Design Patterns Explained

Transcription

1 Design Patterns Explained Analysis to Implementation copyright 2010 Net Objectives Inc.

2 Lean for Executives Product Portfolio Management Business Product Owner Business technical Team process Lean-Agile Kanban / Scrum ATDD / TDD / Design Patterns Lean Enterprise Manage ment Lean Management Project Management ASSESSMENTS CONSULTING TRAINING COACHING Purpose of This Tutorial Provide an innovative look at Design Patterns Incorporates: Object-Oriented Principles a new way to look at object-oriented design a better way to identify and define our entities The general design advice patterns represent Consider how domain analysis can enhance design Consider the difference between Knowing Patterns Being Pattern-Oriented

3 What Tutorial Covers Basic object-oriented principles Encapsulation Polymorphism Inheritance What to use it for General Advice from the Gang of Four Design patterns what they really are Learn why design patterns are good designs Learn how to use design patterns together When Adding Functionality Where s the Problem? In writing the new code? In integrating it into the new system? Which is likely to be the source of difficulties? Why?

4 In a Nutshell How can we design to accommodate change? We are not trying to anticipate change, per se, as much as writing our code to accommodate change better Trying to anticipate change can lead to paralysis by analysis Designing from context will guide us as to when we need to get the details. It also gives us the bigger picture from within which to design Design Patterns copyright 2010 Net Objectives Inc.

5 What Are Patterns? Patterns are best-practice solutions for recurring problems in a particular context. Patterns have been classified as being:* Architectural Design Idiomatic Design patterns can also be thought of as describing the relationships between the entities (objects) in our problem domain. Patterns have led to new modeling techniques: handling variations in behavior new ways of using inheritance to avoid rigidity and aid testing and maintenance issues. * Pattern Oriented Software Architecture, Buschmann, et. al. Drawer Front Top Please Don t Turn the Page Until Instructed to Do So

6 A Pattern in Carpentry Let s say two carpenters are trying to decide on how to build a dresser. One says to the other: should we build the joint by first cutting down, then cutting up at a 45 degree angle... then back down and back up the other way, then back down Dove-Tail Tails and Pins Reliable Strong Humidity Tolerant

7 A Miter Joint Commonly used in picture frames. Patterns Work At All Levels Dovetail Miter Forces Strong, High-Cost, Decorative, Humidity Tolerant Weak, Cheap, Fast, Good for Picture Frames Design Interlaced joint Single Abutting Cut Implementation Cut teeth,.5" long,.4" deep, match teeth to gaps 45 degree angle cut attached with staple or other spanning connector

8 Focusing on Detail Loses the Big Picture By having to describe how we implement the dove-tail joint, we can lose sight of why we might want to use it in the first place. Dove-tail Joint vs. Miter Joint emphasizes: do we want a strong, relatively expensive joint that is of high quality and will last forever or do we want a weak, relatively inexpensive joint that is easy to make but not of high quality The Different Perspectives Conceptual describes what you want, not how you ll get it requirements are often specified at a conceptual level we need to handle inventory in LIFO, FIFO, avg cost Specification the interfaces of our classes how objects talk to each other our product class methods look like Implementation the code itself

9 Consider These Are they the same or different? Mop Broom Sponge Same or Different? Who thinks they are the same? Who thinks they are different?

10 As Any Good Consultant Will Tell You: IT DEPENDS! As specific objects: they are different As a concept: they are all Cleaning Utensils Where does Cleaning Utensil exist? Not in the real world, but in our thoughts as an abstraction classification! A Cleaning Utensil does not exist, but specific kinds do!

11 Three Levels of Perspective* Conceptual Perspective Specification Perspective Implementation Perspective * From Martin Fowler s UML Distilled A Note About Encapsulation We often think of encapsulation as something we do at the object level (i.e., hide its data). On reflection, however, we can see that we have used encapsulation to hide a set of classes (all the derived classes). Abstract classes and interfaces essentially encapsulate all of their derivations and implementations -- no one need know they exist. Encapsulation can be used to contain rules - good idea to put one rule in one place

12 Commonality-Variability Analysis James Coplien s Multi-paradigm Design for C++ Abstraction, in the common English language sense, means to focus on the general and put aside the specific. We abstract by emphasizing what is common and de-emphasizing details. Abstraction is a fundamental analysis tool. His thesis is on line at: (link is case-sensitive) Commonalities Commonality analysis is the search for common elements that helps us understand how family members are the same * Commonalities are Recognized from experience Learned through analysis (abstracted) Commonalities can define basic concepts in a domain * Multi-Paradigm Design in C++, Jim Coplien

13 Variability Analysis Variability makes sense only in a given commonality frame of reference. It is a variation of some commonality From an architectural perspective, commonality analysis gives the architecture its longevity; variability analysis drives its fitness for use * * Multi-Paradigm Design in C++, Jim Coplien Reasons to Get Variations of Commonalitie In analysis, we don t need detailed design, we just need to determine: The resources required for implementation The risks involved Define scope (variations give us specific cases) Make sure variations define commonalities (do we have enough cases to define the interface?) ~3

14 Example Problem copyright 2010 Net Objectives Inc. The Problem We are writing a web-enabled sales order system A customer signs in and fills out the order

15 Initial Solution TaskController SalesOrder Have TaskController instantiate SalesOrder that handles filling out the sales order, etc. The Challenge As soon as we get new variations in tax we have to modify our SalesOrder object Where should we add the new responsibility if taxation begins to vary?

