Easy to Find
We got to the point where the posts on the Principles of OOP and Design Patterns and the discussions of introducing Design Patterns to the workplace became so numerous that they were difficult to locate on the blog. This is the first index that we have, and as we continue to grow, we’ll have to add more. (We are certainly nearing that point with MVC and Pure MVC posts.) So, in the “Categories” section of our blog, we’ll be adding indices as needed. Look for the Index category to locate all indices.
Continue reading ‘Index: ActionScript 3.0 Design Patterns Principles and Design Patterns at Work’
The final principle we’re going to examine for the Lunch Bucket Rules series is the Single Responsibility Principle. Succinctly stated, it means that each class should have one and only one responsibility. At the base of this principle is the idea that if you make a change, you are less likely to run into a problem if each class has a single responsibility. The same principle is expressed as, each class should only have a single reason to change.
In our book, we discuss this principle briefly (pg. 443). The MVC design represents three clear areas of responsibility—Model, View, and Controller. Each responsibility is clearly spelled out, and each of the three elements in the framework sticks with its own responsibility. That’s not a bad place to start as far as a getting a general sense of what this principle means.
Simple Never Is
In searching around for information about the Single Responsibility Principle, I came across a short post by David Chelimsky. In that post he cites the following quote:
In procedural programming, a process is expressed in one place in which a series of instructions are coded in order. Whereas in OO, a process is expressed as a succession of messages across objects. One object sends a message to another, which does part of the process and then sends a new message off to another object, which handles part of the process, etc. You modify a process by reorganizing the succession of messages rather than changing a procedure.
Ooof! That quote knocked the wind out of me because of all of its implications. It’s saying that when you make a change, your main focus is on rearranging responsibilities encapsulated in classes instead of re-writing a procedure. This forces the developer to ask, What responsibility does each class have? If each class has a single responsibility, that makes life a lot simpler. On the other hand, classes with multiple responsibilities may be ripped up or cause problems elsewhere because they can be changed in more ways than one and do more than one thing, wrecking unpredictable havoc.
Continue reading ‘Design Pattern Principles for ActionScript 3.0: Single Responsibility Principle’
The problem in understanding the Hollywood Principle is that it is too often glossed over as a type of inversion of control. In most respects, the Hollywood principle is really about the direction of calls. Where it gets a little confusing is when you assume the natural order of programming is from bottom to the top, with the bottom making calls to the higher levels. At one time, much programming was “bottom-up” in this sense, but that’s been quite a while. Therefore, when talking about inversion, you may be wondering, inversion from what? In fact, the late John Vlissides (one of the Gang of Four) starts off a discussion of the Hollywood Principle, noting,
The Template Method pattern leads to an inversion of control known as the “Hollywood Principle,….” (1996)
As we know, Dependency Inversion is better understood as Abstraction Dependency—both higher and lower level components come to depend on abstractions. If we think depend on abstractions we have no need to even consider inversion. Doing so only confuses the issue. So, if we examine the Hollywood Principle, let’s do so in terms of what it does in its own right—what is its focus?
The Hollywood Principle holds that higher level components should call lower level components, but lower level components should not call higher level components.
So, if we take that focus of the Hollywood Principle we can better discuss its unique features. Is it related to the other principles of OOP? Of course it is, but let’s just focus on the point it makes.
Continue reading ‘Hollywood Principle: Don’t Call Us; We’ll Call You—ActionScript 3.0 Template Design Pattern goes Hollywood!’
For those of you who have developed applications where a reference drills down through a series of movie clips, the Least Knowledge Principle may seem a bit harsh. It is very easy and even shows a semblance of foresight and organization to arrange operations in a movie clip set to have each movie clip do one thing in a complex object. To get something working, though, you do not want to rely on drill-down references that visit each of the many movie clips. Statements such as,
myMC_high.myMC_middle.myMC_lower.myMC_lowest.DoSomething()…
break the principle of Least Knowledge because it implies that each has some knowledge of the inner workings of the others. Likewise, anyone who has spent much time with JavaScript and the Document Object Model (DOM) knows that many of the objects have some hefty drill-downs in references. According to the Least Knowledge Principle, these are all ways to ask for trouble. Let’s see why.
Continue reading ‘Design Pattern Principles for ActionScript 3.0: The Least Knowledge 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.
Continue reading ‘Design Pattern Principles for ActionScript 3.0: The Dependency Inversion Principle’
Bill Sanders
Recent Comments