1. Chapter 6 Introduction to Design Patterns (Part I) COSC 4346: Software Engineering I Dr. Lappoon R. Tang

2. Overview o Recurring Design Purposes o What are Design Patterns? o The abstract factory pattern

3. Readings o Section 6.1 o Section 6.2

4. Review: Sample Design Goals and Ways to Accomplish Them Reusability, Flexibility, and Maintainability oReuse flexible designs oKeep code at a general level oMinimize dependency on other classes Robustness oReuse reliable designs oReuse robust parts Sufficiency / Correctness oModularize design oReuse trusted parts Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

5. Case study: KitchenViewer o Suppose we want to create an application KitchenViewer that can display a design for our kitchen oWall cabinet oCounter oFloor cabinet o The application can also render a style for the kitchen oModern oClassic oAntique oArts & Crafts

6. KitchenViewer Interface Wall cabinet Counter Floor cabinet ModernClassicAntiqueArts & Crafts menu display area styles Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

7. KitchenViewer Example ModernClassicAntiqueArts & Crafts Wall cabinets Floor cabinets Countertop Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

8. Selecting Antique Style ModernClassicAntiqueArts & Crafts Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

9. Design Goals vs. Design Purposes o A design goal (such as reusability) is generally too high level o When confronted with an actual design problem, one needs to translate a goal into specific design purpose oExample: A goal is to reuse a part of a calendar application, it may be translated into a specific design purpose to parameterize a set of methods so that they can be applied to any day, month, year

10. Design Purpose: KitchenViewer o Suppose our design goal here is flexibility o To achieve the goal, what should be our design purpose? oExample: the procedure for rendering various styles is basically the same, there should be no need for more than one copy of this procedure renderKitchen() o More precisely, the design purpose can be stated as follows: oAn application must construct a family of objects at runtime: The design must enable choice among several styles

11. What are Design Patterns? o Class combinations and accompanying algorithms that fulfill common design purposes o A design pattern expresses an idea rather than a fixed class combination oAccompanying algorithms express the patterns basic operation

12. What are Design Patterns? o Design patterns express an idea instead of specific details oExample: In house building, the term ranch style denotes a useful house pattern; it is an idea only, the specific details in building the house according to ranch style has yet to be worked out

13. Bad example first: without design patterns // Sample code for renderKitchen() – version ignoring design purpose // Determine the style... // Case statement // Assume that the antique style was selected. // Create the antique wall cabinets AntiqueWallCabinet antiqueWallCabinet1 = new AntiqueWallCabinet(); AntiqueWallCabinet antiqueWallCabinet2 = new AntiqueWallCabinet();... // Create the antique floor cabinets AntiqueFloorCabinet... // Create the kitchen object, assuming the existence of add() method Kitchen antiqueKitchen = new Kitchen(); antiqueKitchen.add(antiqueWallCabinet1,...); // rest of parameters specify location antiqueKitchen.add(antiqueWallCabinet2,...); // Add antique floor cabinets to the kitchen... // Render antiqueKitchen...

14. Bad example first: without design patterns renderKitchen() uses the classes Kitchen, WallCabinet, FloorCabinet oThis method is placed in a class called Client (conceptually the application class or a class to be used by the application class) o As you can see, the code is going to be repetitive, inflexible, and hardly reusable oOne copy of such code is needed for every type of style (e.g. modern)

15. KitchenViewer Without Design Patterns Kitchen Client renderKitchen() FloorCabinet ModernWallCabinet ModernFloorCabinetAntiqueFloorCabinet AntiqueWallCabinet WallCabinet Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

16. Design Goal At Work: Flexibility Our design should be flexible enough to produce any of the several kitchen styles. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

17. How do we deal with the problem? Problem: … new AntiqueWallCabinet(); o Applies only to antique style because objects of the class AntiqueWallCabinet can only access methods related to rendering antique wall cabinets Solution: o … myStyle.getWallCabinet(); The class of the object myStyle will check at runtime which style (e.g. antique or modern?) is being rendered and then the corresponding method for rendering is used.

18. AntiqueKStyle getWallCabinet() getFloorCabinet() The Abstract Factory Idea KitchenStyle getWallCabinet() getFloorCabinet() ModernKStyle getWallCabinet() getFloorCabinet() WallCabinetFloorCabinet AntiqueWallCabinetAntiqueFloorCabinet FloorCabinet getFloorCabinet() { return new AntiqueFloorCabinet(); } …… FloorCabinet getFloorCabinet() { return new ModernFloorCabinet(); } Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

19. Abstract Factory Design Pattern Applied to KitchenViewer KitchenStyle getWallCabinet() getFloorCabinet() Kitchen getWallCabinet() getFloorcabinet() Client renderKitchen( KitchenStyle ) ModernKStyle getWallCabinet() getFloorCabinet() AntiqueKStyle getWallCabinet() getFloorCabinet() WallCabinetFloorCabinet ModernWallCabinet ModernFloorCabinet AntiqueWallCabinet AntiqueFloorCabinet Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

20. Abstract Factory Design Pattern Applied to KitchenViewer // renderKitchen(KitchenStyle* myStyle) – using design pattern // Note: Code is adapted for C++. // Create wall cabinets, type decided by the class of myStyle WallCabinet* wallCabinet1 = myStyle -> getWallCabinet(); WallCabinet* wallCabinet2 = myStyle -> getWallCabinet();... // Create floor cabinets FloorCabinet* floorCabinet1 = myStyle -> getFloorCabinet(); FloorCabinet* floorCabinet2 = myStyle -> getFloorCabinet();... Kitchen kitchen = new Kitchen(); kitchen.add(wallCabinet1,...); kitchen.add(wallCabinet2,...);... // Add floor cabinet to kitchen

21. Abstract Factory Design Pattern Style getComponentA() getComponentB() Client doOperation( Style myStyle ) Style1 getComponentA() getComponentB() Style2 getComponentA() getComponentB() ComponentAComponentB Style1ComponentA Style1ComponentB Style2ComponentA Style2ComponentB Collection Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

22. Abstract Factory Design Pattern Alternative Style getComponentA() getComponentB() Client doOperation() Style1 getComponentA() getComponentB() Style2 getComponentA() getComponentB() ComponentAComponentB Style1ComponentA Style1ComponentB Style2ComponentA Style2ComponentB Collection getComponentA() getComponentB() Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

23. Key Concept: Design Pattern -- Definition: class combination and algorithms that fulfill a common design purpose. The abstract factory pattern: * Achieves design purposes derived from the design quality flexibility * Key ideas: o Parameterize the methods that are supposed to be flexible and easily extendable o Make the class containing the flexible methods depend on or aggregate an abstract class to which new sub-classes (thus new functionalities) can be added. o Make the sub-classes of the abstract class in turn depend on sub-classes of other abstract classes needed by the design Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.