Selected design patterns (as part of the the PTT lecture)

Selected Design Patterns Prof. Dr. Ralf Lämmel

Universität Koblenz-LandauSoftware Languages Team

(C) 2010-2013 Prof. Dr. Ralf Lämmel, Universität Koblenz-Landau (where applicable)

Reusable solutions to recurrent problems


Selected patterns(Pattern names with intents)

Composite -- provide uniform interface on part-whole hierarchiesCommand -- encapsulate the execution of functionality; enable undoVisitor -- represent operations on object structure as objectsObserver -- provide change notifications to objects depending on stateMVC -- decouple model, view, control in for interactive applicationsProxy -- refine or replace behavior of a given objectObject Adapter -- provide a different interface for an existing objectTemplate Method -- capture general structure of an algorithm...

Intent = short combo of problem + solution


Observer -- Problem

The observer pattern (aka publish/subscribe) involves an object, called the subject, which maintains a list of its dependents, called observers, and notifies them automatically of any state changes.

Do you know the problem?Do you know a solution?


Observer -- Solution

http://en.wikipedia.org/wiki/File:Observer.svg


Essential elements of a design pattern

Name

The problem describes when to apply the pattern.

The solution describes elements of the design, their relationships, responsibilities, and collaborations.

The consequences are the results and trade-offs of applying the pattern.


Describing design patterns

Pattern Name

Classification

Intent

Also Known As

Motivation

Applicability

Structure

Participants

Collaborations

Consequences

Implementation

Sample Code

Known Uses

Related Patterns

We do not go into all

these details in this course.


Classification of design patterns

Aspects

Creational patterns

Structural patterns

Behavioral patterns

Scope

Class

Object


Design patterns -- Overview

[Gamma et al., 1995, S. 10]


Design patternsof this slide deck

Template MethodAbstract FactoryObject AdapterObserverProxy

You are definitely expected to expand on

your knowledge of design patterns.


Abstract Factory -- Problem

Object models often give rise to variation. For instance, there may be multiple GUI libraries subject to different widget hierarchies. Whenever components want to abstract from the specific choice, then substantial efforts are required. For instance, the construction of objects must be tunneled through a factory.


Abstract Factory -- Solution

http://sourcemaking.com/design_patterns/abstract_factory


Abstract Factory

DEMO

Two alternative object models for companies.

POJOs

Some sort of beans

Make the choice of the object model configurable.

Contribution:javaExorcism


Proxy -- Problem

Additional access behavior for objectsAccess management for remote objectsAccess management for expensive objects


Proxy -- Solution

http://en.wikipedia.org/wiki/File:Proxy_pattern_diagram.svg


Proxy -- Scenarios

Additional access behavior for objects

Access management for remote objectsAccess management for expensive objects


Proxy

DEMO

Use security proxy to protect salary access.

Interesting issue of proxy deployment.



Observer -- Problem

The observer pattern (aka publish/subscribe) involves an object, called the subject, which maintains a list of its dependents, called observers, and notifies them automatically of any state changes.


Observer -- Solution

http://en.wikipedia.org/wiki/File:Observer.svg


Observer

DEMO

Use observer to providing logging.

Use observer to enforce data constraint.



Object Adapter -- Problem

A given object often has about the right capabilities for a specific client but not necessarily the precise interface expected. Accordingly, an interface adaptation can be achieved by an extra wrapper around the given object.


Adapter -- Solution(object adapters)


Adapter -- Solution(class adapters)


Adapter

DEMO

Class adapter: add observability of list interface.

Object adapter: downgrade java.util.List to simple list.



Template Method -- Problem

Some algorithms or strategies in a system may be very similar and hence it may be desirable to capture their commonalities in a sort of template so that specifics can be expressed through refinement giving rise to a high degree of reuse.


Template Method -- Solution

http://stephane.ducasse.free.fr/FreeBooks/SmalltalkDesignPatternCompanion/templateMethod.pdf

TEMPLATE METHOD (DP 325) Object Behavioral

IntentDefine the skeleton of an algorithm in an operation, deferring some steps to subclasses. TemplateMethod lets subclasses redefine certain steps of an algorithm without changing the algorithm’sstructure.

Structure

DescriptionTemplate Method may be #1 on the Design Patterns Pop Charts. Its structure and use are at the heartof much of object-oriented programming. Template Method turns on the fundamental object-orientedconcept of inheritance. It relies on defining classes that differ only slightly from an existing class. Itdoes this by relying on the ability of classes to provide for new behavior by overriding inheritedmethods.

The key to the Template Method pattern is a method that implements a broad message in terms ofseveral narrower messages in the same receiver. The broader method, a Template Method, isimplemented in a superclass and the narrower methods, Primitive Methods, are implemented in thatclass or its subclasses. The Template Method defines a general algorithm and the Primitive Methodsspecify the details. This way, when a subclass wants to use the algorithm but wishes to change someof the details, it can override the specific Primitive Methods without having to override the entireTemplate Method as well.

Reuse through Inheritance

Code and attribute sharing through inheritance is one of the most maligned techniques in object-oriented programming. It is deceptively easy to use, but often difficult to use well. Some authoritieshave dismissed implementation inheritance as confusing and unnecessary. As early as the firstOOPSLA, papers have documented potential problems with inheritance (e.g., Snyder, 1986). Theobject-oriented language SELF (Ungar & Smith, 1987) does not even support class inheritance;instead, it uses object composition exclusively. Design Patterns advocates favoring object compositionover class inheritance (pages 18-21). Many patterns transform code that relies on class inheritance touse object composition instead: State, Strategy, Decorator, Bridge, and Abstract Factory are a few ofthem.

Nevertheless, inheritance is a fundamental feature of most object-oriented languages, includingSmalltalk. Good class hierarchies allow for reuse of abstraction, design, and implementation. Because

templateMethod

AbstractClass

ConcreteClassA

primitiveMethod2primitiveMethod1


...self primitiveMethod1....self primitiveMethod2....

ConcreteClassB


ConcreteClassC

primitiveMethod2


Template

DEMO

Two general class of algorithms can identified:Queries such as 101feature:TotalTransformations such as 101feature:Cut

Contribution:javaTemplateContribution:javaExorcism


Summary

The use of design patterns is a basic element of software development. If you wouldn’t use them, your designs and implementations are unnecessarily unstandardized, idiosyncratic, incomprehensible, unmaintainable, etc. That is, if you are interested in a software development career, or you plan to talk to software developers at an interesting level of detail, you have to aggregate substantial knowledge of design patterns.

Technology

Selected design patterns (as part of the the PTT lecture)