16 New Requirement - Multiple Tax Domains Eventually need to handle different tax rules US Tax Canadian Tax One Solution method calctax // use switch on type of tax rule to be used // TYPE US: // calc tax based on US rules // break // TYPE CANADIAN: // calc tax based on Canadian rules // break Direct Inheritance for Specialization We can solve this problem by specializing our first SalesOrder object to handle the new tax rules TaskController SalesOrder + calctax() original calctax that does US tax new (overriden) calctax that does Canadian tax CanadianSalesOrder + calctax()

17 Abstract Inheritance for Specialization This is a bit better SalesOrder + calctax() CanadianSalesOrder + calctax() USSalesOrder + calctax() This May Lead to Maintenance Problems If we get new variations, where do we put them? We either start using lots of switches (which makes the code difficult to understand), or we start overspecializing (which still makes things difficult) What if we need to switch tax algorithms at runtime? SalesOrder + calctax() CanadianSalesOrder + calctax() USSalesOrder + calctax() EnglishCanadianSO + language() FrenchCanadianSO language()

18 Advice From the Gang of Four copyright 2010 Net Objectives Inc. Advice from the Gang of Four Design to interfaces Favor object delegation over class inheritance Consider what varies in your design and encapsulate the concept that varies Gamma, Helms, Johnson, Vlissides: Design Patterns: Elements of Reusable Object-Oriented Design

19 Design to Interfaces: Methods Craft method signatures from the perspective of the consuming entities Hides the implementation of your methods Programming by intention is a systematized way of designing to interfaces Design to Interfaces 1 1 or 1 many AbstractionA Relationship AbstractionB Impl1 Impl2 Impl3 Relationship Impl4 Impl5

20 Favor delegation over inheritance specializing function with inheritance is a short path to problems Proper use of inheritance Define a class that encapsulates variation, contain (via delegation) an instance of a concrete class derived from the abstract class defined earlier Chip Chip Encryption Chip_64e Chip_128e 64e 128e Class Inheritance to Specialize Class Inheritance to Categorize 1. Decoupling of concepts 2. Deferring decisions until runtime 3. Small performance hit

21 Find what varies and encapsulate it Base classes encapsulate their implementing subclasses This encapsulates varying behavior Chip Encryption Find what varies and encapsulate it A varying anything: Varying design Varying object creation Varying relationships (1-1, 1-many) Varying sequences and workflows Etc

22 Encapsulate variations Encapsulating variation means to make it appear as if the varying issue is not varying Each pattern encapsulates a different varying thing The Net Objectives Patterns Repository Behavior Strategy Bridge Template Method Null Object Sequence Decorator Chain of Responsibility Template Method Workflow Template Method Visitor Bridge Null Object Cardinality Decorator Chain of Responsibility Proxy Construction Singleton Abstract Factory Selection Chain of Responsibility Structure Composite Template Method Entity Facade Adapter Proxy Observer Relationships Observer Command Mediator Visitor Dependencies Mock Object

23 This Advice Relates to Principles Deal with things at an abstract level Why? Client AbstractionA Impl4 Impl1 Impl2 Impl3 Relates to: The Open-Closed Principle This Advice Promotes Quality Design to Interfaces: Helps eliminate redundant relationships Avoids subclass coupling Encapsulate Variation Promotes encapsulation Decouples client objects from the services they use Leads to component-based architectures Favor aggregation over inheritance Promotes strong cohesion Helps eliminate redundant implementation

24 At First Level of Understanding Design Patterns Are Examples Each pattern is an example of a design that follows this general advice well, in a given context Design patterns are discovered, not invented: they are what successful design have done to solve the same problem Studying design patterns is a good way to study good design, and how it plays out under various circumstances The Strategy Pattern copyright 2010 Net Objectives Inc.

25 The Strategy Pattern We need different behavior at different times; either for different things we are working on or for different clients asking us to do work. GoF Intent: Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it. * Design Patterns: Elements of Reusable Object-Oriented Software by Gamma, Helm, Johnson, Vlissides. Addison- Wesley Professional The Strategy Pattern The Strategy pattern is a pattern that tells us how to identify a set of rules that conceptually do the same thing In our example: tax identify a common way to communicate with all implementations of the rule define an interface or abstract class that defines this communication implement each variation of the rule as an implementation or derivation

26 Strategy Lives in Analysis, Design, Implementation In analysis: Any time we find a varying business rule, it is likely a Strategy pattern is present If we know we need to use a Strategy, the pattern tells us to encapsulate the varying rule behind an interface During implementation The pattern gives instant experience in the implications of one implementation over another The pattern is really about the relationship between one object that uses one of several conceptually similar rules In The UML TaskController SalesOrder CalcTax + taxamount(itemsold : Salable, qty : double, price : double) : double USTax CanTax

27 The Canonical Strategy Pattern Client Context + request(strategy) Strategy + algorithm() StrategyA + algorithm() StrategyB + algorithm() Strategy as an Example of GoF Approach Client Context + request(strategy) (3) Strategy + algorithm() (2) encapsulates variation (1) StrategyA + algorithm() (1) StrategyB + algorithm() (1) find what varies (the strategies) and (2) encapsulate it (Strategy) (3) favor object-aggregation over class-inheritance

28 Who Knows Which Rule to Use Before, TaskController needed to know either the value of the tax switch to set or which SalesOrder to instantiate It can now instantiate the appropriate CalcTax object OR, we can have a creational object (factory) make the proper CalcTax object Another Version of the Strategy Pattern Client * Context + request(strategy) Strategy + algorithm() 1 Factory StrategyA + algorithm() StrategyB + algorithm()

29 What Happens Now With Changing Requirements If we get a new tax requirement, we : 1. Derive the new class from the CalcTax class 2. Modify the TaskController or the Factory object Which may, in fact, work with a data dictionary so even it doesn t need to change No other objects change Value of Strategy Conceptually it is cleaner Each object is concerned with one function Better independence of different actions Issues that are separated into different encapsulated entities also makes unit testing easier

