Software Patterns<br />Joseph Bonello<br />
Motivation<br />Building software using new frameworks is more complex<br />And expensive<br />There are many methodologie...
Why Patterns?<br />We need a common, tried-and-tested way of building and testing software<br />Especially in those areas ...
Patterns and Anti-patterns<br />A pattern is a general, re-usable solution to a common problem in software design<br />Gam...
What constitutes a pattern?<br />A Pattern has 4 essential elements:<br />A pattern name: Used to refer to a description o...
Categories of Patterns<br />Creational patterns<br />Deal with object creation mechanisms<br />Structural patterns<br />Ea...
Creational Patterns<br />We shall be looking at the following Creational Patterns<br />Singleton Pattern<br />Abstract Fac...
Structural Patterns<br />In this section, we’ll discuss the following patterns<br />Adapter (or Wrapper) Pattern<br />Brid...
Behavioural Patterns<br />These are some common behavioural patterns:<br />Iterator Pattern<br />Observer Pattern<br />Str...
Creational Patterns<br />We shall be looking at the following Creational Patterns<br />Singleton Pattern<br />Abstract Fac...
The Singleton Pattern I<br />Provides a single object throughout the lifetime of an application<br />Provides a single acc...
The Singleton Pattern II<br />Benefits:<br />Controlled access to sole instance (or multiple instances)<br />Avoids “globa...
Abstract Factory (Kit) I<br />Provide an interface for creating families of related or dependent object without specifying...
Abstract Factory (Kit) II<br />
Abstract Factory (Kit) III<br />Use the Abstract Factory pattern when <br />a system should be independent of how its prod...
Abstract Factory (Kit) IV<br />Benefits:<br />Isolates concrete classes<br />Allows to change product family easily<br />P...
Structural Patterns<br />In this section, we’ll discuss the following patterns<br />Adapter (or Wrapper) Pattern<br />Brid...
Adapter (Wrapper) I<br />Convert the interface of a class into another interface clients expect. Adapter lets classes work...
Adapter (Wrapper) II<br />Benefits:<br />Allow two or more incompatible objects to communicate and interact.<br />Improves...
Adapter (Wrapper) III<br />Use when:<br />When you want to use an existing class, and its interface does not match the int...
Bridge (Handle) Pattern I<br />Used to decouple an abstraction from its implementation so that the two can vary independen...
Bridge (Handle) Pattern II<br />Use the pattern when (cont):<br />You have a class hierarchy that proliferates because it ...
Bridge (Handle) Pattern III<br />Known uses<br />GUI frameworks as discussed previously.<br />Persistence Frameworks<br />...
Composite pattern I<br />Used to compose objects into tree structures to represent part-whole hierarchies.  <br />Clients ...
Composite pattern II<br />Use the pattern when:<br />You want to represent part-whole hierarchies of objects<br />You want...
Composite pattern III<br />Example<br />Consequences<br />Define class hierarchies consisting of primitive objects and com...
Decorator (WRAPPER) Pattern I<br />Decorator is used to attach responsibilities to an object dynamically<br />Decorators p...
Decorator (WRAPPER) Pattern II<br />Use the Decorator<br />To add responsibilities to individual objects dynamically and t...
Decorator (WRAPPER) Pattern III<br />Consequences<br />More flexible than static inheritance<br />Easier to add a property...
Façade Pattern I<br />Provides a unified interface to a set of interfaces in a subsystem<br />Defines a higher level inter...
Façade Pattern II<br />Example: Programming environment providing access to its compiler subsystem<br />Higher level inter...
Façade Pattern III<br />Consequences<br />Shields clients from sub-system components<br />Promotes weak coupling between s...
Behavioural Patterns<br />These are some common behavioural patterns:<br />Iterator Pattern<br />Observer Pattern<br />Str...
Iterator (Cursor) Pattern I<br />Provides a way to access the elements of an aggregate object sequentially without exposin...
Iterator (Cursor) Pattern II<br />Use this pattern when you want<br />To access an aggregate object’s contents without exp...
Iterator (Cursor) Pattern III<br />Consequences of using this pattern<br />Supports variations in the traversal of an aggr...
Observer (dependents) Pattern I<br />Defines a one-to-many dependency between objects so that when one object changes stat...
Observer (dependents) Pattern II<br />Used when<br />Abstraction has two aspects, one dependent on the other. Encapsulate ...
Observer (dependents) Pattern III<br />Consequences<br />Abstract coupling between Subject and Observer. Subject knows tha...
Strategy (Policy) Pattern I<br />Define a family of algorithms that encapsulate one another and make them interchangeable<...
Strategy (Policy) Pattern II<br />Use this pattern when<br />Many related classes differ only in their behaviour<br />Need...
Strategy (Policy) Pattern III<br />Consequences<br />Families of related algorithms. Hierarchies of Strategy classes defin...
Other<br />Model-View-Controller (MVC)<br />This pattern isolates domain logic from the user interface<br />The model mana...
Further Reading<br />Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (2007). Design Patterns: Elements of Reusable Objec...
Upcoming SlideShare
Loading in …5
×

