1 / 19

Design Patterns: An Introduction

Design Patterns: An Introduction . Consider expert designers in any field. Experience has value. They reuse solutions that worked in the past. Think of architecture, creative writing, and other fields.

janus
Download Presentation

Design Patterns: An Introduction

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. Design Patterns: An Introduction

  2. Consider expert designers in any field. • Experience has value. • They reuse solutions that worked in the past. • Think of architecture, creative writing, and other fields. • Rarely are products of a creative activity totally new and without any reuse of a previously applied technique. Motivation

  3. “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.” – Christopher Alexander, et al. A Pattern Language, Oxford Univ. Press, New York, 1977. What is a design pattern?

  4. Although Alexander was writing about patterns in buildings and towns, the same is true of object-oriented design patterns. A OO design pattern names, explains, and evaluates an important, recurring design in OO systems. What is a design pattern?

  5. Pattern name • Descriptive name indicative of the essence of the pattern and the problem for which it applies. • Problem • Describes when to apply the pattern. • Solution • Describes the elements of the design, their relationships, responsibilities and collaborations. It’s like a template that can be applied to many different situations. • Consequences • Describes results and trade-offs of applying the pattern. Essential Elements of a Pattern

  6. Nature of Design Patterns • Not about such things as linked lists that can be embodied by a class and reused. • Not domain-specific designs for a whole application. • Descriptions of communicating objects and classes that can be customized to solve a general design problem in some context.

  7. Language features similar to C++ or Smalltalk. Assumption

  8. Finding appropriate objects. • Different approaches exist: • CRC cards • Noun extraction • Use case analysis, etcetera • Design patterns help to identify abstractions that have no counterparts in the real world. • Determining object granularity. • Size and number of objects Problems That Patterns Address (1)

  9. Specifying object interfaces • The set of all signatures defined for an object. • Signature: operation name, objects used as parameters, return value. • Type: The name denoting a particular interface. • Relationships between interfaces. • Objects are known only through their interfaces. • Can be affected by • Implementation within the object. • Polymorphism Problems That Patterns Address (2)

  10. Specifying object implementation • Defined by its class, which specifies its internal data and operations. • Class may be partly defined using inheritance. • An abstract class may define a common interface for subclasses. • Note that in this context, “class” is not the same as “type”. • Class refers to the object’s internal state and its implementation; • Type refers only to its interface, i.e., the set of requests to which it can respond. • A principle of reusable object-oriented design: Program to an interface, not an implementation. Problems That Patterns Address (3)

  11. Putting reuse frameworks into practice • Inheritance versus Composition • Inheritance: Also known as “white-box reuse,” because internal workings of superclasses are usually visible to subclasses. • Composition: New functionality gained by grouping objects having well-defined interfaces to get more complex functionality. • Called “black-box reuse” because internal workings of objects are not visible. Problems That Patterns Address (4a)

  12. Inheritance • Advantages: • Defined at compile time, straightforward, supported by language; easy to modify. • Disadvantages: • Can’t change at run-time. • Contrary to encapsulation, a subclass’ implementation depends on its superclass. • Can cause problems for reuse. • Partially solved by inheritance from abstract classes. Problems That Patterns Address (4b)

  13. Composition • Disadvantages: • Defined dynamically at run-time through references to other objects. • Requires carefully designed interfaces. • Advantages: • Encapsulation is preserved. • Any object can be replaced by another that has the same type (i.e., can respond to same set of requests). Problems That Patterns Address (4c)

  14. A principle of reusable object-oriented design: Favor object composition over class inheritance. • Simpler designs • More reusable designs Problems That Patterns Address (4d)

  15. Two objects work together to handle a request. • Example: Window/Rectangle • Disadvantage: • Software more difficult to understand. • Some run-time inefficiencies. • Possible advantage: • Lessen human inefficiencies • Use only when it simplifies more than it complicates. • Used by several design patterns. Delegation – Making Composition More Powerful

  16. A third way of composing behavior. Can’t change at run-time. Parameterized Types (Generics)

  17. The compile-time code structure is static and may bear little resemblance to the dynamic states of the running program. Run-time structure must be defined more by the designer than the language. Run-Time vs. Compile-Time Structures

  18. Maximize reuse by • Anticipating new requirements and • Changes to existing requirements • Design patterns help to make the system more able to accommodate particular kinds of change. Designing for Change

  19. Creating an object by specifying a class explicitly. Dependence on specific operations. Dependence on hardware and software platform. Dependence on object representations or implementations. Algorithmic dependencies. Tight coupling. Extending functionality by subclassing. Inability to alter classes conveniently. Common Causes of Redesign

More Related