30 Why Bother? What happens if many things vary? In other words, in addition to the tax rules, we could have the following variations? different shipping charges different monetary rules different address rules Switches and direct inheritance do not scale Code Qualities Where Good Design Begins What Good Design Reflects Why Patterns are What they Are copyright 2010 Net Objectives Inc.

31 Qualities Consider a string of Christmas lights What do you do if it fails On the Table? On the Tree? Is this a complex device? It s not so much the complexity as it is the: Dependencies Fragility Duplication Predictability We can t predict how our requirements are going to change We can predict how different coding styles will adapt to unpredictable requirements changes What is the style that adapts more readily?

32 Another One: Who Thinks We Spend a lot of Time Fixing Bugs? The Time on Bugs Myth We usually spend very little time fixing bugs We OFTEN spend a lot of time finding bugs and in the discovery process of seeing how things affect each other We should therefore put our efforts more into finding errors when they occur than worrying about the amount of typing we do

33 Many Factors to Consider What are the first principles? Cohesion Cohesion refers to how closely the operations in a routine [or class] are related. I have heard other people refer to cohesion as clarity because the more operations are related in a routine [or class] the easier it is to understand the code and what it's intended to do. * Strong cohesion is related to clarity and understanding No "schizophrenic classes No "12-page methods" * Code Complete, Steve McConnell, 1993, p. 81. This concept was first described by Larry Constantine in 1975, but we like McConnell s definition best.

34 Strong Cohesion Class Cohesion A class has a single responsibility Commonality-Variability analysis can help us to determine the right size of our classes Testability will help us here, as we shall see Method Cohesion Each method is about fulfilling one functional aspect of that responsibility Programming by intention can help us to code with better method cohesion from the outset Coupling Coupling refers to the strength of a connection between two routines [or classes]. Coupling is a complement to cohesion. Cohesion describes how strongly the internal contents of a routine [or class] are related to each other. Coupling describes how strongly a routine is related to other routines. The goal is to create routines [and classes] with internal integrity (strong cohesion) and small, direct, visible, and flexible relations to other routines [and classes] (loose coupling). * Tight coupling is related to highly interconnected code * Code Complete, Steve McConnell, 1993, p. 81. This concept was first described by Larry Constantine in 1975, but we like McConnell s definition best.

35 No Redundancy "One Rule in One Place" Good example of violating this: Y2K Redundancy is not just: Redundant state Redundant functions It can also be redundant relationships, design, construction, etc Anything that is redundant will cause maintenance problems Encapsulation and Other Qualities Encapsulation and Coupling Hidden things cannot be coupled to Encapsulation and Cohesion? Cohesive issues are easier to hide Encapsulation and Redundancy? When an issue is hidden, multiple clients cannot make use of the same behavior When it s revealed, then no duplication is needed It's an issue of balance

36 Encapsulation, Coupling, and Redundancy Class A -Redundant Issue Class B -Redundant Issue Class A and Class B have a redundant bit of state or functionality, or a redundant relationship to another object The redundant issue is currently encapsulated, however How can we resolve this redundancy? It Depends! Class A -Redundant Issue Class B -Redundant Issue on the relationship between these classes Is it: Conceptual? Are classes A and B variations of some common concept? or A relationship of consistent use? Are classes A and B two distinct entities that have a need that can be resolved in a common way?

37 Using Inheritance Still encapsulated from other objects SuperClass #Redundant Issue Conceptual Class A Class B Concrete We could use Inheritance. So long as we don't mind coupling these classes to a superclass, this resolves the redundancy while keeping the Issue encapsulated Using Delegation Class A Class B Class C +Redundant Issue Must be public for Class A and Class B to use it We could use Delegation. This exposes the Redundant issue as the interface of the service class (Class C). However, remember, the rule is encapsulate by policy, reveal by need. Eliminating redundancy is a definite need.

38 Patterns Promote Quality Client Context + request(strategy) Strategy + algorithm() Factory StrategyA + algorithm() StrategyB + algorithm() Cohesion: Each class is focused on a single responsibility Coupling: Base Strategy hides concrete types Redundancy : Anything common pushed into the base class Encapsulation: Factory hides types, design, implementation How the GoF Advice Promotes Quality Design to Interfaces: Helps eliminate redundant relationships Avoids subclass coupling Encapsulate Variation Promotes encapsulation Decouples client objects from the services they use Leads to component-based architectures Favor aggregation over inheritance Promotes strong cohesion Helps eliminate redundancies Makes designs more dynamic

39 Testability and Design copyright 2010 Net Objectives Inc. Testability and Design Considering how to test your objects before designing them is, in fact, a kind of design It forces you to look at: The public method definitions What the responsibilities of the object are Easy testability is tightly correlated to loose coupling and strong cohesion

40 Testability Code that is difficult to unit test is often: Tightly Coupled: "I cannot test this without instantiating half the system" Weakly Cohesive: "This class does so many things, the test will be enormous and complex!" Redundant: "I'll have to test this in multiple places to ensure it works everywhere" The Role of Testability Unit testing is a good thing. You should do it Whether you agree or not You should always ask yourself "if I were to test this, how would I do it?" If you find the design would be very hard to test, or if you cannot see a way to test it, ask yourself "why isn't this more testable?" This is a thought process that can capture coupling, cohesion, and redundancy issues that you might otherwise miss

