Fundamental Design Patterns

SD

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

• 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.

Delegation (cont’)

Delegator Delegate1 1

user usee

Uses ►

SD

5


• 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


• 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 LuggageCompartmentprivate 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

• 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.

Interface (cont’)

Client<<interface>>IndirectionIF1 1

Uses ►Service

SD

10

Interface (cont’)


° 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

• 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.

Immutable (cont’)Immutable

<<constructor>>Immutable<<misc>>getAttribute1getAttribute2...

Java’s String Class is Immutable

SD

15

Immutable (cont’)


° 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

• 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.

Marker Interface (cont’)<<interface>>

MarkerIF

Operation(:object)

Utility

Marked

UnmarkedRecognizes ►

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.


° 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


• 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


• 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) {…}

}

Documents

Fundamental Design Patterns