Imagine that we've got a collection of applications used by customers to provide data, a collection of applications we use to collect data from vendors. We've got a third collection of analytical tools. Currently, they share a common database, but the focus, use cases, and interfaces are different. Okay so far? Three closely-related groups or families of applications.
We need to introduce a new cross-cutting capability. Let's imagine that it's something central like using celery to manage long-running batch jobs. Clearly, we don't want to just hack celery features into all three families of applications. Do we?
Choices
It appears that we have three choices.
- A "wrapper" application that unifies all the application families and provides a new central application. Responsibilities shift to the new application.
- A site-specific library that layers some common features so that our various families of applications can be more consistent. This involves less of a responsibility shift.
- An "aspect" via Aspect-Oriented programming techniques. Perhaps some additional decorators added to the various applications to make them use the new functionality in a consistent way.
- The workflows in the "wrapper" application needed constant tweaking as the other applications evolved. Every time we wanted to add a step, we had to update the real application and also update the wrapper. Python has a lot of introspection, but these aren't technical changes, these are user-visible workflow changes.
- Introducing a new data types and file formats was painful. The responsibility for this is effectively split between the wrapper and the underlying applications. The wrapper merely serves to dilute the responsibilities.
From http://slott-softwarearchitect.blogspot.com/2010/12/wrapper-vs-library-vs-aspect-problem.html
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}