41 Trim Tabs "If you try to change the course of a supertanker by pushing at the bow you will not see any change. If you push on the rudder your chances of changing the course of the supertanker are guaranteed, but the amount of energy needed is still prohibitive. To be the most effective we need to push on the trim tabs, those small fins on the end of the rudder, by moving them, the rudder in turn moves and the tanker makes its turn. R. Buckminster Fuller "Critical Path" ~3 Testable? Client Context + request(strategy) Strategy + algorithm() Factory StrategyA + algorithm() StrategyB + algorithm() MockStrgy + algorithm()

42 Design Patterns Patterns are not just about Design They are used in Architecture Design Testing Deployment Refactoring and analysis The Analysis Matrix copyright 2010 Net Objectives Inc.

43 Motivation Information overload More information than you need No good way to organize it No way to tell what is important No way to see what the cases are Motivation Example Designing a document control system that includes documents from: All airlines Most manufacturers Boeing, McDonell Douglas Pratt & Whitney, Rolls Royce, GE About 100 cases all told Documents are conceptually the same Collection of text and graphics Version control required

44 Example Requirements Document naming conventions ordered within a document 1, 2, 3, , 1-2, 1A, 1B, ordered across all documents ordered for every version of document do by type of sub-document (with all combinations above allowed) Document revision conventions Given sub-number from document being revised 1-1, 1-2, 1A, 1B, Given next number in line Handling Variation: An Example Let s say we ve been given these requirements: We have to build a sales order system for Canada and the United States. We want to calculate freight based on the country we re in. Money will also be handled by the country we are in. In the US, tax will be calculated by the locale. Use US Postal rules for verifying addresses. In Canada, use GST and PST for tax. Use Fed Ex for Canada shipping

45 Break Requirements Into Cases Distilling the requirements into cases: CASE 1: USA Customer Calculate freight based on UPS charges, use US Postal rules for verifying addresses and calculate tax based on sales and/or services depending upon locale. Handle money in US $ CASE 2: Canadian Customer Use Canadian $. Use Canadian Postal rules. Ship via Fed Ex to Canada and calculate tax based on GST and PST How to Start the Design Before we design anything, we should do some analysis of our problem domain We want to find what varies and encapsulate it An easy way to do this when the requirements are many, is to use something I call the analysis matrix This is simply a matrix where each column represents a given case. Each row is used to represent the concept that case is an example of We can start with a single requirement, and build this as we go. This can be much easier to manage

46 Start With One Calculate freight based on UPS charges, use US Postal rules for verifying addresses and calculate tax based on sales and/or services depending upon locale. Handle money in US$. Requirement (concept) One way to do it, in one case calculate freight US Sales use UPS rates Continue Calculate freight based on UPS charges, use US Postal rules for verifying addresses and calculate tax based on sales and/or services depending upon locale. Handle money in US$. calculate freight verify address US Sales use UPS rates use US Postal rules Different Concept Same Case

47 Continue Calculate freight based on UPS charges, use US Postal rules for verifying addresses and calculate tax based on sales and/or services depending upon locale. Handle money in US$. US Sales calculate freight use UPS rates verify address use US Postal rules calculate tax use state and local taxes money US $ More Concepts More Implementations for this Case Handle Canadian Case US Sales calculate freight use UPS rates verify address use US Postal rules calculate tax use state and local taxes money US $ Canadian Sales Canadian $ Existing Concept New Case Use Canadian$. Use Canadian Postal rules. Use Canadian shipper and calculate tax based on GST and PST.

48 Next Canadian Case US Sales Canadian Sales calculate freight use UPS rates verify address use US Postal rules Canadian Postal Rules calculate tax use state and local taxes money US $ Canadian $ Existing Concept Same Case Use Canadian$. Use Canadian Postal rules. Use Canadian shipper and calculate tax based on GST and PST. All Cases Handled US Sales Canadian Sales calculate freight use UPS rates use Canadian shipper verify address use US Postal rules use Canadian Postal rules calculate tax use state and local use GST and PST taxes money US $ Canadian $ Use Canadian$. Use Canadian Postal rules. Use Canadian shipper and calculate tax based on GST and PST.

49 A Note About Customers They usually know their problem domains very well Few think conceptually They often use the term always when the mean usually They often use the term never when the mean seldom They often say they have told me all of the cases when they have only told me what usually happens The German Case CASE 3: German Customer Use a German shipper, which has a maximum weight of 30 kilograms. Use Value Added Tax for taxes, European postal rules, and the dd/mm/yy date format. Currency used will be the Euro

50 New Case - German Sales US Sales Canadian Sales German Sales calculate freight use UPS rates use Canadian shipper use German shipper verify address use US Postal rules use Canadian Postal rules use European Postal rules calculate tax use state and local use GST and PST use VAT taxes money US $ Canadian $ Euro dates mm/dd/yyyy dd/mm/yyyy dd/mm/yyyy max weight 30 kg Are there maximum weights in US and Canada? Maybe not. Maybe so, and the customer forgot to mention them Now I have a good, specific question to ask My customers are good at answering specific questions Can Check Our Understanding US Sales Canadian Sales German Sales calculate freight use UPS rates use Canadian shipper use German shipper verify address use US Postal rules use Canadian Postal rules use European Postal rules calculate tax use state and local use GST and PST use German VAT taxes money US $ Canadian $ Euro dates mm/dd/yyyy dd/mm/yyyy dd/mm/yyyy max weight 70 lbs none 30 kg "Sometimes yes, sometimes no "

51 Does Get More Complicated Imagine there is a more complicated relationship between two concepts (say between calculating freight and address verification) in the US but not in the other cases Sometimes we can do a drill down to capture the extra complexity, when it is not needed in all cases Use Mini-Matrix for Complex Cases US Sales Canadian Sales calculate freight use UPS rates use Canadian shipper verify address use US Postal rules use Canadian Postal rules calculate tax use state and local use GST and PST taxes money US $ Canadian $ Calculate freight Use USPS Use UPS Verify Address Use US Postal Rules Use US Postal Rules no PO Boxes Pick-up charge N/A $5.00 $4.00 Use FedEx Use US Postal Rules Max weight 50 lbs 70 lbs No maximum

