InteraktionsprogrammeringTDDD13 + TDDC73

Anders Fröberg

onsdag, 2009 oktober 28

Design patterns Outline

• What is a design pattern

• Design Patterns for development

onsdag, 2009 oktober 28

Design Patterns

• In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design.

• A design pattern is not a finished design

• A template for how to solve a problem

onsdag, 2009 oktober 28

Design Patterns

• Different types of patterns

• Traditional for Software (GOF-book)

• System Architectural patterns

• Actual Architectural patterns

• Anti Patterns (how not to do it)

onsdag, 2009 oktober 28

The four essential part of a pattern• The Name

• Naming a pattern increase design vocabulary

• The Problem

• When and where to apply the pattern

• The Solution

• Elements of the solution their relationships, responsibilities and collaborations

• The Consequence

• Trade-offs for applying the patternonsdag, 2009 oktober 28

Patterns • Three main categories

• Creational Patterns

• how objects are created,composed and represented

• Structural Patterns

• how classes and objects are composed to form larger structure

• Behavioral Patterns

• algorithms and assignment of responsibilities between objects

onsdag, 2009 oktober 28

Creational Patterns

• Singleton

• Factory Method

• Abstract Factory

onsdag, 2009 oktober 28

Singleton

• Intent:

• To ensure a object only has one instance, and provide a global point of access to it

• You want to make sure that there is only one Dialog for login

onsdag, 2009 oktober 28

