Design Patterns in Context ©SoftMoore ConsultingSlide 1

Characteristics of Design Patterns Provide simple and elegant solutions to specific problems in object-oriented software design Consist of descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context Different from –application frameworks –class libraries –components Discovered, not invented (Rule of Three) ©SoftMoore ConsultingSlide 2

Characteristics of Design Patterns (continued) Capture solutions that have developed and evolved over time as designers strive for greater reuse and flexibility (not initial solutions) ©SoftMoore ConsultingSlide 3 “One thing expert designers know not to do is solve every problem from first principles. Rather, they reuse solutions that have worked for them in the past. When they find a good solution, they use it again and again. Such experience is what makes them experts.” – Gamma et al.

Three Levels of Expertise: An Analogy with Chess (Robert C. Martin) Becoming a Chess Master –Learn rules (pieces, legal moves, goals, etc.) –Learn principles (e.g., value of controlling center of board) –Study the games of chess masters Becoming an OOD Master –Learn basics of programming (language syntax/semantics, data structures, algorithms, etc.) –Learn principles (encapsulation, cohesion, coupling, Liskov Substitution Principle, etc.) –Study the designs of OOD masters ©SoftMoore ConsultingSlide 4

Anticipating Change Software designs must anticipate changes and extensions –new requirements –changes to existing requirements Each design pattern lets some aspect of system structure vary independently of other aspects, thereby making a system more robust to a particular kind of change. ©SoftMoore ConsultingSlide 5 “Program to an interface, not an implementation.” – Gamma et al.

Impact of the GOF Book ©SoftMoore ConsultingSlide 6 “The revolutionary concept of the GOF book is not the fact that there are patterns; it is the way in which those patterns are documented.... Prior to the GOF book, the only good way to learn patterns was to discover them in design documentation, or (more probably) code.” – Robert C. Martin

Software patterns as a symptom of failure? ©SoftMoore ConsultingSlide 7 “The ultimate target for Software Patterns may not be the programmers they were initially design for, but for programming language designers.” – Rick Jelliffe

Using Design Patterns ©SoftMoore ConsultingSlide 8 “The more complicated a pattern is, the less common it tends to be. It’s no coincidence that Flyweight, Interpreter, and Visitor are among the most complex, least understood, and least used patterns in our repertoire. When you need them, you need them; that’s when most people bother to learn them. Until such time, they’re easy to ignore.” – John Vlissides

Leftover Patterns (from Head First Design Patterns) “Since Design Patterns: Elements of Reusable Object- Oriented Software first came out, developers have applied these patterns thousands of times. The patterns we summarize in this appendix are full-fledged, card carrying, official GoF patterns, but aren’t always used as often as the patterns we’ve explored so far. But these patterns are awesome in their own right, and if your situation calls for them, you should apply them with your head held high. Our goal in this appendix is to give you a high level idea of what these patterns are all about.” –Bridge– Builder– Chain of Responsibility –Flyweight– Interpreter– Mediator –Memento– Prototype– Visitor ©SoftMoore ConsultingSlide 9

Specialized Patterns (John Moore) In general, I find the following patterns to be somewhat less useful than the others except in highly specialized cases. Creational –Abstract Factory Structural –Flyweight (but Java Enums are very useful) Behavioral –Interpreter –Visitor ©SoftMoore ConsultingSlide 10

The Role of Design Patterns Provide common vocabulary for communication and design documentation Provide framework for evolution and improvement of existing patterns Promote system understanding by focusing on a higher level of abstraction than that of a design notation or programming language Improve the design skills of software developers Assist in implementing software designs ©SoftMoore ConsultingSlide 11

References COMPOSITE à la Java, Part I (John Vlissides) “Software patterns as a symptom of failure?” by Rick Jelliffe, O’Reilly Media. ©SoftMoore ConsultingSlide 12