52 How To Use the Analysis Matrix Note how each column in the analysis matrix represents one particular case. In our case, this represents one nationality and a particular case in how it is to be handled Each entry can be thought of as an object Thinking of Elements as Objects US Sales Canadian Sales German Sales calculate USCalcFreight CanCalcFreight GermCalcFreight freight verify USAddrRules CanAddrRules GermanAddrRules address calculate tax USCalcTax CanCalcTax GermanCalcTax money USMoney CanMoney GermanMoney dates Date_mmddyy Date_ddmmyy Date_ddmmyy max weight USMaxWght CanMaxWght GermanMaxWght

53 How To Use the Analysis Matrix Each row represents different ways a rule may be implemented across all of the cases This sounds quite a bit like a Strategy pattern It can be implemented as such How do we handle the instantiation of the appropriate strategy objects? Using the Strategy Pattern calculate freight verify address calculate tax money date format max weight US Sales Canadian Sales German Sales The objects in this row can be implemented as a Strategy pattern encapsulating the calculate freight rule. The objects in this row can be implemented as a Strategy pattern encapsulating the verify address rule. The objects in this row can be implemented as a Strategy pattern encapsulating the calculate tax rule. We can use Money objects that can contain Currency and Amount fields that automatically convert as needed.. We can use Date objects that can display as required for the country the customer is in. The objects in this row can be implemented as a Strategy pattern encapsulating the max weight rule.

54 Concrete Implementation Rules: Columns calculate freight verify address calculate tax money date format max weight These implementations are used when we have a US customer. US Sales Canadian Sales German Sales These implementations are used when we have a Canadian customer. These implementations are used when we have a German customer. How Sales Order Will Work TaskController Sales Order should not couple to concrete types. It must have a factory to get the objects for it. SalesOrder CalcTax +taxamount():double USTax CanTax GermanTax AddressRules +validate():boolean USAddr CanAddr GermanAddr CalcFreight +taxamount():double USFreight CanFreight GermanFreight

55 How Can We Control Instantiation? We have two issues to deal with: 1. using the desired objects in a de-coupled way 2. instantiating the correct set Using the desired objects can be simplified with the Strategy Pattern To instantiate the correct set we need a way to instantiate a family of objects We can see the "sets" now, in our design, which gives us a motivation in how we create them We need an object factory here The Abstract Factory copyright 2010 Net Objectives Inc.

56 The Abstract Factory Pattern We need to create families of objects for particular situations. That is, particular clients need particular sets of instantiations GoF Intent: Provide an interface [a set of methods] for creating families of related or dependent objects without specifying their concrete classes * *Design Patterns, Elements of Reusable Object-Oriented Software, Gamma, Helm, Johnson, Vlissides The Abstract Factory Pattern The Abstract Factory pattern gives us a way to instantiate the legitimate a set of objects corresponding to a particular case It will build the allowable combinations only but it also encapsulates something else

57 The Cases are hidden a c F t o r y US Case I n t e... Canada Case r f a c e Here, we hide country. The notion only appears in the factory. What s the advantage? Classes of the Abstract Factory

58 The "Abstract Factory" Why is this pattern called "The Abstract Factory"? Using the Abstract Factory calculate freight verify address calculate tax money date format max weight These objects can be coordinated with the use of the Abstract Factory pattern. US Sales Canadian Sales German Sales T These objects can be coordinated with the use of the Abstract Factory pattern. These objects can be coordinated with the use of the Abstract Factory pattern. Abstractions

59 The Abstract Factory in Action The Abstract Factory in Action

60 The Abstract Factory in Action The Abstract Factory in Action

61 The US Case: Sequence Diagram The Canada Case: Sequence Diagram

62 C# Implementation of Factories abstract class AbstractFactory { abstract CalcTax MakeCalcTax(); abstract CalcFreight MakeCalcFreight(); abstract AddressRules MakeAddrRules(); public static AbstractFactory GetAFtoUse(customerID){ // Decide whether to return // instance of USAF CanAF } } class USAF : AbstractFactory { public override CalcTax MakeCalcTax() { return new USTax(); } public override CalcFreight MakeCalcFreight() { return new USFreight(); } public override AddressRules MakeAddrRules() { return new USAddr(); } } class CanAF : AbstractFactory { public override CalcTax MakeCalcTax() { return new CanTax(); } public override CalcFreight MakeCalcFreight() { return new CanFreight(); } public override AddressRules MakeAddrRules() { return new CanAddr(); } } class SalesOrder { private CalcTax mytax; private CalcFreight myfreight; private AddressRules myaddr; public SalesOrder (AbstractFactory myaf) { mytax= myaf.makecalctax(); myfreight= myaf.makecalcfreight(); myaddr= myaf.makeaddrrules(); } } C# C# Interfaces interface CalcTax { public double CalcTax (double qty, int id); } interface AddressRules { public bool Verify (Address myaddress); } interface CalcFreight { public double CalcFreight ( string fromcode, string tocode, string frghtclass, double weight); }

63 C# Putting It Together // In the tier controller, or similar AbstractFactory myaf = AbstractFactory. getaftouse( customerid); mysalesorder = new SalesOrder( myaf); // mysalesorder is now set up to use the correct strategies, etc. What Variations Can Occur? What if we add a new country Uses existing variations (France uses Euro) New Factory for France Use existing Euro object Has a new implementation of a concept (no VAT in Italy) New Factory for Italy New "ItalyTax" object Have a new requirement for UK only Certain products (pharmaceuticals) pay no tax if over 65 How can you avoid changing the interface of calctax? Introduces a brand new concept (China!) Trade Restrictions in China Everything will have to be maintained

