Better Software - July/August 2008 - (Page 35) Notice that the proper name (the title of the GoF book notwithstanding) is patterns OF software design. I agree that this sounds like I’m splitting hairs, but it matters how we use the patterns during design. Look at the patterns above, as well as all of the GoF patterns. They are instantiations of design decisions. You make a design decision to encapsulate the creation of objects of a class hierarchy— that’s the design. Factory Method or Abstract Factory pattern is the way you make that design happen. You design your data as a hierarchal collection with recursive overtones, and Composite helps you implement the design. You design a counter to keep track of the frequency of errors and to alert you if the threshold is exceeded—that’s a Leaky Bucket Counter. What does this mean? You design your solution following good design principles. Along the way, patterns help you implement your design. They can even give you low level design ideas. In fact, as you use them, patterns will become a part of you, and you will draw on them more automatically in the proper circumstances. solidates reference checking and error handling into one place: The null object itself. The Factory patterns put all the object creation code in one place. liskOv subsTiTuTiON PriNciPle Barbara Liskov first intoned the advice that a derived object (subclass) should be able to be used wherever an instance of the base class (superclass) is used [8]. A derived class can always substitute for its base class. Of course, you can follow this principle without necessarily using any patterns. However, the Template Method pattern is one pattern that implements this idea. seParaTe iNTerface frOm imPlemeNTaTiON This principle allows the two to vary independently—changes to the interface need not affect the implementation, and one may change the implementation without forcing changes to the interface. One of the standard ways of doing so is to put the implementation in a class and create a separate class for the interface. Interface objects contain a reference to a corresponding implementation object. This is called variously the Handle Body Idiom (or pattern) [9] or the Pointer to Implementation idiom. patterns in depth to understand the nuances of their benefits and drawbacks. So where should you start? Ironically, don’t start with the patterns. Instead, be sure to master good software design— make the principles of good design (not limited to the ones above) part of you. If you are already there, then explore patterns beyond the Gang of Four. In particular, explore patterns in the domains in which you work. Learn how these patterns help you solve problems within the overall context of disciplined software design. Good luck with your next project. And remember that twenty-three is not the answer to the Ultimate Question of Life, the Universe, and Everything. That would be forty-two. {end} RefeRences: 1] Gamma, Erich; Helm, Richard; Johnson, Ralph; and Vlissides, John M. Design Patterns: Elements of Object-Oriented Software, AddisonWesley, 1995. 2] Freeman, Eric and Freeman, Elisabeth. Head First Design Patterns, O’Reilly, 2004. 3] Woolf, Bobby. “Null Object,” In Pattern Languages of Program Design, Volume 3, pp. 5-18. Addison-Wesley, 1998. 4] Buschmann, Frank; Meunier, Regine; Rohnert, Hans; Sommerlad, Peter; and Stal, Michael. Pattern-Oriented Software Architecture, Volume 4. Wiley, 2007. 5] Adams, Michael; Coplien, James; Gamoke, Robert; Hammer, Robert; Keeve, Fred; and Nicodemus, Keith. “Fault-Tolerant Telecommunication System Patterns.” In Pattern Languages of Program Design, Volume 2, pp. 549-562. Addison-Wesley, 1995. pp. 549-562. 6] Utas, Greg. Robust Communications Software. Wiley, 2005. 7] Mezaros, Gerard. “Pattern: Half-Object Plus Protocol (HOPP).” In Pattern Languages of Program Design, Volume 1. Addison-Wesley, 1995. 8] Liskov, Barbara, H. and Wing, Jeanette, M. “Behavioral Subtyping Using Invariants and Constraints.” Carnegie Mellon University Technical Report CMU-CS-99-156, July, 1999. 9] Coplien, James, O. “C++ Idioms Patterns.” In Pattern Languages of Program Design, Volume 4. Addison-Wesley, 2000. Design Principles Yes, I said “following good design principles.” Now you’re wondering what the difference is between principles and patterns. “Doesn’t that mean to design using patterns?” Sigh. That is the same attitude that fosters the belief that the design with the most patterns wins. That isn’t true, but it is true that designs that follow principles of good design tend to be easier to implement and maintain. Let me illustrate the difference between software design principles and patterns. cOuPliNg aND cOhesiON Everyone has heard the mantra that cohesion should be high and coupling should be low. This is one of the most basic software principles, perhaps only behind modularity and information hiding. And all of these are intertwined. But here’s a curious thing—not all design patterns help improve cohesion and coupling. For example, Command and Visitor allow tight coupling between objects. But, they have good reasons for doing so. And that’s the point—patterns by themselves will not necessarily improve your coupling and cohesion, or any aspect of design. Instead they may help instantiate a good design. DON’T rePeaT yOurself (Dry) This is a standard principle of good software design and coding. If you repeat code, you waste effort and leave yourself vulnerable to error propagation when forgetting to change the code the same way everywhere. A pattern that helps adhere to this principle is Null Object. Without Null Object, one is compelled to check everywhere for null references and perform some error handling (usually the same actions). Null Object con- Putting It All Together Well, that’s a lot to think about, isn’t it? I’ve briefly described four new patterns and hinted at many more. Yet these are just introductions to these patterns. You really need to read and study the www.StickyMinds.com JULY/AUGUST 2008 BETTER SOFTWARE 35 http://www.StickyMinds.com
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.