Software Patterns

1,127 views
1,057 views

Published on

What are Software Patterns

Published in: Technology
0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,127
On SlideShare
0
From Embeds
0
Number of Embeds
110
Actions
Shares
0
Downloads
0
Comments
0
Likes
5
Embeds 0
No embeds

No notes for slide
  • Code is platform-dependent. Concrete classes here have a specific implementation
  • Widgets with all possible types of borders, scrollbars, etc.
  • Widgets with all possible types of borders, scrollbars, etc.
  • Spreadsheet – same data, different views
  • Spreadsheet – same data, different views
  • Spreadsheet – same data, different views
  • Software Patterns

    1. 1. Software Patterns<br />Joseph Bonello<br />
    2. 2. Motivation<br />Building software using new frameworks is more complex<br />And expensive<br />There are many methodologies and frameworks to help developers build enterprise application<br />The main problems are:<br />Changes in business logic<br />Technology updates<br />Maintenance<br />Building software is difficult<br />Building reusable software is even harder!<br />
    3. 3. Why Patterns?<br />We need a common, tried-and-tested way of building and testing software<br />Especially in those areas where common problems recur<br />The aim is to make it easier to change and maintain software<br />Other aims<br />Developers adopt a common design principle<br />Don’t waste time “hacking” your way into a solution<br />Reference on structures that get the work done efficiently<br />
    4. 4. Patterns and Anti-patterns<br />A pattern is a general, re-usable solution to a common problem in software design<br />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)<br />An anti-pattern is a commonly used pattern but is counterproductive or ineffective in practice<br />Experienced OO designers, in general, do not try to solve a problem from first principles<br />Instead, they prefer to reuse a solution that has worked in the past<br />
    5. 5. What constitutes a pattern?<br />A Pattern has 4 essential elements:<br />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.<br />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.<br />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.<br />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.<br />
    6. 6. Categories of Patterns<br />Creational patterns<br />Deal with object creation mechanisms<br />Structural patterns<br />Ease the design of defining relationships between entities<br />Behavioral patterns<br />Used to identify communication patterns between objects and increase flexibility when carrying out this communication<br />
    7. 7. Creational Patterns<br />We shall be looking at the following Creational Patterns<br />Singleton Pattern<br />Abstract Factory (Kit) Pattern<br />
    8. 8. Structural Patterns<br />In this section, we’ll discuss the following patterns<br />Adapter (or Wrapper) Pattern<br />Bridge Pattern<br />Composite Pattern<br />Decorator Pattern<br />Façade Pattern<br />
    9. 9. Behavioural Patterns<br />These are some common behavioural patterns:<br />Iterator Pattern<br />Observer Pattern<br />Strategy Pattern<br />
    10. 10. Creational Patterns<br />We shall be looking at the following Creational Patterns<br />Singleton Pattern<br />Abstract Factory (Kit) Pattern<br />
    11. 11. The Singleton Pattern I<br />Provides a single object throughout the lifetime of an application<br />Provides a single access point to the object<br />An example would be to have one database connection per client application<br />Used when:<br />There must only be one instance of a class<br />Clients need one single way of accessing the instance<br />
    12. 12. The Singleton Pattern II<br />Benefits:<br />Controlled access to sole instance (or multiple instances)<br />Avoids “global variables” in namespace<br />Permits Subclassing<br />More flexible than static member and methods<br />
    13. 13. Abstract Factory (Kit) I<br />Provide an interface for creating families of related or dependent object without specifying their concrete classes<br />Used to de-couple clients from a particular concrete implementation<br />Example: Different implementations of handling an order’s costs (e.g. TaxCalculator(EU,USA, CN,etc), shipping costs, etc) <br />
    14. 14. Abstract Factory (Kit) II<br />
    15. 15. Abstract Factory (Kit) III<br />Use the Abstract Factory pattern when <br />a system should be independent of how its products are created, composed, and represented. <br />a system should be configured with one of multiple families of products. <br />a family of related product objects is designed to be used together, and you need to enforce this constraint. <br />you want to provide a class library of products, and you want to reveal just their interfaces, not their implementations. <br />
    16. 16. Abstract Factory (Kit) IV<br />Benefits:<br />Isolates concrete classes<br />Allows to change product family easily<br />Promotes consistency among products<br />Factory usually a Singleton; ideally create<Object> should have a type parameter to make it extensible<br />
    17. 17. Structural Patterns<br />In this section, we’ll discuss the following patterns<br />Adapter (or Wrapper) Pattern<br />Bridge Pattern<br />Composite Pattern<br />Decorator Pattern<br />Façade Pattern<br />
    18. 18. Adapter (Wrapper) I<br />Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.<br />Example<br />Merging a new library with an old library you discover two methods with the same name but different parameters<br />
    19. 19. Adapter (Wrapper) II<br />Benefits:<br />Allow two or more incompatible objects to communicate and interact.<br />Improves reusability of older functionality.<br />
    20. 20. Adapter (Wrapper) III<br />Use when:<br />When you want to use an existing class, and its interface does not match the interface you need.<br />When you want to create a reusable class that cooperates with unrelated or onforeseen classes, classes that don't necessarily have compatible interfaces.<br />When you want to use an object in an environment that expects an interface that is diferent from the object's interface.<br />When you must ensure interface translation among multiple sources.<br />
    21. 21. Bridge (Handle) Pattern I<br />Used to decouple an abstraction from its implementation so that the two can vary independently<br />When an abstraction (abstract class) can have several implementations, the usual way to accommodate them is to use inheritance<br />This isn’t always a flexible approach because the implementation binds to the abstraction permanently<br />Use the pattern when:<br />You want to avoid a permanent binding between an abstraction and its implementation<br />Both the abstractions and the implementations should be extensible by sub-classing<br />Changes in the implementation of an abstraction should not impact clients<br />
    22. 22. Bridge (Handle) Pattern II<br />Use the pattern when (cont):<br />You have a class hierarchy that proliferates because it needs to adapt to various specific implementations<br />You want to share an implementation among multiple objects but you want to keep the fact hidden from the client.<br />
    23. 23. Bridge (Handle) Pattern III<br />Known uses<br />GUI frameworks as discussed previously.<br />Persistence Frameworks<br />Consequences:<br />Implementation is not bound permanently to an interface<br />Eliminates compile time dependencies (no recompilation of abstract class)<br />Decoupling encourages layering, therefore a better structured system<br />Improved extensibility<br />Hiding implementation details from clients<br />
    24. 24. Composite pattern I<br />Used to compose objects into tree structures to represent part-whole hierarchies. <br />Clients treat individual objects and compositions of objects uniformly<br />Example<br />Consider graphics applications that allow users to build complex diagrams out of simple components which can be grouped into more complex ones<br />A simple implementation would define classes for graphical primitives and other classes that act as containers for these primitives<br />Problem: code using these classes must treat primitives and objects differently<br />The distinction increases the complexity of the system<br />The pattern uses recursive composition so clients do not make this distinction<br />
    25. 25. Composite pattern II<br />Use the pattern when:<br />You want to represent part-whole hierarchies of objects<br />You want clients to be able to ignore differences between compositions of objects and individual objects<br />
    26. 26. Composite pattern III<br />Example<br />Consequences<br />Define class hierarchies consisting of primitive objects and composite objects<br />Simplifies the client’s architecture<br />Simplifies the process of adding new components<br />The design can be overly general (disadvantage)<br />
    27. 27. Decorator (WRAPPER) Pattern I<br />Decorator is used to attach responsibilities to an object dynamically<br />Decorators provide a flexible alternative to sub-classing for extending functionality<br />Why use it?<br />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)<br />If you use inheritance will affect every instance which will not allow it to vary the choice as it is statically linked<br />The solution is to add the object, called the decorator or wrapper, within another that adds the required property<br />
    28. 28. Decorator (WRAPPER) Pattern II<br />Use the Decorator<br />To add responsibilities to individual objects dynamically and transparently<br />To withdraw responsibilities from the object<br />When extending by sub-classing is impractical or not permitted<br />A large number of independent extensions would result in an explosion of classes<br />A class definition may be hidden or sealed (final)<br />
    29. 29. Decorator (WRAPPER) Pattern III<br />Consequences<br />More flexible than static inheritance<br />Easier to add a property twice (e.g. a widget with a double border)<br />Avoids feature-laden classes up in the hierarchy, reducing complexity. Features are added incrementally with new decorator objects<br />The decorator and its component are identical, the decorator is a transparent enclosure similar to a photograph frame<br />Lots of little objects (disadvantage), difficult to learn and debug<br />Used frequently in UI Toolkits and in the implementation of IO stream classes<br />
    30. 30. Façade Pattern I<br />Provides a unified interface to a set of interfaces in a subsystem<br />Defines a higher level interface that makes the subsystem easier to use<br />Structuring a system into subsystems helps reduce complexity<br />Common design goal is to minimise communication and dependency between subsystems<br />Façade objects provides a single, simplified interface to more general facilities of the sub-system<br />
    31. 31. Façade Pattern II<br />Example: Programming environment providing access to its compiler subsystem<br />Higher level interface shields clients from intricate details of different parts of compiler by allowing access to specific functionality of different subparts<br />Use Façade when:<br />Provide a simple interface to a complex system<br />There are many dependencies between clients and the implementation classes of an abstraction – Façade decouples the sub-system from clients<br />Layer your subsystems. Façade defines the entry to each subsystem layer<br />
    32. 32. Façade Pattern III<br />Consequences<br />Shields clients from sub-system components<br />Promotes weak coupling between sub-system and its clients<br />Reduces compilation dependencies<br />Does not prevent applications from using subsystem classes if they need to<br />
    33. 33. Behavioural Patterns<br />These are some common behavioural patterns:<br />Iterator Pattern<br />Observer Pattern<br />Strategy Pattern<br />
    34. 34. Iterator (Cursor) Pattern I<br />Provides a way to access the elements of an aggregate object sequentially without exposing its underlying representation<br />An aggregate object (e.g. List) should give you a way to access its elements without exposing its structure<br />You might want to traverse the list in many ways, but you want to keep the design and implementation of the List clean<br />The idea of the pattern is to take the responsibility for accessing and traversing the list using at iterator object<br />The iterator keeps track of the current element<br />The List is responsible for creating its own iterator, possibly using a Factory to generalise the operation<br />
    35. 35. Iterator (Cursor) Pattern II<br />Use this pattern when you want<br />To access an aggregate object’s contents without exposing its internal representation<br />Support multiple traversals of aggregate objects<br />Provide a uniform interface for traversing different aggregate structures<br />
    36. 36. Iterator (Cursor) Pattern III<br />Consequences of using this pattern<br />Supports variations in the traversal of an aggregate<br />Simplify the aggregate interface<br />Mode than one traversal can be pending on the same aggregate<br />Known uses: Collection classes (Lists, Vectors, etc)<br />
    37. 37. Observer (dependents) Pattern I<br />Defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically<br />When partitioning a system into a collection of cooperating classes, one needs to maintain consistency between related objects<br />Note that tightly coupling class is not a solution because it reduces reusability<br />The observer pattern describes how to establish common relationships between objects<br />The key objects are the subject and the observer<br />All observer are notified when the subject changes (publish-subscribe model)<br />
    38. 38. Observer (dependents) Pattern II<br />Used when<br />Abstraction has two aspects, one dependent on the other. Encapsulate the objects separately and reuse them independently<br />When a change to one object requires changing the others, and you do not know how many objects to change<br />When an object needs to be able to notify other objects without making assumptions about who these objects are (not tightly coupled)<br />
    39. 39. Observer (dependents) Pattern III<br />Consequences<br />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<br />Support for broadcast communication<br />Unexpected updated (disadvantage). Since observers have no knowledge of other observers, changing the subject might result in undesired updates<br />
    40. 40. Strategy (Policy) Pattern I<br />Define a family of algorithms that encapsulate one another and make them interchangeable<br />Strategy lets the algorithm vary independently of the client that uses them<br />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<br />Client get overly complex<br />Different algorithms will be appropriate at different times<br />Difficult to add new algorithms and vary existing ones<br />
    41. 41. Strategy (Policy) Pattern II<br />Use this pattern when<br />Many related classes differ only in their behaviour<br />Need different variants of an algorithm<br />An algorithm uses data that clients shouldn’t know about (avoid exposing complex, algorithm-specific data structures)<br />A class defines many behaviours that appear as multiple conditional statements in its operators<br />
    42. 42. Strategy (Policy) Pattern III<br />Consequences<br />Families of related algorithms. Hierarchies of Strategy classes define a family of algorithms that can be reused<br />An alternative to sub-classing, which is easier to switch to, understand and extend<br />Strategies eliminate conditional statements<br />Provides a choice of implementations<br />Clients must be aware of different strategies (disadvantage)<br />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)<br />Increased number of objects<br />
    43. 43. Other<br />Model-View-Controller (MVC)<br />This pattern isolates domain logic from the user interface<br />The model manages the behaviour and data of the application domain, <br />The view renders the model into a form suitable for interaction, typically a user interface element. <br />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.<br />Sometimes considered a framework<br />
    44. 44. Further Reading<br />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)<br />McConell, S. (2004). Code Complete: A Practical Handbook of Software Construction. USA: MICROSOFT PRESS (ISBN 0-735-61967-0)<br />Alur, D., Malks, D., & Crupi, J. (2003). Core J2EE Patterns: Best Practices and Design Strategies. USA: Prentice Hall (ISBN 0-131-42246-4)<br />http://www.dofactory.com/Patterns/Patterns.aspx<br />http://www.oodesign.com<br />

    ×