64 Vulnerability In design, our greatest vulnerability is often: A wrong or missing abstraction A Note on the Abstract Factory The Abstract Factory Pattern says to define an interface for the instantiation of objects In practice, there are several ways to implement an Abstract Factory

65 Abstract Factory Variations 1. Extend an abstract type 2. Make a concrete factory object where each creation method contains a switch (based on a common variable: nationality) 3. Make a concrete factory object that is driven from a configuration file 4. Use run-time class loading driven by a database C# Single Object with Switch // do same for each method CalcTax makecalctax (string ID) { optionnum= Config.getCalcTaxOption(ID); switch (optionnum) { case option1: return new CalcTax1(); case option2: return new CalcTax2();... } } // do same for each method ~3

66 C# Single Object with Database CalcTax makecalctax (string ID) { string record[]; record= Database.getRecord( ID); string classtoinstantiate; classtoinstantiate= record[calc_tax]; // CALC_TAX // holds column # //instantiate the object //classtoinstantiate needs to be in Namespace.class format CalcTax mycalctax = (CalcTax) Activator.CreateInstance(Type.GetType(classToInstantiate)); } ~3 The Adapter Pattern copyright 2010 Net Objectives Inc.

67 The Adapter Pattern We need to change the interface of a class that has the right stuff but has the wrong interface GoF Intent: Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn t otherwise because of incompatible interfaces* *Design Patterns, Elements of Reusable Object-Oriented Software, Gamma, Helm, Johnson, Vlissides Our Problem Shape + setlocation() + getlocation() + display() + fill() + setcolor() + undisplay() Point + display() + fill() + undisplay() Line + display() + fill() + undisplay() Square + display() + fill() + undisplay()

68 What We Have XX_Circle + set_location() + get_location() + display_it() + fill_it() + set_its_color() + undisplay_it() What We Want XX_Circle to behave like a Shape to a Client object Unfortunately, we cannot get polymorphism with XX_Circle: XX_CIRCLE = Shape

69 Our Problem Our client can t behave with our XX_Circle in the same way it does with the Square because XX_Circle is not a Shape Author of XX_Circle may not be willing or able to change XX_Circle s interface How to Implement the Pattern Shape + setlocation() + getlocation() + display() + fill() + setcolor() + undisplay() Point Line Square Circle XX_Circle + display() + fill() + undisplay() + display() + fill() + undisplay() + display() + fill() + undisplay() + display() + fill() + getlocation() + setlocation() + setcolor() + undisplay() + set_location() + get_location() + display_it() + fill_it() + set_its_color() + undisplay_it() If circle contained an XX_circle, it could handle the "communication with the client and let XX_circle handle the work

70 C# Example class Circle : Shape { private XX_circle pxc; public Circle () { pxc= new XX_circle(); } } public void override display() { pxc.display_it(); } General Approach If we want a client object to work with objects from two other classes we are writing in the same way without "knowing" which one it has, then either: We create an Interface (if we re in Java or C#) or an abstract class And have each class implement/derive from the interface/abstract class If we are using objects from two classes, then we may need to adapt one or both of them This is also called "wrapping but the more specific terms is preferred (decorators, proxies, and façades are also called wrappers )

71 The Bridge Pattern copyright 2010 Net Objectives Inc. The Bridge Pattern GoF Intent: De-couple an abstraction from its implementation so that the two can vary independently * The normal reaction to reading this is: Huh?" Mine was: How come I understand every word in this sentence but I have no idea what it means? *Design Patterns, Elements of Reusable Object-Oriented Software, Gamma, Helm, Johnson, Vlissides

72 Rectangle Drawing Program C# Code Example abstract class Rectangle { private int _x1, _y1, _x2, _y2; void public Draw () { DrawLine(_x1,_y1,_x2,_y1); DrawLine(_x2,_y1,_x2,_y2); DrawLine(_x2,_y2,_x1,_y2); DrawLine(_x2,_y1,_x1,_y1); } abstract void DrawLine( double x1, double y1, double x2, double y2); } class V1Rectangle : Rectangle { void override DrawLine( double x1, double y1, double x2, double y2) { DP1.draw_a_line( x1,y1,x2,y2); } } class V2Rectangle : Rectangle { void override DrawLine(double x1, double y1, double x2, double y2) { DP2.drawline( x1,x2,y1,y2); } }

73 Get New Requirements Told we must now handle Circles We decide to handle it in a similar way Make a V1Circle class and a V2Circle class Decouple the client from the specific shapes by deriving them from a common base class Handling New Shape Class

74 Handling New Shape Class C# Code Example abstract class Shape { public abstract void draw(); } abstract class Rectangle : Shape { private int _x1, _y1, _x2, _y2; public override void draw() { drawline(_x1, _y1, _x2, _y1); drawline(_x2, _y1, _x2, _y1); drawline(_x2, _y2, _x1, _y2); drawline(_x1, _y2, _x1, _y1); } abstract void drawline( double x1, double y1, double x2, double y2); } } class V1Rectangle : Rectangle { public override void drawline( double x1, double y1, double x2, double y2){ DP1.draw_a_line(x1,y1, x2, y2); } } class V2Rectangle : Rectangle { public override void drawline( double x1, double y1, double x2, double y2){ DP2.drawline(x1, x2, y1, y2); } } abstract class Circle : Shape { private double _x, _y, _r; public override void draw () { drawarc( _x, _y, _r, 0, 360); } abstract void drawarc( double x, double y, double r, double a1, double a2); } class V1Circle : Circle { protected override void drawarc(double x, double y, double r, double a1, double a2){ DP1.draw_an_arc(x,y,r,a1,a2); } } class V2Circle : Circle { protected override void drawarc(double x, double y, double r, double a1, double a2){ DP2.drawarc(_r,_x,_y,a1,a2); } }

