Sometimes a concept or principle is so simple that it can fly under the radar and no one understands it. For me, at least, this was the case for the OOP principle, encapsulate what varies. In the context of a program, encapsulation is the process of hiding the internal mechanisms and data structures behind an interface. To use the encapsulated operations (object, component), all the developer needs to know is what the component does. Then when the developer needs the component, all of the operations hidden in it are accessed by some kind of request—composition, inheritance or even simple instantiation.
So far so good. Encapsulation is pretty clear, and by the time you’ve decided to tackle design patterns, you should have some idea of encapsulation from OOP principles. The tricky part may be in understanding what is meant by separating elements that you expect to change and those that you expect to stay the same and encapsulate those that change. For this principle, we’re only interested in those elements that may change. Obviously, variables and data change values all the time, and so if we try to encapsulate everything that changes in a program we can quickly become entangled in a swirling flux of mutable elements.
What May Change?
In a recent Lunch Bucket pattern post that loaded SWF files, I noted that I was thinking about adding modules that would load XML files and text files. In other words, I was thinking about what may need to be changed in the program. So when discussing change the principle is not pointing to variables and data but adding components to the existing structure.
The added components are the change referenced in the principle.
All I really need to add (change in the program) is an algorithm to load XML files and another one to load text files. By choosing the Strategy pattern, I can easily add this new functionality by implementing the strategy interface with a new algorithm. The Strategy design pattern is specifically designed to handle change by adding algorithms; therefore, in that pattern algorithms vary and so they are encapsulated.
Suppose you don’t want to change algorithms. Then, you’ll need a different design pattern. For example, in Chapter 10 of our book, I wanted to build a video player that would start and stop playing a video. However, I knew that if my video player program was going to be robust, I’d eventually want to add pause, record, and other functionality to the player. In looking at what would vary (in the long run) I determined that that states of the video player changed. It would be in a play or stop state initially, but by adding modules I could add pause and record states—as well as states that would stop pause and recordings. So, I used the State design pattern because it handles states and makes it easy to change (add new states) because the states had been encapsulated.
You may well be wondering,
“How can I ever know what design pattern encapsulates what I need to change?”
Fortunately, that’s easy! On page 30 of their book, the Gang of Four provide a table (Table 1.2, but I call it, The Magic Table) that shows all of the design patterns and what aspect of the pattern can vary. I’ve reproduced the table making only slight changes in Table 1.
| Pattern | What Varies |
| Abstract Factory | families of product objects |
| Adapter | interface to an object |
| Bridge | implementation of an object |
| Builder | how a composite object gets created |
| Chain of Responsibility | object that can fulfill a request |
| Command | when and how a request is fulfilled |
| Composite | structure and composition of an object |
| Decorator | responsibilities of an object without subclassing |
| Facade | interface to a subsystem |
| Factory Method | subclass of object that is instantiated |
| Flyweight | storage costs of objects |
| Interpreter | grammar and interpretation of a language |
| Iterator | how an aggregate’s elements are accessed, traversed |
| Mediator | how and which objects interact with each other |
| Memento | what priavte information is stored outside an object, and when |
| Observer | number of objects that depend on another object; how the dependent objects stay up to date |
| Prototype | class of object that is instantiated |
| Proxy | how an object is accessed; its location |
| Singleton | the sole instance of a class |
| State | states of an object |
| Strategy | an algorithm |
| Template Method | steps of an algorithm |
| Visitor | operations that can be applied to objects(s) without changing their class(es) |
Table 1:The Magic Table
Using the Magic Table, not only can you better understand the principle of encapsulating what varies, you can see which elements that you may want to change. For example, the Chain of Responsibility pattern allows you to change (add) new or revised request handlers without having to re-write the whole program. Just look at the Magic Table to find what you may possibly need to change in revising a program and use the pattern associated with what needs changing. At the same time, you’ll be learning how to select which design pattern to use. (Take a look at pages 28-29 in GoF for a complete list of ways to help you select a design pattern.)
Into the Lunch Bucket
The principle to encapsulate what varies is a planning principle because you have to think ahead. The Gang of Four suggest that instead of considering what might force a change you should plan on the basis of what you may want to be able to change. If nothing else this principle forces you to stop and think about what you’re doing. By taking this principle to work, you’re adding a little architectural thinking to your programming. The rush of events may not allow you the luxury of considering every possible change that may crop up; however, if you can pick the main change, you can find the change in the Magic Table and know what design pattern to use.
The Design Pattern Principles for ActionScript 3.0: Encapsulate What Varies by William B. Sanders, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.
Bill Sanders
Dear William B. Sanders,
Up until this point, I have been a quiet reader of your incredible blog. I have read Actionscript 3 Design Patterns over and over again in hopes of one day being able to even consider myself in the same arena as you are. One day I hope to get there.
After reading today’s post, I thought it was time for me to speak for the first time, this post really hit home with me.
I am currently about to embark on phase 2 of a project that I started several months ago. I had a tight time-line, and I feel like, had I had more time, I would have built it differently.
I am now faced with phase II of this project. I wish I had taken into consideration the additions that would have come up functionality wise as you did with your Video player example.
Thank you very much for all your hard work, I am amazed how much you are able to do, at what seems like at the same time, and do it at such a high level. You are both a role model and an inspiration to me. Thank you!
Hi Y_Ed,
Chandima and I are glad you like our blog and book. We enjoy what we’re doing and don’t mind putting in the time. In many ways I wish that Design Patterns were easier, but in time everyone comes to understand and use them to make their work better and eventually easier.
Kindest regards,
Bill
Hello again Dr. William B. Sanders,
I agree with you, I wish that Design Patterns were easy. I find myself in a constant struggle to figure out the best way to go about planning a project, architecture wise, and in some regards which Patterns to use and when to use them.
I think that with time I will be better able to figure this out, and with such a great recourse as this site has become, I know that I will find more then one answer right here on this blog.
The project that I mentioned before, is an online application. The app allows users to take a photo with their webcam, or upload an image to use, they are then able to adjust and rotate the image. I was considering going with an Adapter pattern for getting the users image. I thought it would be a good approach since to provide users with the same methods to (capture – upload bitmapData to server) the image, and Encapsulating what varies, that being the method in which the user obtains the image (webcam and uploading).
What is your opinion? I would love to hear what you think would be the best approach to using good OO practices.
Looking forward to hearing from you once again.
Hi Y-Ed,
First off–”Bill” is fine. We’re not fancy on this blog. As for what design pattern to use on your project, just ask yourself, “What would I like to change, add or enhance in a possible update?” If you want to change the interface to an object; then go ahead with the Adapter pattern. What is the “method in which the user obtains the image”? If the focus is on changing the method, do you mean the operations in the method (algorithms). If so; then look to a Strategy pattern. If you have something else in mind; then take a look at the ‘Magic Table’ and see what variation most closely matches what you want to be able to change.
Kindest regards,
Bill