Singleton public class Singleton { private static final Singleton INSTANCE = new Singleton(); // Private constructor prevents instantiation /// from other classes private Singleton() {} public static Singleton getInstance() { return INSTANCE; } }

public class Singleton { // Private constructor prevents //instantiation from other classes private Singleton() {} /** * SingletonHolder is loaded on the

* first execution of Singleton.getInstance() * or the first access to SingletonHolder.INSTANCE, not before. */ private static class SingletonHolder { private static final Singleton INSTANCE = new Singleton(); } public static Singleton getInstance() { return SingletonHolder.INSTANCE; } }

The solution of Bill Pugh

onsdag, 2009 oktober 28

Factory Method

• Intent:

• Define a interface for creating an object, but let the subclasses decide which class to instantiate. Factory method lets a class defer instantiation to subclasses

onsdag, 2009 oktober 28

Factory Method

onsdag, 2009 oktober 28

Factory method

• Factory methods are common in toolkits and frameworks where library code needs to create objects of types which may be subclassed by applications using the frameworks

onsdag, 2009 oktober 28

Factory method public interface ImageReader { public DecodedImage getDecodedImage();} public class GifReader implements ImageReader { public DecodedImage getDecodedImage() { return decodedImage; }} public class JpegReader implements ImageReader { // ....}

public class ImageReaderFactory { public static ImageReader getImageReader(InputStream is) { int imageType = determineImageType(is); switch(imageType) { case ImageReaderFactory.GIF: return new GifReader(is); case ImageReaderFactory.JPEG: return new JpegReader(is); // etc. } }}

onsdag, 2009 oktober 28

Abstract factory Pattern

• Intent:

• Provide an interface for creating families of related or dependent objects without specifying their concrete classes

onsdag, 2009 oktober 28

Abstract factory Pattern

onsdag, 2009 oktober 28

Abstract factory pattern

• Insulates client code from object creation by having clients ask a factory object to create an object of the desired abstract type

• The client code has no knowledge whatsoever of the concrete type

• Factories often stored using Singleton

onsdag, 2009 oktober 28

Structural Patterns

• Adapter

• Composite

• Decorator

• Facade

onsdag, 2009 oktober 28

Adapter pattern

• Intent:

• Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces.

onsdag, 2009 oktober 28

Adapter pattern

onsdag, 2009 oktober 28

Adapter Pattern

• The adapter pattern is useful in situations where an already existing class provides some or all of the services you need but does not use the interface you need.

• A good real life example is an adapter that converts the interface of a Document Object Model of an XML document into a tree structure that can be displayed.

onsdag, 2009 oktober 28

Composite Pattern

• Intent:

• Compose object into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.

onsdag, 2009 oktober 28

Composite Pattern

onsdag, 2009 oktober 28

Composite Pattern

• Composite can be used when clients should ignore the difference between compositions of objects and individual objects.

• If using multiple objects in the same way, and often have nearly identical code to handle each of them, then composite is a good choice

onsdag, 2009 oktober 28

Decorator

• Intent:

• Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.

onsdag, 2009 oktober 28

Decorator Pattern

1. Subclass the original "Component" class into a "Decorator" class (see UML diagram);2. In the Decorator class, add a Component pointer as a field;3. Pass a Component to the Decorator constructor to initialize the Component pointer;4. In the Decorator class, redirect all "Component" methods to the "Component" pointer; and5. In the Decorator class, override any Component method(s) whose behavior needs to be

modified.

onsdag, 2009 oktober 28

Decorator Pattern

• The decorator pattern is an alternative to subclassing. Subclassing adds behavior at compile time, and the change affects all instances of the original class; decorating can provide new behavior at runtime for individual objects.

onsdag, 2009 oktober 28

Facade Pattern

• Intent:

• Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use

onsdag, 2009 oktober 28

Facade Pattern

onsdag, 2009 oktober 28

Facade Pattern■make a software library easier to use and understand, since the

facade has convenient methods for common tasks;■make code that uses the library more readable, for the same

reason;■ reduce dependencies of outside code on the inner workings of a

library, since most code uses the facade, thus allowing more flexibility in developing the system;

■ wrap a poorly-designed collection of APIs with a single well-designed API (as per task needs).

onsdag, 2009 oktober 28

Behavioral Patterns

• Mediator

• Observer

onsdag, 2009 oktober 28

Mediator Pattern

• Intent:

• Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.

onsdag, 2009 oktober 28

Mediator Pattern

onsdag, 2009 oktober 28

Mediator Pattern

•Dependencies between Objects•Different Dialogs will have different dependencies •Even if you use same UI-objects they cant be reused

onsdag, 2009 oktober 28

Mediator Pattern

• Communication between objects is encapsulated with a mediator object.

• Objects no longer communicate directly with each other, but instead communicate through the mediator.

• This reduces the dependencies between communicating objects, lowering the coupling

onsdag, 2009 oktober 28

Observer Pattern

• Intent:

• Define a one to many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

onsdag, 2009 oktober 28

Observer Pattern

onsdag, 2009 oktober 28

Observer Pattern

• Swing is a heavy user of the Observer pattern—it implements more than 50 event listeners for implementing application-specific behavior, from reacting to a pressed button to vetoing a window close event for an internal frame.

onsdag, 2009 oktober 28

MVC

• From Smalltalk-80

• Designed for building user interfaces

• Designed to decouple classes of different responsibilities

• In essence a collection of other patterns

• Observer,Composite,Strategy and Factory

onsdag, 2009 oktober 28

MVC

onsdag, 2009 oktober 28

MVC

• A model that represents the data for the application.

• The view that is the visual representation of that data.

• A controller that takes user input on the view and translates that to changes in the model.

onsdag, 2009 oktober 28

Swing MVC

• A tight coupling between Controller and View

• Hard to define a generic Controller that needs no information about the View

onsdag, 2009 oktober 28

Swing MVC

• Swing collapses the view and controller parts of each component into a single UI (user-interface) object.

• Sometime refereed to as: separable model architecture

onsdag, 2009 oktober 28

Swing MVC

• Good practice to center the architecture of an application around its data rather than around its user interface

• Still facilitates model-driven programming in Swing

• The ability to delegate some of a component's view/controller responsibilities to separate look-and-feel object.

onsdag, 2009 oktober 28

Swing MVC

• GUI-state or Application-state model

• GUI state models are interfaces that define the visual status of a GUI control

• An application-data model is an interface that represents some quantifiable data

onsdag, 2009 oktober 28

GUI-state model

• Visual status of a GUI control

• Typically are relevant only in the context of a graphical user interface

• Button-pressed, Position of a slider or Item-selected from a list

• Manipulate the state of a GUI control through top-level methods on the

onsdag, 2009 oktober 28

Application-state model

• Represents some quantifiable data that has meaning primarily in the context of the application

• Value of a cell in a table or the Items displayed in a list.

• Data-centric Swing components, such as JTree and JTable, work with the model

onsdag, 2009 oktober 28

Conclusion

• Statically typed OO-languages (like java) has inherent problems, often there is a named solution (a pattern).

• Patterns are not magic mere a template way of solving a problem

• Patterns gives us a language we can use on a higher level to talk about the solution

onsdag, 2009 oktober 28