1. CS212: Object Oriented Analysis and Design Lecture 38: Design Pattern-II

2. Recap of Lecture 37 Design Pattern Pattern everywhere Pattern in computation Design pattern Iterator Patter Gang of Four Pattern

3. Outline of Lecture 38 GoF Pattern Abstract Factory Singleton Adapter

4. Pros of Design Patterns Help capture and disseminate expert knowledge. Promotes reuse and avoid mistakes. Provide a common vocabulary: Help improve communication among the developers. Reduce the number of design iterations: Help improve the design quality and designer productivity. Mar-15Software Engineering

5. Pros of Design Patterns Patterns solve software structural problems attributable to: Abstraction, Encapsulation Information hiding Separation of concerns Coupling and cohesion Separation of interface and implementation Single point of reference Divide and conquer Mar-15Software Engineering

6. Cons of Design Patterns Design patterns do not directly lead to code reuse. To help select the right design pattern at the right point during a design exercise Mar-15Software Engineering

7. Mar-15 Catalogue of Design Patterns (GoF) Software Engineering

8. Abstract Factory: Intent Provide an interface for creating families of objects A hierarchy that encapsulates Construction of a suite of "products" The new operator considered harmful

9. Abstract Factory: Problem If an application is to be portable, it needs to encapsulate platform dependencies platform : windowing system, OS, database, etc. Lots of #ifdef case statements

10. Abstract Factory: Discussion Abstracts the creation of families of related or dependent objects Without directly specifying their concrete classes The "factory" object has the responsibility for providing creation services for the entire platform family Clients never create platform objects directly, they ask the factory to do that for them. It is routinely implemented as a Singleton

11. Abstract Factory: Structure

12. Abstract Factory: Example

13. Abstract Factory: Check List Map out a matrix of "platforms" versus "products". Define a factory interface that consists of a factory method per product. Define a factory derived class for each platform that encapsulates all references to the new operator. The client should retire all references to new, and use the factory methods to create the product objects. Demonstration: abstractFactory.cpp

14. Singleton: Intent Ensure a class has only one instance Provide a global point of access to it. Encapsulated "just-in-time initialization“ "initialization on first use".

15. Singleton: Problem Application needs one, and only one, instance of an object. Lazy initialization and global access are necessary.

16. Singleton: Discussion Make the class of the single instance object responsible for creation, initialization, access, and enforcement. Declare the instance as a private static data member. Provide a public static member function that encapsulates all initialization code, and provides access to the instance.

17. Singleton: Structure Make the class of the single instance responsible for access and "initialization on first use". The single instance is a private static attribute. The accessor function is a public static method.

18. Singleton: Example

19. Singleton: Checklist Define a private static attribute in the "single instance" class. Define a public static accessor function in the class. Define all constructors to be protected or private. Clients may only use the accessor function to manipulate the Singleton. Demonstration: singleton.cpp

20. Mar-15 Catalogue of Design Patterns (GoF) Software Engineering

21. Adapter: 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. Wrap an existing class with a new interface. Impedance match an old component to a new system

22. Adapter: Problem An "off the shelf" component Offers compelling functionality that you would like to reuse

23. Adapter: Discussion Reuse has always been painful and elusive Something not quite right between the old and the new Creating an intermediary abstraction that translates Adapter functions as a wrapper or modifier of an existing class. It provides a different or translated view of that class.

24. Adapter: Structure

26. Adapter: Example Allows otherwise incompatible classes to work together Converting the interface of one class into an interface expected by the clients.

27. Adapter: Check list Identify the players: the client, the adaptee Identify the interface that the client requires Design a "wrapper" class that can "impedance match“ The adapter/ wrapper class "has a" instance of the adaptee class The adapter/wrapper class "maps" the client interface to the adaptee interface. The client uses (is coupled to) the new interface

28. Thank you Next Lecture: Design Pattern