1 / 30

Design Patterns

Design Patterns. Section 7.1 (JIA’s) Section 7.2.1 (till page 259) (JIA’s) Section 7.2.2(JIA’s) Section 10.4.1 (JIA’s). Design Patterns. Pattern is a term used to describe architectural designs Recurring Problems in architectural designs (Christopher Alexander, 1977)

becka
Download Presentation

Design Patterns

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 Section 7.1 (JIA’s) Section 7.2.1 (till page 259) (JIA’s) Section 7.2.2(JIA’s) Section 10.4.1 (JIA’s)

  2. Design Patterns • Patternis a term used to describe architectural designs • Recurring Problems in architectural designs (Christopher Alexander, 1977) • describe solutions for those problems • A pattern is a generic or reusable solution to a recurring problem • Can that be applied to software?

  3. Design Patterns • Similarities between software and architecture • Both are based on creative processes • Design must satisfy customer’s needs • Design my be feasible to engineer • Designers must balance many competing constraints and requirements • As a result, software design patterns are descriptions (templates) of solutions to recurring problems in software design • Not a finished design!

  4. Design Patterns • Why use design patterns? • Why reinvent the wheel? Use (reuse) common solutions for common problems • Boost confidence in software systems --use established design patterns that have been proveneffective • Provide a common vocabulary for software designers to communicate about software design • Work started by Gamma et al. • Design Patterns [Gamma et al., 1995]

  5. Design Patterns • 23 general-purpose design patterns [Gamma et al.] • Creational patterns • Deal with the process of object creation • E.g. Singleton --- One instance of class can exist • Structural patterns • Deal with the static composition and structure of classes and objects • E.g. Adapter --- Convert an interface of a class to a different one expected by other classes • Behavioral patterns • Deal with dynamic interaction among classes and objects • E.g. Template --- Separate variant and invariant behaviors among related classes

  6. Design Patterns • Pattern name (Also known as) • Problem addressed • Detailed description • When to apply (list of preconditions) • The Solution • Class diagram that depicts the participants of the pattern and the relationships among them • A list of classes participating in the pattern • Does not describe a concrete solution, is a template instead • Describe results and tradeoffs

  7. Singleton Design Pattern • Pattern name: Singleton • Category: Creational design pattern • Intent: Ensure that a class has only one instance and provides a global point of access to it • Also known as: N/A • Applicability: Use the Singleton pattern when there must be exactly one instance of a class and it must be accessible to clients from a well-known access point • a GUI application must have a single mouse • an active modem needs one and only one telephone line • an operating system can only have one window manager • or, a PC is connected to a single keyboard • Such objects are accessed by disparate objects throughout a software system, and therefore require a global point of access • Structure: NEXT SLIDE • Participants: Itself

  8. Singleton’s Structure

  9. Singleton • Declares the unique instance of the class as a static variable • Defines a static method getInstance() for clients to access the unique instance --- global access point • Code • public class Singleton {   private static Singleton theOnlyOne = null;//usually has other instance variables as well private Singleton() {    }   public static Singleton getInstance() { // global access point      if(theOnlyOne == null) {         theOnlyOne = new Singleton();      }      return theOnlyOne;   }}

  10. Singleton • public class SingletonInstantiator { • public SingletonInstantiator() { • Singleton instance = Singleton.getInstance(); • Singleton anotherInstance =new Singleton(); !!! } • } • Test if working properly?

  11. Example Singleton public class SingleRandom { private Random gen; private static SingleRandom theOnlyOne = new SingleRandom(); private SingleRandom() {gen = new Random(); } public void setSeed(int seed) { gen.setSeed(seed); } public int nextInt() { return gen.nextInt(); } public static SingleRandom getInstance() { return theOnlyOne; }

  12. Template Design Pattern • One of the most widely used design patterns • Useful for separating the variant and the invariant object behavior • Invariant means common to all subclasses • The invariant behavior is placed in the abstract class (template) • Concrete methods common to all subclasses • Abstract class contains abstract methods for the variant behavior • Any subclasses that inherit it can override the abstract methods and implement the specifics needed in that context • In the body of TemplateMethod() --- invariant --- there are calls to operation1() and operation2() … • operation1() and operation2() are abstract • defined by the subclasses which override them

  13. Template Design Pattern • Why abstract classes for templates? • Contain behavior that is common to all its subclasses encapsulated in non-abstract methods • Might even be defined as final • The abstract methods in such a class require that context-specific behavior be implemented for each concrete subclass • Called Hook methods

  14. Template Design Pattern • A program that sorts data using different sorting algorithms: • The AbstractClasswould have a method called Sort() • -- the invariant behavior • Sort uses the abstract methods in the class, which are specified by any class that inherits from it • The hook methods in this case might be • compare() (compares two objects and returns the one that is "higher") • sortPass() (performs one iteration of a particular sorting algorithm) • The usual control structure of object calls and relations is reversed! • It is the parent class that calls the method in the subclass

  15. Template Design Pattern • Pattern Name: Template Method • Category: Behavioral design pattern • Intent:To define the skeleton of an algorithm deferring some steps to subclasses, thus allowing the subclasses to redefine certain steps of the algorithm • This way, subclasses can override parts of the algorithm without changing its overall structure • Applicability: The Template Method Pattern should be used • to implement the invariant parts of an algorithm once and leave it to the subclasses to implement variant behavior • localize the common behavior among subclasses to avoid code duplication

  16. Structure of the Template Design Pattern

  17. # #

  18. Template Design Pattern • Participants: • Generic (or Abstract) Class • Defines theabstract hook methods (variant behavior) that concrete classes override to implement the steps of an algorithm • Implementsa template method (invariant behavior) that defines the skeleton of an algorithm called by the hook methods • Concrete Class • Implements the hook methodsto carry-out subclass-specific steps of the algorithm defined in the template method • Example 7.3 page 267 • www.users.csbsju.edu/~jschnepf/CS230/Code/Plotter/index.html

  19. Adapter Design Pattern • Pattern Name: Adapter • Category: Structural design pattern • Intent: To convert the contract of a class into another contract that new clients expect • The Adapter pattern is used so that two incompatible interfaces can work together • The join between them is called an Adapter • We convert interface of one class into interface expected by the client • A.K.A: Wrapper • Applicability: when we need to use an existing class with a “different” interface than provided

  20. Structure of Object Adapter Pattern << >>

  21. Structure of Object Adapter Pattern • Object adapters use delegation to adapt one interface to another • The adapter implements the target interface that the client expects to see, while it holds an instance of the adaptee • Can extend adaptee instead (limited to a single adaptee) • Object (composition) vs. Class (inheritance) Adapter • When the client calls the request() method on its target object (the adapter), the request is translated into the corresponding specific request on the adaptee • Adapters enable the client and the adaptee to be completely decoupled from each other • Only the adapter knows about both of them

  22. Structure of Class Adapter Pattern << >> Adaptee

  23. Adapter Design Pattern • Participants • Client • Requires objects conforming toATarget • ATargetinterface • Defines the interface expected by the Client • Adaptee class • Defines the “undesired” interface of an existing class • Adapter • Adapts the interface of Adaptee toATarget via delegation (composition) or inhertince

  24. CLIENT application would like to use a stack interface on DList (i.e. adapt ADAPTEE to TARGET) ADAPTEE /* DoubleLinkedList */ class DList { public void insert (int pos, Object o) { ... } public void remove (int pos, Object o) { ... } public void insertHead (Object o) { ... } public void insertTail (Object o) { ... } public Object removeHead () { ... } public Object removeTail () { ... } public Object getHead () { ... } public Object getTail () { ... } } TARGET interface Stack { void push (Object); Object pop (); Object peek(); } Example Object Adapter

  25. ADAPTER /* Adapt DList class to Stack interface */ class DListStack implements Stack { private DList _dlist; public DListStack() {_dlist = new DList(); } publicvoid push (Object o) { _dlist.insertHead (o); } public Object pop () {return _dlist.removeHead ();} public Object peek() {return _dlist.getHead ();} } Example Object Adapter

  26. /* Adapt DList class to Stack interface */ ADAPTER class DListImpStack extends DList implements Stack { publicvoid push (Object o) {insertHead (o); } public Object pop () {return removeHead (); } public Object peek() {return getHead(); } } Example Class Adaptor

  27. Example (Object Adapter) • Example page 514-530 • Table (Generic display table) • Client • Expects entries of type TableEntry • ListTableModel • TableEntry (row in a table) • Target • Student (Information on a Student) • Adaptee • Does not conform to TableEntry • StudentEntry2 • Adapter • Adapts Student to TableEntry

  28. Example

  29. Example (Class Adapter) • Table (Generic display table) • Client • Expects entries of type TableEntry • TableEntry (row in a table) • Target • Student (Information on a Student) • Adaptee • Does not conform to TableEntry • StudentEntry • Adapter • Adapts Student to TableEntry

  30. Example

More Related