<<

Examples Shape vs Picture

• AWT/Swing Components • Is there a relationship between them? – Picture contains Shape instances. • Document Components – Picture implements the same functionality that Shape presents. • Directory • So, a Picture is a Shape with children. – Where is the best place to put the functionality to support children • Porfolio of assets management? • Commands

Maximizing Component

Generalization Shape/Picture • The interface between Component and Composite Component/Composite classes should be the same, so that clients can use either transparently. – Component class defines default implementations Component – Leaf and Composite classes re-implement them. • But there are operations in Component that do not make sense for some Composites (Leaf) – Interface for accessing children • Be creative and think that a Leaf never has Component1 Component2 Component3 Composite children. • Component class implements children() to return null.

1 Child management ops Composite pattern

• Where should children ops reside? • Allows building of complex objects by – Component class? recursively composing similar objects in a • But not all Composites have children! tree-like manner. The tree components will • Lose operation safety. be treated transparently. – Composite class? • Maintain operation safety but … • Forces: • Loose transparency! – complex object seen as a whole-part hierarchy • Consider adding query hasChildren() – minimize complexity by minimizing number of in Component for every Composite. different kinds of child objects known by tree

Composite Pattern Diagram Other instances of the composite pattern use : To deal with trees Component defined implicitly. • Data can implicitly define a tree structure. • Logic can implicitly include a composition

Comp1 Comp2 Compk Composite of operations that can be represented via a tree.

CC1 CC2 CCk

2 Related pattern Decorator pattern

• Decorator. • Attach additional responsibilities to an object dynamically and transparently. • These added responsibilities can be withdrawn at run-time as well. • A flexible alternative to subclassing. • Another approach to avoid class (and naming) explosion.

Strategy pattern Template method pattern

• Lets an algorithm vary independently from • Defines the skeleton of an algorithm in an the client that uses it. Define a family of operation, deferring some steps to algorithms, encapsulate each one and make subclasses without subclasses changing the them interchangeable. algorithm structure. • Another alternative to inheritance to provide a variety of algorithms. But inheritance hardwires behavior into context. • Strategies eliminate use of conditionals.

3 Template vs strategy pattern Command Pattern

• Both address how to make an algorithm • Encapsulate a request as an object. more flexible – Template use inheritance to vary part of the • Flexibility gained: algorithm – Accessing a method via different views. – Strategy uses delegation to vary the entire algorithm. – Accessing different methods via same interface.

Abstract Factory Patterns

• Provide an interface for creating families of • Factory method • Iterator related or dependent objects without • Singleton • Observer specifying their concrete classes. • Abstract factory • State • Strategy • Adapter • Template method • Bridge • Command • Composite • Decorator

4 Patterns Other design issues • Design of hierarchies • Grasp patterns • Fundamental OO design principles – Information expert – Creator – High cohesion – Low coupling – Polymorphism – Indirection – Pure fabrication – Protected variation

Coding flaws XP coding methodology

• Make it work. • Make it well. • Make it fast.

5 Inheritance vs composition

• Inheritance – establishes a compile-time relationship between classes. – It sets up the overall structure of objects to be used at run-time • Composition – Allows for the change of definitions at run-time – It addresses the ability to plug-and-play.

6