TITLE: Patterns that Break the Rules AUTHOR: Eugene Wallingford DATE: July 30, 2004 12:26 PM DESC: elementary patterns and design rules and heuristics ----- BODY: I ran across an old 'thought piece' (*) a couple of days ago that reminded me of a discussion that was common at my early PLoPs: how some design patterns 'break the rules' of object-oriented design. Among the GoF patterns, Bridge and Singleton are often cited as patterns that violate some of the principles of OOD, or at least the heuristics that usually indicate good designs. On the other hand, some of the GoF patterns don't violate OOD design principles. Indeed, they seem to specialize or at least illustrate of OOD design principles. Strategy, Adapter, and State come to my mind. I remember a comment that Bobby Woolf made to me at PLoP'96 or '97 when he came across such a pattern in a workshop: "That's not a pattern. It's just object-oriented programming." Of course, if a particular configuration of classes and methods recurs in a particular context, then acknowledging that recurrence has value has a tool for teaching and learning. What is obvious to one reader is not obvious to every reader. (Brian Marick wrote an interesting note on how this applies to comments in code.) Such a pattern also has value as a part of a pattern language that documents something bigger. Back in those days, Jim Coplien was just beginning to talk about the idea of symmetries, symmetry breaking, and their relationship to what is and isn't a pattern. I wish I could remember some of the pragmatic criteria he used for classifying the GoF patterns in this way, but my memory fails me. One can see this idea at work with patterns of imperative programming, too. Control structures break the "symmetry" of sequential processing, while some looping patterns illustrate common design rules (e.g., Process All Items) and others violate more general rules (e.g., Loop and a Half). The most important point made in this thought piece was a pedagogical one, made in the conclusion: that relating patterns to more general design rules and heuristics helps students learn both better. This should be obvious to us, but like many patterns needs to be said explicitly every once in a while. Relating patterns to more general design rules and heuristics creates a richer context for both. It helps students learn to make better design decisions through a deeper understanding of the forces at play. (*) Joseph Lang et al., "Object-Oriented Programming and Design Patterns", SIGCSE Bulletin 33(4):68-70, December 2001. -----