75 Redundant Relationships Did We Resolve the Redundancy?

76 Don't Trade One Redundancy for Another Problems with this Approach Doesn t scale well If we add another type of Shape, we have 6 implementations Number of implementations will equal # types of Shapes times # of drawing programs Redundant Clearly accessing each of the drawing programs across the different types of Shapes will involve duplication or require greater modularization There will be many redundancies between V1Rectangle and V2Rectangle, etc Static Must make new objects when any issue varies at runtime

77 Intent Makes Sense Now *GoF Intent: De-couple an abstraction from its implementation so that the two can vary independently Abstraction: The entity, what something is. In this case Shape Implementation: What something does. In this case, the drawing behavior Drawing *Design Patterns, Elements of Reusable Object-Oriented Software, Gamma, Helm, Johnson, Vlissides Discovering the Bridge Pattern We use the following approach to discover the Bridge pattern 1. Find what is common in the problem domain 2. Define an abstraction to represent each common concept 3. Determine the nature of the variations, and create concrete entities Lastly: Observe how these abstractions relate to each other

78 We Have the Following Commonalities Our Shape class represents our commonality of abstraction. It represents a varying entity. We also have a behavioral implementation which varies CVA separates these issues into is-a relationships Derive Variations

79 Determine Remaining Relationships Which Way? Don't want them down here: "Design to Interfaces Use Qualities to Define Relationship Find different ways these CVA structures can work together: Shapes use drawing programs to draw themselves Client gives drawing program a shape to draw A Manager coordinates them both Whichever has better qualities is what we want (whether it happens to be a pattern or not) New patterns can be discovered in this way

80 Scoring Loose Coupling Strong Cohesion No Redundancy Encapsulation Testable Focus Shapes use DP DP given Shape 3 rd Module Shapes Using Drawing Programs

81 Drawing Programs Using Shapes Control Program Using Shapes

82 Scoring Shapes use DP DP given Shape Loose Coupling Yes DPs coupled to Shapes Strong Cohesion Yes DPs concerned with Shapes No Redundancy Yes Knowledge of shapes duplicated in DPs Encapsulation implementation and type implementation only Testable N + M N * M N + M Assertive Yes No No Focus Yes Shapes spread out a little Shapes using DPs wins! 3 rd Module Module coupled to Shapes Weak: Shape and Draw stuff Knowledge of shapes duplicated in CP implementation only Yes ~3 Add the Relationship The Adapter Pattern

83 Illustrating the Separation Abstraction Implementation C# Example Implementation class Client { } public static void Main (String argv[]) { Shape s1; Shape s2; Drawing dp; } // See comments below to see what // gets returned dp= Factory.getDP(); s1= Factory.getShape(dp); dp= Factory.getDP(); s2= Factory.getShape(dp); s1.draw(); s2.draw(); // Factory: // first call: getdp returns V1Drawing // first call: getshape returns // new Rectangle(dp,1,1,2,2); abstract class Shape { private Drawing _dp; } Shape (Drawing dp) { _dp= dp; } abstract void draw (); protected void drawline ( double x1, double y1, double x2, double y2) { _dp.drawline( x1, y1, x2, y2); } protected void drawarc ( double x, double y, double radius, double fromangle, double toangle){ _dp.drawarc( x,y,radius, fromangle, toangle); } // second call: getdp returns V2Drawing // second call: getshape returns // new Circle( dp,2,2,4);

84 C# Example Continued class Rectangle : Shape { Rectangle : base(dp) (Drawing dp, double x1, double y1, double x2, double y2) { _x1= x1; _y1= y1; _x2= x2; _y2= y2; } public override void draw () { drawline(_x1, _y1, _x2, _y1); drawline(_x2, _y1, _x2, _y2); drawline(_x2, _y2, _x2, _y1); drawline(_x2, _y1, _x1, _y1); } } class Circle : Shape { Circle : base(dp)(drawing dp, double x, double y, double radius) { _x= x; _y= y; _radius= radius; } public override void draw () { drawarc(_x,_y,_radius, 0, 360); } } abstract class Drawing { abstract void drawline ( double x1, double y1, double x2, double y2); abstract void drawarc( double x,double y,double radius, double fromangle, double toangle); } class V1Drawing : Drawing { public override void drawline ( double x1, double y1, double x2, double y2) { DP1.draw_a_line( x1, y1, x2, y2); } public override void drawarc ( double x, double y, double radius, double fromangle, double toangle) { DP1.draw_an_arc( x, y,radius, fromangle,toangle); } } C# Example Continued class V2Drawing : Drawing { public override void drawline ( double x1, double y1, double x2, double y2) { DP2.drawline( x1, x2, y1, y2); } public override void drawarc ( double x, double y, double radius, double fromangle, double toangle) { DP2.drawarc(radius, x, y, fromangle, toangle); } } class DP1 { static void draw_a_line ( double x1, double y1, double x2, double y2) { // draw_a_line implementation given to us } static void draw_an_arc( double x, double y, double radius, double from_angle, double to_angle) { // draw_an_arc implementation given to us } } class DP2 { static void drawline ( double x1, double y1, double x2, double y2) { // drawline implementation given to us } static void drawarc( double radius, double x, double y, double fromangle, double toangle) { // drawarc implementation given to us } }

