What are Software Patterns

1. Software Patterns Joseph Bonello

2. Motivation Building software using new frameworks is more complex And expensive There are many methodologies and frameworks to help developers build enterprise application The main problems are: Changes in business logic Technology updates Maintenance Building software is difficult Building reusable software is even harder!

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

4. 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) 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

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

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

7. Creational Patterns We shall be looking at the following Creational Patterns Singleton Pattern Abstract Factory (Kit) Pattern

8. Structural Patterns In this section, we’ll discuss the following patterns Adapter (or Wrapper) Pattern Bridge Pattern Composite Pattern Decorator Pattern Façade Pattern

9. Behavioural Patterns These are some common behavioural patterns: Iterator Pattern Observer Pattern Strategy Pattern

10. Creational Patterns We shall be looking at the following Creational Patterns Singleton Pattern Abstract Factory (Kit) Pattern

11. The Singleton Pattern I Provides a single object throughout the lifetime of an application Provides a single access point to the object 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

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

13. 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)

14. Abstract Factory (Kit) II

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

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

17. Structural Patterns In this section, we’ll discuss the following patterns Adapter (or Wrapper) Pattern Bridge Pattern Composite Pattern Decorator Pattern Façade Pattern

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

19. Adapter (Wrapper) II Benefits: Allow two or more incompatible objects to communicate and interact. Improves reusability of older functionality.

20. 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 onforeseen classes, classes that don't necessarily have compatible interfaces. When you want to use an object in an environment that expects an interface that is diferent from the object's interface. When you must ensure interface translation among multiple sources.

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

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

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

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

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

26. 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)

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

28. 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)

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

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

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

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

33. Behavioural Patterns These are some common behavioural patterns: Iterator Pattern Observer Pattern Strategy Pattern

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

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

36. 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)

37. 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)

38. 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)

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

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

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

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

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

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