SOFTWARE PATTERNS Joseph Bonello
MOTIVATION Building software using new frameworks is more complex And expensive There are many methodologies and frameworks to help developers build enterprise application
MOTIVATION The main problems are: Changes in business logic Technology updates Maintenance Building software is difficult Building reusable software is even harder!
WHY PATTERNS? We need a common, tried-and-tested way of building and testing software Especially in those areas where common problems recur The aim is to make it easier to change and maintain software Other aims Developers adopt a common design principle Don t waste time hacking your way into a solution Reference on structures that get the work done efficiently
PATTERNS AND ANTI-PATTERNS A pattern is a general, re-usable solution to a common problem in software design Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley. ISBN 0-201-63361-2 (Gang-Of-Four Book)
PATTERNS AND ANTI-PATTERNS An anti-pattern is a commonly used pattern but is counterproductive or ineffective in practice Experienced OO designers, in general, do not try to solve a problem from first principles Instead, they prefer to reuse a solution that has worked in the past
WHAT CONSTITUTES A PATTERN? A Pattern has 4 essential elements: A pattern name: Used to refer to a description of a design problem, its solutions and consequences using a descriptive alias. The alias allows us to communicate with other and design at a higher level of abstraction. The problem: It describes when to apply the pattern. It describes the context of the problem such as class/object structures symptomatic of bad design or a list of conditions that must be met before applying the pattern.
WHAT CONSTITUTES A PATTERN? A Pattern has 4 essential elements: The solution: describes the elements that make up the design, the relationships, responsibilities and collaborations. It does not describe a concrete implementation. It is an abstract description of the general arrangement that will solve the problem. The consequences: refer to the results and trade-offs or applying the pattern. They are used to judge the costs and benefits of applying the pattern. Consequences include impact on system flexibility, extensibility and portability.
CATEGORIES OF PATTERNS Creational patterns Deal with object creation mechanisms Structural patterns Ease the design of defining relationships between entities Behavioral patterns Used to identify communication patterns between objects and increase flexibility when carrying out this communication
CREATIONAL PATTERNS We shall be looking at the following Creational Patterns Singleton Pattern Abstract Factory (Kit) Pattern
THE SINGLETON PATTERN IA Provides a single object throughout the lifetime of an application Provides a single access point to the object
THE SINGLETON PATTERN IB An example would be to have one database connection per client application Used when: There must only be one instance of a class Clients need one single way of accessing the instance
THE SINGLETON PATTERN II Benefits: Controlled access to sole instance (or multiple instances) Avoids global variables in namespace Permits Subclassing More flexible than static member and methods
SINGLETON PATTERN III public class ClassicSingleton { private static ClassicSingleton instance = null; protected ClassicSingleton() { // Exists only to defeat instantiation. public static ClassicSingleton getinstance() { if(instance == null) { instance = new ClassicSingleton(); return instance;
SINGLETON PATTERN IV public class ThreadSafeSingleton { private static ThreadSafeSingleton instance = null; protected ThreadSafeSingleton() { // Exists only to defeat instantiation. public synchronized static ThreadSafeSingleton getinstance() { if(instance == null) { instance = new ThreadSafeSingleton(); http://www.javaworld.com/article/2073352/core return instance; -java/simply-singleton.html
ABSTRACT FACTORY (KIT) I Provide an interface for creating families of related or dependent object without specifying their concrete classes Used to de-couple clients from a particular concrete implementation Example: Different implementations of handling an order s costs (e.g. TaxCalculator(EU,USA, CN,etc), shipping costs, etc)
ABSTRACT FACTORY (KIT) IIA
ABSTRACT FACTORY (KIT) IIB
ABSTRACT FACTORY (KIT) III Use the Abstract Factory pattern when a system should be independent of how its products are created, composed, and represented. a system should be configured with one of multiple families of products. a family of related product objects is designed to be used together, and you need to enforce this constraint. you want to provide a class library of products, and you want to reveal just their interfaces, not their implementations.
ABSTRACT FACTORY (KIT) IV Benefits: Isolates concrete classes Allows to change product family easily Promotes consistency among products Factory usually a Singleton; ideally create<object> should have a type parameter to make it extensible
ABSTRACT FACTORY (KIT) V Step 1: The Interface public interface Shape { void draw(); Step 2: The Concrete Class public class Rectangle implements Shape { @Override public void draw() { System.out.println("Inside Rectangle::draw() method.");
ABSTRACT FACTORY (KIT) V Step 3: Create the Abstract Factory Class public abstract class AbstractFactory { abstract Shape getshape(string shape) ; Step 4: Create the Concrete Factory Class public class ShapeFactory extends AbstractFactory { @Override public Shape getshape(string shapetype){ if(shapetype == null){ return null; if(shapetype.equalsignorecase("rectangle")){ return new Rectangle(); return null;
ABSTRACT FACTORY (KIT) V Step 5: Create Factory Producer public class FactoryProducer { public static AbstractFactory getfactory(string choice){ if(choice.equalsignorecase("shape")){ return new ShapeFactory(); return null;
ABSTRACT FACTORY (KIT) V Step 6: Use Producer to Get Factories public class AbstractFactoryPatternDemo { public static void main(string[] args) { //get shape factory AbstractFactory shapefactory = FactoryProducer.getFactory("SHAPE"); // get an object of Shape Rectangle Shape shape1 = shapefactory.getshape( RECTANGLE"); // call draw method of Shape Rectangle shape1.draw();
STRUCTURAL PATTERNS In this section, we ll discuss the following patterns Adapter (or Wrapper) Pattern Bridge Pattern Composite Pattern Decorator Pattern Façade Pattern
ADAPTER (WRAPPER) I Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces. Example Merging a new library with an old library you discover two methods with the same name but different parameters
ADAPTER (WRAPPER) II Benefits: Allow two or more incompatible objects to communicate and interact. Improves reusability of older functionality.
ADAPTER (WRAPPER) III Use when: When you want to use an existing class, and its interface does not match the interface you need. When you want to create a reusable class that cooperates with unrelated or unforeseen classes, classes that don't necessarily have compatible interfaces.
ADAPTER (WRAPPER) III When you want to use an object in an environment that expects an interface that is different from the object's interface. When you must ensure interface translation among multiple sources.
ADAPTER (WRAPPER) III
ADAPTER (WRAPPER) III Step 1: Create the interfaces public interface MediaPlayer { public void play(string audiotype, String filename); public interface AdvancedMediaPlayer { public void playvlc(string filename); public void playmp4(string filename);
ADAPTER (WRAPPER) III Step 2: Create the concrete class implementing the advanced interface public class VlcPlayer implements AdvancedMediaPlayer{ @Override public void playvlc(string filename) { System.out.println("Playing vlc file. Name: "+ filename); @Override public void playmp4(string filename) { //do nothing
ADAPTER (WRAPPER) III Step 2: Create the concrete class implementing the advanced interface public class VlcPlayer implements AdvancedMediaPlayer{ @Override public void playvlc(string filename) { System.out.println("Playing vlc file. Name: "+ filename); @Override public void playmp4(string filename) { //do nothing
ADAPTER (WRAPPER) III Step 3: Create the adapter for MediaPlayer public class MediaAdapter implements MediaPlayer { AdvancedMediaPlayer advancedmusicplayer; public MediaAdapter(String audiotype){ if(audiotype.equalsignorecase("vlc") ){ advancedmusicplayer = new VlcPlayer(); else if (audiotype.equalsignorecase("mp4")){ advancedmusicplayer = new Mp4Player(); @Override public void play(string audiotype, String filename) { if(audiotype.equalsignorecase("vlc")){ advancedmusicplayer.playvlc(filename); else if(audiotype.equalsignorecase("mp4")){ advancedmusicplayer.playmp4(filename);
ADAPTER (WRAPPER) III Step 4: Create the concrete implementation of the adapter public class AudioPlayer implements MediaPlayer { MediaAdapter mediaadapter; @Override public void play(string audiotype, String filename) { //inbuilt support to play mp3 music files if(audiotype.equalsignorecase("mp3")){ System.out.println("Playing mp3 file. Name: " + filename); //mediaadapter is providing support to play other file formats else if(audiotype.equalsignorecase("vlc") audiotype.equalsignorecase("mp4")){ mediaadapter = new MediaAdapter(audioType); mediaadapter.play(audiotype, filename); else{ System.out.println("Invalid media. " + audiotype + " format not supported");
ADAPTER (WRAPPER) III Step 5: Use the adapter public class AdapterPatternDemo { public static void main(string[] args) { AudioPlayer audioplayer = new AudioPlayer(); audioplayer.play("mp3", "beyond the horizon.mp3"); audioplayer.play("mp4", "alone.mp4"); audioplayer.play("vlc", "far far away.vlc"); audioplayer.play("avi", "mind me.avi");
BRIDGE (HANDLE) PATTERN I Used to decouple an abstraction from its implementation so that the two can vary independently When an abstraction (abstract class) can have several implementations, the usual way to accommodate them is to use inheritance This isn t always a flexible approach because the implementation binds to the abstraction permanently
BRIDGE (HANDLE) PATTERN I Use the pattern when: You want to avoid a permanent binding between an abstraction and its implementation Both the abstractions and the implementations should be extensible by sub-classing Changes in the implementation of an abstraction should not impact clients
BRIDGE (HANDLE) PATTERN II Use the pattern when (cont): You have a class hierarchy that proliferates because it needs to adapt to various specific implementations You want to share an implementation among multiple objects but you want to keep the fact hidden from the client.
BRIDGE (HANDLE) PATTERN III Known uses GUI frameworks as discussed previously. Persistence Frameworks Consequences: Implementation is not bound permanently to an interface Eliminates compile time dependencies (no recompilation of abstract class) Decoupling encourages layering, therefore a better structured system Improved extensibility Hiding implementation details from clients
COMPOSITE PATTERN I Used to compose objects into tree structures to represent part-whole hierarchies. Clients treat individual objects and compositions of objects uniformly Example Consider graphics applications that allow users to build complex diagrams out of simple components which can be grouped into more complex ones A simple implementation would define classes for graphical primitives and other classes that act as containers for these primitives Problem: code using these classes must treat primitives and objects differently The distinction increases the complexity of the system The pattern uses recursive composition so clients do not make this distinction
COMPOSITE PATTERN II Use the pattern when: You want to represent part-whole hierarchies of objects You want clients to be able to ignore differences between compositions of objects and individual objects
COMPOSITE PATTERN III Example Consequences Define class hierarchies consisting of primitive objects and composite objects Simplifies the client s architecture Simplifies the process of adding new components The design can be overly general (disadvantage)
DECORATOR (WRAPPER) PATTERN I Decorator is used to attach responsibilities to an object dynamically Decorators provide a flexible alternative to sub-classing for extending functionality Why use it? We use it when we need to add responsibilities to individual objects, not the entire class (e.g. adding borders or scrollbars to a visual widget) If you use inheritance will affect every instance which will not allow it to vary the choice as it is statically linked The solution is to add the object, called the decorator or wrapper, within another that adds the required property
DECORATOR (WRAPPER) PATTERN II Use the Decorator To add responsibilities to individual objects dynamically and transparently To withdraw responsibilities from the object When extending by sub-classing is impractical or not permitted A large number of independent extensions would result in an explosion of classes A class definition may be hidden or sealed (final)
DECORATOR (WRAPPER) PATTERN III Consequences More flexible than static inheritance Easier to add a property twice (e.g. a widget with a double border) Avoids feature-laden classes up in the hierarchy, reducing complexity. Features are added incrementally with new decorator objects The decorator and its component are identical, the decorator is a transparent enclosure similar to a photograph frame Lots of little objects (disadvantage), difficult to learn and debug Used frequently in UI Toolkits and in the implementation of IO stream classes
FAÇADE PATTERN I Provides a unified interface to a set of interfaces in a subsystem Defines a higher level interface that makes the subsystem easier to use Structuring a system into subsystems helps reduce complexity Common design goal is to minimise communication and dependency between subsystems Façade objects provides a single, simplified interface to more general facilities of the sub-system
FAÇADE PATTERN II Example: Programming environment providing access to its compiler subsystem Higher level interface shields clients from intricate details of different parts of compiler by allowing access to specific functionality of different subparts Use Façade when: Provide a simple interface to a complex system There are many dependencies between clients and the implementation classes of an abstraction Façade decouples the sub-system from clients Layer your subsystems. Façade defines the entry to each subsystem layer
FAÇADE PATTERN III Consequences Shields clients from sub-system components Promotes weak coupling between sub-system and its clients Reduces compilation dependencies Does not prevent applications from using subsystem classes if they need to
BEHAVIOURAL PATTERNS These are some common behavioural patterns: Iterator Pattern Observer Pattern Strategy Pattern
ITERATOR (CURSOR) PATTERN I Provides a way to access the elements of an aggregate object sequentially without exposing its underlying representation An aggregate object (e.g. List) should give you a way to access its elements without exposing its structure You might want to traverse the list in many ways, but you want to keep the design and implementation of the List clean The idea of the pattern is to take the responsibility for accessing and traversing the list using at iterator object The iterator keeps track of the current element The List is responsible for creating its own iterator, possibly using a Factory to generalise the operation
ITERATOR (CURSOR) PATTERN II Use this pattern when you want To access an aggregate object s contents without exposing its internal representation Support multiple traversals of aggregate objects Provide a uniform interface for traversing different aggregate structures
ITERATOR (CURSOR) PATTERN III Consequences of using this pattern Supports variations in the traversal of an aggregate Simplify the aggregate interface Mode than one traversal can be pending on the same aggregate Known uses: Collection classes (Lists, Vectors, etc)
OBSERVER (DEPENDENTS) PATTERN I Defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically When partitioning a system into a collection of cooperating classes, one needs to maintain consistency between related objects Note that tightly coupling class is not a solution because it reduces reusability The observer pattern describes how to establish common relationships between objects The key objects are the subject and the observer All observer are notified when the subject changes (publish-subscribe model)
OBSERVER (DEPENDENTS) PATTERN II Used when Abstraction has two aspects, one dependent on the other. Encapsulate the objects separately and reuse them independently When a change to one object requires changing the others, and you do not know how many objects to change When an object needs to be able to notify other objects without making assumptions about who these objects are (not tightly coupled)
OBSERVER (DEPENDENTS) PATTERN III Consequences Abstract coupling between Subject and Observer. Subject knows that it has a list of observers conforming to the observer interface, it does not know the concrete class of the observer minimal coupling Support for broadcast communication Unexpected updated (disadvantage). Since observers have no knowledge of other observers, changing the subject might result in undesired updates
STRATEGY (POLICY) PATTERN I Define a family of algorithms that encapsulate one another and make them interchangeable Strategy lets the algorithm vary independently of the client that uses them Example: Many algorithms exist for breaking a stream of text into lines. Hard-wiring all algorithms into the classes that require them is not desirable because Client get overly complex Different algorithms will be appropriate at different times Difficult to add new algorithms and vary existing ones
STRATEGY (POLICY) PATTERN II Use this pattern when Many related classes differ only in their behaviour Need different variants of an algorithm An algorithm uses data that clients shouldn t know about (avoid exposing complex, algorithm-specific data structures) A class defines many behaviours that appear as multiple conditional statements in its operators
STRATEGY (POLICY) PATTERN III Consequences Families of related algorithms. Hierarchies of Strategy classes define a family of algorithms that can be reused An alternative to sub-classing, which is easier to switch to, understand and extend Strategies eliminate conditional statements Provides a choice of implementations Clients must be aware of different strategies (disadvantage) Communication overhead between Strategy and Context (Strategy interface is shared, so some simple concrete classes may use little or none of the parameters passes to them. Tightly couple context and strategy to solve this problem) Increased number of objects
OTHER Model-View-Controller (MVC) This pattern isolates domain logic from the user interface The model manages the behaviour and data of the application domain, The view renders the model into a form suitable for interaction, typically a user interface element. The controller receives input and initiates a response by making calls on model objects. A controller accepts input from the user and instructs the model and viewport to perform actions based on that input. Sometimes considered a framework
FURTHER READING Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (2007). Design Patterns: Elements of Reusable Object-Oriented Software. USA: Addison-Wesley Professional (ISBN 0-201-63361-2) McConell, S. (2004). Code Complete: A Practical Handbook of Software Construction. USA: MICROSOFT PRESS (ISBN 0-735-61967-0) Alur, D., Malks, D., & Crupi, J. (2003). Core J2EE Patterns: Best Practices and Design Strategies. USA: Prentice Hall (ISBN 0-131-42246-4) http://www.dofactory.com/patterns/patterns.aspx http://www.oodesign.com