85 Canonical Bridge Pattern Abstraction + operation() Implementation + opimp1() + opimp2() Concrete1 operation() { im p.opim p1() } Concrete2 operation() { imp.opimp2() } ImpA + opimp1() + opimp2() ImpB + opimp1() + opimp2() Bridge Pattern and the GoF Advice (1) Find what varies and (2) Encapsulate it. Use inheritance to categorize. (3) Design to Interfaces (2) (3) (2) (1) (1) (1) (1)

86 Another Way to Think of Bridge Consider the following: The cost of having a common interface for the implementation The benefits of separating the issues, testability, cohesion, clarity, extensibility, etc If the benefits are greater than the cost, use it If not, the pattern tells you Don t use me! The Two Designs Bridge Strategy

87 Comparing Strategy and Bridge Strategy Bridge Contains variation of behavior? Yes Yes Behaviors are isolated Yes No, dependant Risk of Interface Bloat No Yes Open-Closed to How many variations are encapsulated New behavior 1 3 New entity, behavior, way of using behaviors The Façade copyright 2010 Net Objectives Inc.

88 The Façade Pattern We want to use a sub-set of the functionality of a complex system, or to simplify its interface, or to improve how it is used, or to provide OO access to a non-oo system GoF Intent * : Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use *Design Patterns, Elements of Reusable Object-Oriented Software, Gamma, Helm, Johnson, Vlissides 8 of Manuals: One Complex System

89 Using a Complex System If you were in a group of developers that had to use parts of a complex system, would you: A. have everyone learn how to use it? B. draw straws where the loser had to learn it and make a set of classes for you to use? If you picked B, what that person created would be a Façade Insulating Ourselves From the Complex System Façade

90 Standard Façade vs. Encapsulating Facade The Façade normally is used to simplify the use of a complex system However, clients may use it or not -- they may use the complex system directly too An Encapsulating Façade restricts access to the complex system -- clients must use the Façade This has advantages Advantages of the Encapsulating Façade The Façade itself can be varied, using polymorphism, to allow for: Testing (Dummy Façade) Marketing/Presentations - Demonstration Façade is used to simulate a remote system Training "Demo" versions of commercial software etc

91 Comparing Façade With Adapter Client? which pattern? Pre-Existing Pre-Existing, or Foreign classes? Is there an existing interface we must adhere to? Are we trying to enable polymorphism? Are we creating a new interface for simplification? Is statefullness a concern? Façade Yes No No Yes Yes, Façades tend to be large Adapter Yes Yes Usually No Not usually Adapter and Façade Mean: Defer Having to Worry About Your Interface You can use the Adapter and Façade patterns to make the interfaces of classes you have been given to be exactly the way you want them to This is an example of design by context. First figure out what you want, then adapt (or simplify with a Facade) the interface to how you want it

92 The Thought Process of Patterns Programming by Intention copyright 2010 Net Objectives Inc. C#/Java/ Programming by Intention "Sergeant" Method public void printreport (String CustomerID) { } Employee[] emps = getemployees(customerid); if(needssorting(emps)) sortemployees(emps); printheader(customerid); printformattedemployees(emps); printfooter(customerid); paginate(); "Private"* Methods *Note: These methods may not be literally private, as we may need to make some of them public or protected for testing. But we treat them as private from client objects, to limit coupling.

93 The Thought Process of Patterns Shalloway s Law copyright 2010 Net Objectives Inc. Shalloway s Law If N things need to change and N>1, Shalloway will find at most N-1 of these things

94 Shalloway s Principle Avoid situations where Shalloway s Law Applies The Thought Process of Patterns Encapsulate that! copyright 2010 Net Objectives Inc.

95 Our Situation We have multiple processors in a real-time environment. We know there will be a performance problem. We just don t know where / how. What can we do? Our Options 1. Figure out where / how the performance problem will show up. 2. Just use what appears best at first and fix it later if it becomes clear later that we need something else 3. Use Scott Bain s magic consultant card ~3

96 Scott Bain s Magic Consultant Card Scott, a Net Objectives Design Patterns Instructor, has a magic card that tells you how to solve design problems It requires, however, that you explicitly and concisely state what your problem is Fortunately, we know what our problem is: We do not know the nature of the collection we need ~3 Instructions for Using the Magic Consultant Card 1. Hold magic card face down in front of you 2. State aloud three times what your problem is 3. Flip the card over 4. Read the card ~3

97 Using the Magic Consultant Card "Encapsulate That" ~3 Limits of the Magic Consulting Card and Where Design Patterns Help First the good news the magic card is always right! Now the bad news it doesn t tell you how to do what it tells you to do! That s where design patterns come in Encapsulate what varies ~3

98 Summary Attend to code qualities Gang of Four Advice Design to interfaces Delegate Encapsulate what varies Use testability as a design tool Program by intention Encapsulate Shalloway s Principle Patterns hide variation Net Objectives Talks At Conference Monday 8:30-12:00pm Eight Steps to Kanban. Ken Pugh Tuesday 8:30-12:00pm Scaling Agile with the Lessons of Lean Product Development Flow. Alan Shalloway 1:00-4:30pm Design Patterns Explained: From Analysis Through Implementation. Alan Shalloway Wednesday 3:45-5:00 Lean Development Practices for Enterprise Agile. Alan Shalloway Thursday Keynote :00pm Form Follows Function: The Architecture of a Congruent Organization. Ken Pugh Register at for slides & more _s

99 Thank You! Register at See Contact me at Twitter copyright 2010 Net Objectives Inc. Q U E S T I O N S? Lean for Executives Product Portfolio Management Business Product Owner technical Team process Lean-Agile Kanban / Scrum ATDD / TDD / Design Patterns Business Lean Enterprise Manage ment Lean Management Project Management ASSESSMENTS CONSULTING TRAINING COACHING For more info on free resources see: