Strong dependencies among classes (or components) are definitely the villains within a software architecture. The opposite of strong dependencies, ie completely decoupled architectures, do not exist however, because such a utopian schema would actually result in no messages being exchanged among objects at all. Architects should focus on minimizing strong dependencies, designing only well-planned ones. I refer to the latter as healthy dependencies, and they undoubtedly bring a lot of benefits to a system.
Successful development processes such as UP (Unified Process) are usually defined as architecture-centric, which basically means that development iterations are guided by the evolution of the architecture, and by architectural artifacts such as UML (Unified Modeling Language) diagrams. Therefore, the architect is responsible for establishing a high level of modularity in order to achieve both expandibility and maintainability potentials. Nicely designed modules connected by healthy dependencies have the power to minimize three undesired, internal properties: Rigidity, Fragility, and Immobility. Let’s have a closer look at each one.
The Rigidity property states that maintenance in a specific point in the architecture may oblige the developer to also change directly related points, generating a maintenance chain. I like calling it the Domino Effect. If you don’t enjoy reading Wikipedia articles, you can just read the following extract: “The Domino Effect is a simple chain reaction that occurs when a small change causes a similar change nearby, which then will cause another similar change, and so on in linear sequence”. It’s pretty clear, isn’t it?
The Fragility property, in its turn, states that maintenance in a specific point in the architecture may force the developer to change a point indirectly related to or far from the former point. We will call the consequence of ths property the Butterfly Effect. Again, another Wikipedia snapshot: “The Butterfly Effect is a phrase that encapsulates the more technical notion of sensitive dependence on initial conditions in chaos theory. Small variations of the initial condition of a dynamical system may produce large variations in the long term behavior of the system”. I am sure the meaning is clear.
Finally, the Immobility property takes place when a developer tries to reuse an existing component, but then gets blocked by other component’s classes that the desired ones depend on. I usually call this the Banana-Gorilla Effect, funny huh? This is because whenever you try to get just the banana, the gorilla comes after it. There’s no way of running away from the big animal, and you suddenly lost one of the major features of the object orientation tenet, code reuse.
OK, enough talking, let’s get back to business. How can we avoid having these three bad properties? How can we design only healthy dependencies? Quick answer: Using Interfaces for dependency inversion. An Interface is a partial description of a domain concept, and is certainly an invaluable ally for any software architect. Technically speaking, it’s a bunch of method signatures that allow further specialization. Erich Gamma et al wrote an entire (best-seller) book called “Design Patterns: Elements of Reusable Object-Oriented Software”, which provides a full set of solutions that address common object-oriented software problems. The solutions are divided in three categories (namely Creational, Structural, and Behavioral), and all of them take advantage of interfaces (holy thing!).
In the next post I’ll illustrate the discussion using a graphical, concrete example. Cheers!
Related posts:
October 21st, 2008 at 12:05 pm
[...] a previous post we met object orientation’s worst enemy (i.e. strong, unplanned dependencies among classes). It is now time to have a closer look at [...]