Introduction to Object-Oriented Design Patterns

1. Presentation for IPMA Forum 2004 Glenn Briskin – Director of Consulting Services – Sierra Systems Inc. Nick Malik – Development Lead – Microsoft Introduction to Object-Oriented Design Patterns

2. Sierra Corporate Profile • Publicly traded on TSX (SSG) • Founded in 1966 • 2002/03 Revenue of $150 million • 750+ consultants (Average of 11 yrs in IT industry) • 10% having professional designations • 15% with graduate degrees • 25% with technical certifications • 2 Washington State Locations • 16 offices throughout North America • Microsoft Gold Certified Partner

3. eProcurement Insurance and Benefits Claims Management K-12 and Higher Education Student Records Data Management Lands, Title and Deeds Management Legislative Licensing and Permitting Municipal and Physical Infrastructure Management Natural Resources Management Public Sector Administration Human Resources Payroll Finance Safety, Quality, Regulatory and other Inspection Services Tax and Revenue Management eGovernment Practice

4. Agenda • What are design patterns? • Architectural vs. Design patterns • An example problem • Design patterns as a catalyst for change • How to learn design patterns • References and Acknowledgements

5. What is a Design Pattern? • A solutions to a commonly occurring design problem • Help create flexible and reusable designs • Larger scope than a single class or algorithm • Describes the circumstances in which the pattern is applicable • Describes the consequences and trade-offs of using the pattern within a larger design • Language Independent

6. Architectural vs. Design Patterns • Architectural patterns address problems of • Distributed functionality and system partitioning • Protocols and Interfaces • Scalability, Reliability, Security • Leverages the “Distributed system” • Design patterns address problems of • Maintainability, code reuse, and frameworks • Abstraction and algorithm hiding • Leverages the “Object oriented language”

7. What problem does DP solve? • Good designs can cope with change • Underlying technologies change • Business goals change • User expectations change • OOP gives us the tools to cope with change: • Encapsulation • Inheritance • Polymorphism • Having tools = good. Using them well = better.

8. An Example Problem • In the beginning, you get the following requirement: The regional sales entry system must send data, in batches, to the accounting package (Microsoft Great Plains Accounts Receivable). • You create the OrderCollector class.

9. And now the requirements change • Good news: our departmental application is being picked up by the manufacturing division in Florida. • Bad news: they use Solomon for their accounting package. Fix the code to use Solomon as well as Microsoft Great Plains. • The interaction is quite different. You have to change the code that calls the accounting interface.

10. The new diagram

11. The problem with the solution • The code to call the Microsoft Great Plains solution is similar to the code that calls the Solomon solution. • Business rules specific to the task of “send something to accounting” are mixed in with business rules for “send data to the specific package.” • Therefore: if another accounting package comes in, say Oracle, you’d have to do it again. • The interfaces are fairly different… inheritance doesn’t appear to help.

12. Apply the Adapter pattern • According to GoF, Adapter “converts the interface of a class into another interface clients expect.” • In this example, we use one variation of the Adapter pattern called the “pluggable adapter using abstract operations” (see p.144 of GoF) • The pattern looks like this:

13. A better OO solution

14. Better because • Business rules are separate from technical rules. They are more readable and more testable. • The business rules are implemented once and only once. This makes it easier to find and update business rules. • If you add another accounting system, you only have to code another adapter. The business code already exists and can be reused (usually).

15. So what’s the big deal? I could have done that with a code template! I’ve done that before on my own! Why call this a pattern? The power of Design Patterns does not come just from templates and bits of reusable code… It comes from a new way of thinking about objects. Patterns are the examples that lead us to make this leap.

16. Some questions for you to ponder • Are objects just “data with methods?” • Does encapsulation mean the same thing as data hiding? • Is inheritance best used to create “specialized” versions of a class?

17. A different way of thinking • Encapsulation = hide anything… not just data • Objects as a “realized set of responsibilities” • Abstract classes that define “common” capabilities of an object, with inheritance used to specify variations.

18. A different way of programming • Focus on what objects are supposed to do, not simply how to implement them. • Consider what is variable in the design… then hide it. • Put layers between things that independently change. Design Patterns = applied best practices in software design • Proven methods for hiding things, not just data. • “Commonality vs. Variability” lives at the heart of DP

19. Benefits of using Design Patterns • Establish a vocabulary • Allows teams to communicate at a higher lever • Reusing a technical solution allows you to focus on the business problem • Makes design documentation easier to understand • Your code improves • More maintainable: Less coupling, greater cohesion • Internalize concepts of commonality vs. variability • Your productivity improves • Why re-invent the wheel?

20. How to learn Design Patterns • Read the Gang-of-Four book. • Better yet, Read the Shalloway book first, then read GoF. • Better yet, join a Study Group, and study them both. • Keep learning: • build a community of interest, and discuss them. • build a community of practice, and use them.

21. Design Pattern Study Groups • Joshua Kerievsky provides an excellent overview: http://www.industriallogic.com/papers/learning.html • Learn the patterns in a specific order • Meet frequently in small groups in a conducive space • Socratic method – study a question and answer it using the material.

22. Suggested Navigation (one order in which to learn the GoF patterns) u Observer u Chain of Responsibility u Memento u Command l Prototype u State u Visitor n Flyweight u Interpreter n Facade l Factory Method u Strategy n Decorator n Composite u Iterator u Template Method l Abstract Factory l Builder l Singleton n Proxy n Adapter n Bridge u Mediator • l Creational • Structural u Behavioral

23. AntiPatterns – what doesn’t work • Software Development • The Blob • Lava Flow • Functional Decomposition • Poltergeists • Golden Hammer • Spaghetti Code • Cut-and-Paste programming • Software Architecture • Stovepipe Enterprise • Stovepipe System • Vendor Lock-in • Architecture by Implication • Design by Committee • Reinvent the wheel • Project Management • Analysis Paralysis • Death by Planning • Corncob • Irrational Management • Project Mismanagement

24. Resources • Design Patterns: Elements of Reusable Object-Oriented Software by Gamma, Helm, Johnson, and Vlissides • Design Patterns Explained: A New Perspective on Object Oriented Design by Shalloway and Trott • Anti-Patterns: Refactoring Software, Architectures and Projects in Crisis by Brown, Malveau, McCormick, and Mowbray • Patterns Home Page • http://hillside.net/patterns/patterns.html • Vince Huston’s Patterns page • http://home.earthlink.net/~huston2/dp/patterns.html • Portland Pattern Repository • http://c2.com/ppr/ • Microsoft’s Patterns and Practices • http://msdn.microsoft.com/practices/type/Patterns/enterprise/

25. Acknowledgements • Significant portions of this presentation were adapted from original works by: • James C. Smith - Reflexive Entertainment, Inc. • Alan Shalloway – NetObjectives • Douglas Schmidt – University of California, Irvine • Joshua Kerievsky – Industrial Logic • Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (the Gang of Four) • About Nick Malik: A development lead in Microsoft Business IT, Nick is an architect, author, speaker, trainer, designer, and all around problem solver. After 23 years of software development, he still loves to learn, discover, develop, and share what works. NMalik@Microsoft.com

26. © 2002 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.