Design Pattern Principles for ActionScript 3.0: The Dependency Inversion Principle

Most of what we mean by the Dependency Inversion Principle has been discussed either in describing what a design pattern does in terms of relating components to one another or implied in other principles. However, I’ve found that the Dependency Inversion Principle acts as a helpful reminder to keep things abstract in working with instances that request functionality or extend a base class.

Unfortunately, the concept of inversion is only half the story and is used in reference to programming structures where a higher-level module depends on a lower-level module. One might be led to believe that the inversion occurs where lower level modules depend on higher-level modules only. Actually, the principle holds that

all modules of a program should depend on abstractions

Maybe a better name for the principle would be the Abstraction Dependency Principle. In any event, program modules should all depend only on abstractions. If you look at Figure 1 you can see a simple example where a Client instantiates a concrete class but depends on the abstract class for typing. Further, the concrete classes depend on the abstract class for implementation. Aggregations and associations would depend on the abstract base class instead of the concrete classes as well.

Figure 1: Depending on Abstractions
As you can see in both the diagram and code snippets, all dependencies are on the Abstract class. That’s what the principle means at its core. It’s not a difficult one, and it overlaps with lots of other principles we’ve discussed on this blog and in our book.

The Devil is in the Details

A corollary to dependency inversion is what might be called detail inversion—not that anyone actually calls it that. The principle is,

Details should depend on abstractions, and abstractions should not depend on details.

As you can see in Figure 1, the details in the two concrete classes depend on the implementations of the abstract class. Likewise, the details of instantiation depend on the nature of the Client’s request. If you’ve been reading about the different design patterns on this blog and in our book, this corollary may appear to be almost too self-obvious to state. However, if this is the first OOP principle you’ve considered, it may not be as clear.

Consider an abstract class called Fruit. As you know, the details of different kinds of fruit are many—from kumquats to kiwi fruit and bananas to blueberries. So, while you can put the general characteristics of fruit in an abstract class (e.g., berry, pome, drupe), the details are in the concrete implementations (e.g., apples and oranges). However, the implementations depend on the general properties in the base abstract class; not the other way around.

Where to Find Dependency Inversion in Design Patterns

Robert C. Martin’s series of articles in his Engineering Notebook written for the C++ Report came out around the same time as the Gang of Four’s Design Patterns book. (Roughly the period of late 1995 to early 1996). However, Martin along with OOP thinkers like Grady Booch and GoF were all thinking along the same lines. Martin makes references to OOD for Object Oriented Design—clearly differentiating it from OOP, and he references the GoF book, which was brand new at the time he was writing about dependency inversion. What all of these software engineers had in common was that their emphasis had shifted from just programmingto the broader concept of programming design.

So while you’ll not find a reference to dependency inversion in GoF, you will see it applied in design patterns. For example, if you look at the Strategy design pattern, you will see an almost perfect example of dependency inversion. The Client makes requests through the abstract Context, which in turn holds references to the abstract Strategy. Any references to the concrete classes are all through an abstract interface or class. That is, the references are typed as abstract classes or interfaces. Likewise Martin uses a Template Method and Adapter design patterns to illustrate dependency inversion. Suffice it to say that the thinking and writing about design patterns in the early 1990s through OOPSLA conference presentations and papers began to coalesce around the mid-1990s in publications focusing on the design aspect of programming. The programming principles that emerged from that era were all looking for ways to express the importance of strong but loose designs for reusability and adding functionality.

Into the Lunch Bucket

Now that you have a sense of dependency inversion, you can put it into your lunch bucket and take it to work. You may be thinking that the other principles pretty much encompass what is included in the Dependency Inversion Principle, and you’d be right. When Robert C. Martin developed the concept, he noted that the principle encompasses both the Open/Closed and Liskov Substitution Principles. So any sense of déjà vu you may have detected is grounded in reality. Also, if you are interested in a related concept that will be discussed in a later post, you might want to look into Martin Fowler’s Dependency Injection concept. (Be careful not to get your Martins mixed up!). Likewise, Miško Hevery has a great video and article on dependency injection.

The Design Pattern Principles for ActionScript 3.0: The Dependency Inversion Principle by William B. Sanders, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.

Related posts:

1. Index: ActionScript 3.0 Design Patterns Principles and Design Patterns at Work
2. Design Pattern Principles for ActionScript 3.0: The Liskov Substitution Principle
3. More OOP Principle Analogies