fundamental design patterns n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Fundamental Design Patterns PowerPoint Presentation
Download Presentation
Fundamental Design Patterns

Loading in 2 Seconds...

play fullscreen
1 / 21

Fundamental Design Patterns - PowerPoint PPT Presentation


  • 119 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Fundamental Design Patterns' - fitzgerald-goodman


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
fundamental design patterns1
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

delegation
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

delegation cont
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

delegation cont1
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

delegation cont2
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

delegation con t
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

interface
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

interface cont
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

interface cont1
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

interface cont2
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

interface con t
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

immutable
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

immutable cont
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

immutable cont1
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

immutable cont2
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

marker interface
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

marker interface cont
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

marker interface cont1
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

marker interface cont2
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

marker interface cont3
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