Design Patterns CMPS 2143

Design Patterns Consider previous solutions to problems similar to any new problem ▫ must have some characteristics in common ▫ tweak the solution Very few really new problems Whole bunch of patterns are documented that you can use

What is a design pattern? Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. Christopher Alexander Aid in discussing structures and relationships at a higher level of abstraction (viewed as a community of interacting agents)

Two Reasons to use design patterns Speeds process of finding a solution ▫ don’t reinvent the wheel Naming patterns gives programmers a common vocabulary or language to discuss design alternatives.

What patterns aren’t. Patterns are a generalized concept, an idea formed in succinct manner, yet expressible in many different ways. They aren’t: ▫ an exact solution ▫ the basis of a code catalog

Controlling Information Flow Many design patterns deal with how information flows between a client/server or consumer/producer boundary. client info server

Easy Example: Adapter Pattern An object in your community (client) needs a service and requires a specific interface Another object provides the service, but does not support the desired interface CREATE AN ADAPTER! ▫ speaks the language of the client, but doesn’t do the work itself, it gets the service to do it

Coded example Client wants a DataBox but wants the methods in Collection class MyCollection implements Collection{ public boolean isEmpty() {return data.count()== 0;} public int size () {return data.count();} public void addElement (Object e) {data.add(e);} public boolean containsElement (Object e) { return data.find(e) != null;} public Object findElement (Object e) { return data.find(e);} private DataBox data = new DataBox(); }

Describing Patterns Special format to describe patterns Use a narrative with these parts ▫ name ▫ synopsis ▫ forces (or requirements of pattern) ▫ solution (or rather the essence of a solution) ▫ counterforces (reasons not to use the pattern) ▫ related patterns

Describing the Adapter Pattern ▫ name: Adapter ▫ synopsis: Used to connect a client who needs a service described using one interface with a provider who implements the desired functionality but uses a different interface ▫ solution : implements the interface as specified by the client, but rather than performing the given operations, passes the work on to the service provider ▫ counterforces: adds one layer of indirection between the client and provider and also introduces another class

Singleton Pattern Not all patterns deal with client/server interactions In Singleton pattern the developer of a class wants to ensure there is never more than one instance of the class

Coded Example of Singleton Pattern class SingletonClass { public: static SingletonClass * oneAndOnly () {return theOne;} //other non-constructor methods here private: //constructor Singleton () { //theOne is initialized here } //the member data static SingletonClass * theOne; }

Decorator Pattern Decorator pattern deals with how new functionality can be attached to existing objects ▫ inheritance is one way to do this ▫ inheritance is static and heavyweigth ▫ inheritance does not permit values to change their behavior dynamically during execution A decorator wraps around an existing object and satisfies the same requirements ▫ delegates much of responsibility to original ▫ occasionally adds new functionality

Decorator Pattern

Coded Example of Decorator from Java class BufferedInputStream extends InputStream { public BuffererInputStream (InputStream s) {data =s;} //other methods here private InputStream data; } InputStream reads bytes from input device, such as file. BufferedInputStream is a subclass of InputStream, adding the ability to buffer input ▫ can reset to an earlier point and can reread values NOTE: BufferedInputStream is-an Input Stream AND has-an InputStream

Observer Pattern Addresses problem of how two objects can stay synchronized without having direct knowledge of each other

Observer Pattern The model – part that is doing the actual work The view – portion of the program charged with displaying the results Need an intermediary ▫ ObserverManager communicates with both the model and the observers ▫ ObserverManager maintains list of models and they notify it when they change ▫ Observers register with ObserverManager Also known as Publish-Suscribe and ModelViewController

Model-View-Controller

Study pg. 478: 1, 3, 5, 15