Design Patterns

1. Design Patterns CSCI 5801: Software Engineering

2. Design Patterns

3. Design Patterns • Standard “toolbox” of design ideas • Usually codify solutions to common problems within system design • Usually support the major data classes within a system by helping them communicate • Identify major data classes • Identify the design pattern classes • Not at overall architecture level(but often used to implement common components within an architecture)

4. Design Patterns • Behavioral Patterns • Chain of Responsibility • Command • Interpreter • Iterator • Mediator • Memento • Observer • State • Strategy • Template Method • Visitor • Creational Patterns • Abstract Factory • Builder • Factory Method • Prototype • Singleton • Structural Patterns • Adapter • Bridge • Composite • Decorator • Façade • Flyweight • Proxy

5. Iterator Pattern • Provides way to access elements of an aggregate object sequentially without knowing representation • Example: User classes would like to get students in a Roster without having to deal with array, linked list, or however Roster stores it.

6. Iterator Pattern

7. Adapter Pattern • Converts the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. • Example:An updated roster must be stored in the roster database. You would like to separate the business logic of the Roster class from specific SQL commands and other details such as the type of database server (which might change in the future).

8. Adapter Pattern

9. Memento Pattern • Without violating encapsulation, capture and externalize an object’s internal state so than the object can be restored to this state later. • Example:Students may change their mind after adding a course. You need to implement an “undo” button that undoes up to the last five changes made.

10. Memento Pattern

11. Observer Pattern • Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. • Example:The registrar maintains a list of all open sections. When a section is opened or closed (due to students dropping or adding), that list must be updated.

12. Observer Pattern

13. Builder Pattern • Separate the construction of a complex object from its representation so that the same construction process can create different representations. • Example:You must be able to create many different ways to display a roster to users, including HTML, Excel, and PDF

14. Builder Pattern

15. Façade Pattern • Provide a unified interface to a set of interfaces in a subsystem. Façade defines a higher-level interface that makes a subsystem easier to use. • Example:When a section is created, a number of complex properties can be set, including days of the week and times and rooms for each day. While objects for all of these exist, most users don’t want to use them directly.

16. Façade Pattern

17. Chain of Responsibility • Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along until an object handles it. • Example:When a new section is created, a number of checks must be made in order to insure it does not conflict with other sections. These checks may need to be changed over time as the system evolves.

18. Chain of Responsibility

19. Factory Pattern • Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses. • Example:A project section is a section that does not have a room or time. However, we do not know whether to create a project section or a regular section until certain information has been provided.

20. Factory Pattern