1 / 21

Fundamental Design Patterns

Fundamental Design Patterns. Fundamental Design Patterns. Delegation—when not to use Inheritance Interface Abstract superclass (not covered here) Interface and abstract class (not covered here) Immutable Marker interface Proxy (not covered here). Delegation. Intent

fitzgerald-goodman
Download Presentation

Fundamental 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. FundamentalDesign Patterns SD

  2. Fundamental Design Patterns • Delegation—when not to use Inheritance • Interface • Abstract superclass (not covered here) • Interface and abstract class (not covered here) • Immutable • Marker interface • Proxy (not covered here) SD

  3. Delegation • Intent • A way to extend and reuse functionality of a class by writing an additional class with added functionality that uses instances of the original class to provide the original functionality. • Motivation • Inheritance is a common way to extend & reuse functionality. • Usually is-a-kind-of (Specialization) • Inheritance is inappropriate for many situations: • is-a-role-played-by ? • Delegation is a more general way for extending a class’s behavior. • Applicability • Use the Delegation pattern when • Behavior might change over time. • Not conceptually an inheritance relationship. SD

  4. Delegation (cont’) • Structure • Participants • Delegator • declares interface for clients. • delegates messages to Delegate. • Delegate • answers to messages sent by the Delegator. • may be shared. • Collaborations • Clients use the Delegator interface to send messages to the Delegator, as a side effect, the same message is sent to the Delegate by the Delegator. Uses ► 1 1 Delegate Delegator user usee SD

  5. Delegation (cont’) • Consequences • Advantages: • Can be used without the problems that accompany inheritance. • e.g. Sub-typing • Easy to compose behavior at runtime. • Disadvantages: • Less structured than inheritance. • Relationship between classes less obvious. • Implementation • The implementation of delegation is very straightforward. SD

  6. Delegation (cont’) • Sample Code • consider the FlightSegment and LuggageCompartment classes: Class FlightSegment { … LuggageCompartment luggage; … void checkLuggage(Luggage piece) throws LuggageException { luggage.checkLuggage(piece); } } Class LuggageCompartment { … // The pieces of luggage in this LuggageCompartment private Vector pieces = new Vector(); … void checkLuggage(Luggage piece) throws LuggageException { … pieces.addElement(piece); } } SD

  7. Delegation (con’t) • Related Patterns • Almost every other pattern uses delegation. Some of the patterns that rely most clearly on delegation are the Decorator pattern and the Proxy pattern. SD

  8. Interface • Intent • Keep a class that uses data and services provided by instances of other classes independent of those classes by having those instances through an interface. • Motivation • Capture common behavior semantics • e.g. Glyphs, e-mail entities on msOutlook • Assists “Programming in the large” • commit to a set of interfaces and their semantics between software teams. • Applicability • Use the Interface pattern when • Common behavior may have different implementations. • Business protection issues - not reveal actual code. SD

  9. Interface (cont’) • Structure • Participants • Client • uses Service classes that implement IndirectionIF. • IndirectionIF • provides the indirection that keeps the Client class independent of the Service class. • Service • provides a service to Client classes by implementing the IndirectionIF interface • Collaborations • Clients use the interface to interact with different service objects which are instances of different classes which are guaranteed to implement the interface. Uses ► <<interface>> IndirectionIF Service Client 1 1 SD

  10. Interface (cont’) • Consequences • Advantages: • keeps a class that needs a service from another class from being coupled to any specific class. • Disadvantages: • like any other indirection, the interface pattern can make a program more difficult to understand. • Implementation • The implementation of an interface in Java is very straightforward. • In C++, you can write a pure abstract class and supply no method implementation • use virtual type methodName(args) = 0; • however, the compiler won’t check that you didn’t actually supply an implementation. SD

  11. Interface (cont’) • Sample Code • consider the AddressPanal, AddressIF and ReceivingLocation classes: Class AddressPanel extends Panel { private AddressIF data; … public void save() { if (data != null) { data.setAddress(addressField.getText()); … data.setPostalCode(postalCodeField.getText()); } } } Public interface AddressIF { public String getAddress(); public void setAddress(String address); … public String getPostalCode(); public void setPostalCode(String postalCode); } SD

  12. Interface (con’t) • Implementation (cont’) • Related Patterns • The delegation and interface patterns are often used together. • many other patterns use the interface pattern. Class ReceivingLocation extends Facility implements AddressIF { private String address_; private String postalCode_; … public String getAddress() { return address_; } public void setAddress(String address) { address_ = address; } … public String getPostalCode() { return postalCode_; } public void setPostalCode(String postalCode) { postalCode_ = postalCode; } } SD

  13. Immutable • Intent • Increase the robustness of objects that share references to the same object and reduce overhead of concurrent access to an object. It accomplishes this by forbidding any of the object’s state information to change after the object is constructed. • Motivation • const-correctness is invaluable. • avoid synchronization issues. • Applicability • Use the Immutable pattern when • an object isn’t suppose to change state during it’s lifetime. See also: http://renaud.waldura.com/doc/java/final-keyword.shtml#immutable SD

  14. Immutable (cont’) Immutable • Structure • Participants • Immutable • allows modification of state variables only upon creation. • provides access methods for exposed state variables. • may provide other services. • Collaborations • Clients use the interface to interact with different service objects which are instances of different classes which are guaranteed to implement the interface. <<constructor>> Immutable <<misc>> getAttribute1 getAttribute2 ... Java’s String Class is Immutable SD

  15. Immutable (cont’) • Consequences • Advantages: • there is no need to write code to manage state changes. • no need to synchronize threads that access immutable objects. • Disadvantages: • operations that would otherwise have changed the state of an object must create a new object. • Implementation • no method other than the constructor should modify the values of a class’s instance variables. • any method that computes new state information must store that information in a new instance of the same class, rather then modify the existing object’s state. SD

  16. Immutable (cont’) • Sample Code • consider the Position class • Related Patterns • Single threaded execution pattern - can be avoided by using the Immutable pattern. Class Position { private int x_; private int y_; public Position(int x, int y) { x_ = x; y_ = y; } public int getX() { return x_; } public int getY() { return y_; } public Position offset(int xOffset, int yOffset) { return new Position(getX()+xOffset,getY()+yOffset); } } SD

  17. Marker Interface • Intent • Use interfaces that declare no methods or variables to indicate semantic attributes of a class. • Say that classes implement an interface (with no methods) as the semantic flag/tag • Motivation • unrelated concepts do have something in common • Serializable,Cloneable • however, how to use this information is context-dependent • Applicability • Use the Marker Interface pattern when • as intent states - to indicate a semantic attribute. SD

  18. Marker Interface (cont’) <<interface>> MarkerIF Unmarked • Structure • Participants • MarkerIF • marks descendants for a certain mark • Marked • may be passed to Utility • supports some thing it chose to be marked with. • Utility • queries objects for MarkerIF interface and if so uses this information. • Unmarked • can be passed to Utility but doesn’t comply to MarkerIF consequences. Recognizes ► Utility Operation(:object) Marked SD

  19. Marker Interface (cont’) • Collaborations • Clients query if a given object is an instance of the marker interface. This works because inheritance is also sub-typing. • Consequences • Advantages: • utility classes are able to make some inferences about objects passed to their methods without depending on the objects to be instances of any particular class. • The relationship between the utility class and the marker interface is transparent to all other classes except for those classes that implement the interface. • Disadvantages: • uses Run-Time Type Identification(RTTI) which is discouraged as bad design. However, in rare cases this can’t be avoided. SD

  20. Marker Interface (cont’) • Implementation • in Java, use the instanceof keyword to find out if an object is an instance of a class that is marked by the marker interface. • For example, ObjectOutputStream refuses to serialize objects unless their class implements serializable (indicating serialization is allowed) • In C++, use dynamic_cast<marker_interface_name>. • In Smalltalk, use isKindOf: marker_interface_name SD

  21. Marker Interface (cont’) • Sample Code • consider a LinkedList implementation • Related Patterns • the Snapshot pattern uses a marker interface to allow serialization of objects. public class LinekedList implements Cloneable, java.io.Serializable { … public LinkedList find(Object target) { if (target == null || tagrget instanceof EqualByIdentity) return findEq(target); else return findEquals(target); } private synchronized LinkedList findEq(Object target) { … } private synchronized LinkedList findEquals(object target) { … } } SD

More Related