Design Patterns CSCI 5801: Software Engineering. Design Patterns.

20
Design Patterns CSCI 5801: Software Engineering

Transcript of Design Patterns CSCI 5801: Software Engineering. Design Patterns.

Page 1: Design Patterns CSCI 5801: Software Engineering. Design Patterns.

Design Patterns

CSCI 5801: Software Engineering

Page 2: Design Patterns CSCI 5801: Software Engineering. Design Patterns.

Design Patterns

Page 3: Design Patterns CSCI 5801: Software Engineering. Design Patterns.

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)

Page 4: Design Patterns CSCI 5801: Software Engineering. Design Patterns.

Design Patterns• Creational Patterns

– Abstract Factory– Builder– Factory Method– Prototype– Singleton

• Structural Patterns– Adapter– Bridge– Composite– Decorator – Façade– Flyweight– Proxy

• Behavioral Patterns– Chain of Responsibility– Command– Interpreter– Iterator– Mediator– Memento– Observer– State– Strategy – Template Method– Visitor

Page 5: Design Patterns CSCI 5801: Software Engineering. Design Patterns.

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.

Page 6: Design Patterns CSCI 5801: Software Engineering. Design Patterns.

Iterator Pattern

Page 7: Design Patterns CSCI 5801: Software Engineering. Design Patterns.

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).

Page 8: Design Patterns CSCI 5801: Software Engineering. Design Patterns.

Adapter Pattern

Page 9: Design Patterns CSCI 5801: Software Engineering. Design Patterns.

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.

Page 10: Design Patterns CSCI 5801: Software Engineering. Design Patterns.

Memento Pattern

Page 11: Design Patterns CSCI 5801: Software Engineering. Design Patterns.

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.

Page 12: Design Patterns CSCI 5801: Software Engineering. Design Patterns.

Observer Pattern

Page 13: Design Patterns CSCI 5801: Software Engineering. Design Patterns.

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

Page 14: Design Patterns CSCI 5801: Software Engineering. Design Patterns.

Builder Pattern

Page 15: Design Patterns CSCI 5801: Software Engineering. Design Patterns.

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.

Page 16: Design Patterns CSCI 5801: Software Engineering. Design Patterns.

Façade Pattern

Page 17: Design Patterns CSCI 5801: Software Engineering. Design Patterns.

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.

Page 18: Design Patterns CSCI 5801: Software Engineering. Design Patterns.

Chain of Responsibility

Page 19: Design Patterns CSCI 5801: Software Engineering. Design Patterns.

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.

Page 20: Design Patterns CSCI 5801: Software Engineering. Design Patterns.

Factory Pattern