1 / 15

Software Design Patterns (1)

Software Design Patterns (1). Introduction. patterns do … & do not …. Patterns do... • provide common vocabulary • provide “shorthand” for effectively communicating complex principles • help document software architecture • capture essential parts of a design in compact form

Download Presentation

Software Design Patterns (1)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Software Design Patterns (1) Introduction

  2. patterns do … & do not … Patterns do... • provide common vocabulary • provide “shorthand” for effectively communicating complex principles • help document software architecture • capture essential parts of a design in compact form • show more than one solution • describe software abstractions Patterns do not... • provide an exact solution • solve all design problems • only apply for object-oriented design

  3. non-generative / generative Patterns can be • non-generative (Gamma patterns) – observed in a system – descriptive and passive • generative – generate systems or parts of systems – prescriptive and active

  4. types of patterns • Creational patterns: • Deal with initializing and configuring classes and objects • Structural patterns: • Deal with decoupling interface and implementation of classes and objects • Composition of classes or objects • Behavioural patterns: • Deal with dynamic interactions among societies of classes and objects • How they distribute responsibility

  5. creational (software) patterns • Abstract Factory: • Factory for building related objects • Builder: • Factory for building complex objects incrementally • Factory Method: • Method in a derived class creates associates • Prototype: • Factory for cloning new instances from a prototype • Singleton: • Factory for a singular (sole) instance

  6. structural (software) patterns • Adapter: • Translator adapts a server interface for a client • Bridge: • Abstraction for binding one of many implementations • Composite: • Structure for building recursive aggregations • Decorator: • Decorator extends an object transparently • Facade: • Simplifies the interface for a subsystem • Flyweight: • Many fine-grained objects shared efficiently. • Proxy: • One object approximates another

  7. behavioural (software) patterns • Chain of Responsibility: • Request delegated to the responsible service provider • Command: • Request is first-class object • Iterator: • Aggregate elements are accessed sequentially • Interpreter: • Language interpreter for a small grammar • Mediator: • Coordinates interactions between its associates • Memento: • Snapshot captures and restores object states privately

  8. behavioural (software) patterns (cont.) • Observer: • Dependents update automatically when subject changes • State: • Object whose behaviour depends on its state • Strategy: • Abstraction for selecting one of many algorithms • Template Method: • Algorithm with some steps supplied by a derived class • Visitor: • Operations applied to elements of a heterogeneous object structure

  9. creational pattern example : abstract factory “The abstract factory pattern is a software design pattern that provides a way to encapsulate a group of individual factories that have a common theme. In normal usage, the client software creates a concrete implementation of the abstract factory and then uses the generic interfaces to create the concrete objects that are part of the theme. “

  10. creational pattern example : singleton • “.. the singleton pattern is a design pattern used to implement the mathematical concept of a singleton, by restricting the instantiation of a class to one object. This is useful when exactly one object is needed to coordinate actions across the system. The concept is sometimes generalized to systems that operate more efficiently when only one object exists, or that restrict the instantiation to a certain number of objects (say, five).”

  11. structural pattern example : adapter “.. the adapter pattern (often referred to as the wrapper pattern or simply a wrapper) is a design pattern that translates one interface for a class into a compatible interface. An adapter allows classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface.”

  12. structural pattern example : facade • “the facade pattern is a design pattern that provides a simplified interface to a larger body of code, such as a class library. A facade can: • make a software library easier to use, understand and test, since the facade has convenient methods for common tasks; • make code that uses the library more readable, for the same reason; • reduce dependencies of outside code on the inner workings of a library, since most code uses the facade, thus allowing more flexibility in developing the system; • wrap a poorly-designed collection of APIs with a single well-designed API (as per task needs).”

  13. behavioural pattern example : iterator “ ..the Iterator pattern is a design pattern in which iterators are used to access the elements of an aggregate object sequentially without exposing its underlying implementation. An Iterator object encapsulates the internal structure of how the iteration occurs.”

  14. behavioural pattern example : observer “The observer pattern (a subset of the publish/subscribe pattern) is a software design pattern in which an object, called the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods. It is mainly used to implement distributed event handling systems.”

  15. References Gama, Helm, Johnson, Vlissides, Design Patterns Elements of Reusable Object-Oriented Software, Addison Wesley, 1995 Doug Lea, Christopher Alexander: An Introduction for Object-Oriented Designers http://www.cmcrossroads.com/bradapp/docs/patterns-intro.html http://hillside.net/patterns/

More Related