CSCD01 Engineering Large Software Systems. Design Patterns. Joe Bettridge. Winter With thanks to Anya Tafliovich

Size: px
Start display at page:

Download "CSCD01 Engineering Large Software Systems. Design Patterns. Joe Bettridge. Winter With thanks to Anya Tafliovich"

Transcription

1 CSCD01 Engineering Large Software Systems Design Patterns Joe Bettridge Winter 2018 With thanks to Anya Tafliovich

2 Design Patterns Design patterns take the problems consistently found in software, and look to solve them using a reusable design. These patterns describe the way code is laid out, rather than the exact code that would be required This implies that design patterns are language agnostic to a degree We can use UML to easily describe these patterns both structurally and functionally These patterns also represent a means to communicate design decisions which may have been made by other developers, in a common and clean way. It is important to get used to recognizing these within a given code base.

3 Design Patterns First published in a book titled Design Patterns: Elements of Reusable Object-Oriented Software in 1994, although the concept had been around since the late 70 s. The book was published by the Gang of Four (Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides) The original book had 23 patterns, there have been many more created since. The patterns are split in three main groups: Creational Patterns that deal with the mechanics of object creation Structural Patterns that deal with creating simple ways of building relationships between objects Behavioural-Patterns that deal with common communication between objects

4 Design Patterns Slide Layout For the next several lectures, we will be diving into each of the patterns laid out by the gang of four in detail. For each pattern, we will discuss its intended use, the motivation of the pattern, the UML that describes it, and the situations to look for when using it. For some patterns, we will also be going into specific examples in Java or Python, as well as consequences of using it, and common or known issues with the use of the pattern.

5 Gang of Four Patterns Original book describes 23 patterns 5 Creational, 7 Structural, and 11 Behavioural. Creational Patterns Behavioural Patterns Structural Patterns Abstract Factory Chain of Responsibility Adapter Builder Command Bridge Factory Method Interpreter Composite Prototype Iterator Decorator Singleton Mediator Façade Memento Flyweight Observer Proxy State Strategy Template Method Visitor

6 Observer (B) Problem Need to maintain consistency between related classes Two aspects that are dependent upon one another Objects should be able to updated related objects without requiring specific knowledge of those objects Intent Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and update automatically Consequences There is only light, abstract coupling between the Subject and Observer. Since the Subject only knows it has a list of Observers whom conform to the simple Observer Interface Broadcast messaging is achieved, as the Subject does not need to specify the receiver of the message Not easy to trace the cost of an update, as everything is so loosely coupled at a design level, but is highly interdependent at an operation level. Each change to the Subject may cause large cascading changes throughout application, if not carefully controlled for Related Patterns Mediator, Singleton

7 Observer Standard Solution

8 Observer Java Implementation Although Java does provide a default Observer implementation, it does so through an abstract class. This removes the ability to use it alongside custom hierarchies, as Java does not have multiple inheritance. For this reason, most implement their own version of the pattern classes using interfaces.

9 Observer Example in Java

10 Observer Sequence Diagram The standard sequence diagram for Observer is shown to the right. You may also see this drawn without the Par tag.

11 Singleton Pattern (C) Problem How do you ensure that only one instance of a class ever exists? Is there a way to ensure that an object is only created if it is needed? Intent Ensure a class only has one instance and provide a global point of access for it Consequences Strict control on access since the singleton has only one point of entry, this can be easily monitored and controlled Reduced namespace The pattern removes pollution of the global namespace by unnecessary repetition Recent thoughts on Singleton A large number of software engineers now consider Singleton to be a design smell, something that is off in the system. Seeing it used often means something was not well thought out. A notable person with this thought is Erich Gamma, the original creator of the pattern Related Patterns Many patterns can use singleton in their implementation, but this is becoming frowned upon

12 Singleton Standard Solution

13 Iterator Pattern (B) Problem Want to be able to see the objects stored within an aggregator sequentially, but do not want to expose the underlying representation Want to have the ability to iterate over the same aggregation in different, independent ways Intent Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation Consequences Supports variations in the traversal of an aggregate. Complex aggregates may be traversed in many ways Iterators simplify the aggregate interface by removing details about traversal More than one traversal can be pending on an aggregate. Iterators only keep track of their own traversal state, and thus, multiple traversals can be occurring in unison Related Patterns Composite, Factory Method, Memento

14 Iterator Pattern Standard Solution

15 Iterator in Java In java, you will notice that Iterators are most commonly seen with classes that have generics. The iterator pattern is implemented in Java already through the Iterator Interface within java.util package Since Java 5, using the Java Iterable interface allows for you to use foreach loops

16 Strategy Pattern (B) Problem Having multiple classes that only differ in the algorithms used on them (behaviour) Algorithms shouldn t be implemented directly within the class Intent Define a family of algorithms, encapsulating each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it Consequences Families of related algorithms emerge these can be factored out using class hierarchies within the strategies An alternative to sub-classing Sometimes algorithmic differences are only difference between parent and children classes, Strategy removes the need to create specific children Eliminate conditional statements By delegating the choice to the composite class, remove the need for if blocks Choice of implementation Client can pick between multiple strategies that have different time or space trade-offs Clients must be aware of different strategies The pattern can potentially create issues if client doesn t have full awareness Communication overhead between strategy and context Context can create large overhead for simple algorithms that don t need the full set of information that other more complex algorithms need Increased number of objects As each strategy requires its own class, the number of objects can increase Related Patterns Flyweight Strategy often makes good Flyweights

17 Strategy Pattern Standard Solution

18 Example Without Strategy Pattern

19 Using Strategy Pattern

20 Façade Pattern (S) Problem Want a way to hide the complexity of an underlying package from those who use it Some programs have complexities we want to hide from other users Intent Provide a unified interface to a set of interfaces in a subsystem. Façade defines a higher-level interface that makes the subsystems easier to use. (NOTE: In this context interface does not mean an interface type object such as we have in Java, but a point of communication between two areas) Consequences Clients are shielded from subsystem objects, reducing scope of what they need to understand Promotes weak coupling, between subsystems and clients of that system It doesn t explicitly prevent direct use of subclasses, but gives an alternative. Related Patterns Abstract Factory, Mediator, Singleton

21 This is a Façade

22 Façade Standard Solution The Façade does not add any new functionality, nor does it remove previously available functionality. It simply gives an easy to use interface into a subsystem that may have been previously difficult to understand.

23 Façade - Example

24 Adapter Pattern (S) Problem Clients often want things in a format other than what we have, but we do not want to recreate our classes Lets classes work together that otherwise couldn t easily work together by creating an agreed interface Two primary forms: Class adapter (using multiple inheritance) and Object adapter (using object composition) Intent Convert the interface of a class into another interface to meet a clients demand/expectation. Adapter lets classes work together that couldn t otherwise because of incompatible interfaces Consequences Each of the two versions have different consequences which will be broken down on the following slide Related Patterns Bridge, Decorator, Proxy

25 Adapter Two Forms Class Adapter Adapts Adaptee to Target by committing to a concrete Adaptee class. As a consequence, a class adapter won t work when we want to adapt a class and all its subclasses Allows for overriding the Adaptee s behaviour Object Adapter Lets a single adapter work with many adaptees, for example, all subclasses of the adaptee as well as the adaptee itself Makes it difficult to override the methods of the adaptee Consequences How much adapting should be done It can be difficult where to draw the line for when this is an appropriate pattern and when it will end up ultimately creating more work Pluggable adapters a class is more reusable if you minimize the assumptions other classes make to use it. The term refers to building in adapters from the onset Using two-way adapters currently adapter does not allow for two-way adaptation, and it isn t transparent to the client what is happening. This can lead to suboptimal situations

26 Adapter Standard Solution Class Adapter Object Adapter

27 Adapter - Example PROBLEM Suppose there is a shortage of Ducks, and in their place we want to use Penguins, as I mean, they are pretty close What cannot be done Direct substitution of Penguins where we have Ducks. Ducks have some distinctive differences from Penguins, and thus have a different interface! Solution Write a PenguinAdapter class! (Can you even tell which is which?)

28 Adapter - Example

29 Adapter - Example

30 Factory Method Pattern (C) Problem Creating new objects often requires complex logic, which we d ideally like to mask from our clients Often we want to create objects in a fixed way but don t want to store this fixed logic inside the calling class as this creates stronger coupling Intent Define an interface for creating an object but let subclasses decide which class to instantiate. Factory method allows classes to differ instantiation to subclasses Consequences Provides hooks for subclasses Creating objects in a class with a factory method is more flexible Connects parallel class hierarchies Factory methods can be called from either creators or from parallel classes Related Patterns Abstract Factory, Template Method, Prototype

31 Factory Method Standard Solution

32 Factory Method - Example

33 Abstract Factory Pattern (C) Problem Systems should be independent of how their objects are created, composed, or represented A family of related products are designed to be used together, and you need to enforce this constraint Intent Provide an interface for creating families of related or dependent objects without specifying their concrete classes Consequences It isolates concrete classes You can remove the use of concrete class names in client code, meaning if you need to change a concrete implementation, the client never needs to know It makes exchanging product families easy Switching out abstract factories can result in a new functionality without much code change at all It promotes consistency among products as all products will follow a similar design, you end up with more consistent classes Extending product families (new products in same family) is very difficult this is because the abstract factory defines all the products it can create. Adding becomes a major change. Related Patterns Factory Method, Prototype, Singleton

34 Abstract Factory Standard Solution

35 Abstract Factory - Example

36 Abstract Factory Example in Java For this example, we want to give users the ability to at runtime decide if they want the shapes they are seeing to be displayed as text names for the shapes, or ASCII drawings of the shapes. The user will provide a console input of 0 if they want the drawings, and 1 if they want text.

37 Factory Pattern (C) NOTE: Not an official pattern Motivation There is often a need to use some of the elements of Factory Method, and some of the elements of Abstract Factory, without implementing to the totality of both. This is often referred to as the Factory Pattern.

38 Factory Example In this example, assume we have an application for calculating the cost of a construction project. TaxCalculator calculates the tax on our specific items. Quebec and Ontario have different tax rates and rules, and thus need to be handled differently. We may eventually also want to add another province into the project.

39 Decorator Pattern (S) Problem Sometimes we want to give additional responsibilities to an object after it s been defined Want this to be done without impacting other objects When it s impractical to subclass due to the combinatorial explosion of possibilities Intent Attach additional responsibilities to an object dynamically. Decorators allow for a flexible alternative to subclassing when there is a need to extend functionality Consequences More flexibility than static inheritance The decorator pattern provides a more flexible way to add responsibilities to objects Avoids feature-laden classes high up in the hierarchy decorator offers a pay-as-you-go approach to adding responsibilities to classes Lots of little objects these can be a mess to deal with. Can become very complex to debug Related Patterns Adapter, Composite, Strategy

40 Decorator Standard Solution

41 Decorator Example Problem Problem There are many types of pizza, and many different combinations of what can be on a pizza Crust thin, thick, whole wheat Toppings cheese, tomato, anchovies, pineapple, Solution Inheritance? But where is the pineapple??

42 Decorator Example Solution New toppings? Not to worry! Just create another little subclass to PizzaDecorator

43 Decorator Example Solution How exactly is this working? Let s take a quick walkthrough of the code. This is a very simplistic version, but gives you a good general understanding. Finally, would this differ in Python?

44 Chain of Responsibility Pattern Problem Sometimes we have multiple classes that can handle a potential request, and do not know a priori which handler should be used We want to issue a request to one of several potential objects but do not want to explicitly specify the receiver The objects to handle a request should be specified dynamically Intent Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it. Consequences Reduced Coupling The pattern frees an object from knowing which other object handles a request. Added flexibility in assigning responsibility Since the chain can be modified at runtime, you have control over how requests are handled, and can even change based on context Receipt isn t guaranteed Since a request has no explicitly defined receiver there is no guarantee it ll be handled. A request can fall off the end of the chain without being handled. This is usually a configuration issue Related Patterns Often implemented with Component pattern to keep track of the chain of successors

45 Chain of Responsibility - Standard Solution A typical object structure looks something like this:

46 Chain of Responsibility - Java Let s implement a simple chain of responsibility in Java. This chain will be built with a series of loggers. One logger will log to stdout, and another to stderr. Once we understand this chain, we will add a third logger which will output to stdout with a different message than the original stdout logger. Finally, we will draw the command chains for each of the loggers we have setup, as well as the sequence diagram for them on the board.

47 Visitor Pattern (B) Problem You have an object structure with many classes and interfaces and you want to perform operations on these classes that logically should be together We don t want to pollute our object structures with many distinct and unrelated operations. We want to use objects across multiple applications, but some operations are not needed by all applications Our objects are not changing frequently, but the operations we want to apply are Intent Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates. Consequences As there are many important consequences to visitor, they will be covered in the slide after the basic UML and sequence diagrams for Visitor. Related Patterns Composite, Interpreter

48 Visitor Pattern Standard Solution Note: The Accept(Visitor v) operations will in turn call upon the VisitConcreteElement method with itself as a parameter, giving the visitor full access to the Element s object structure.

49 Visitor Pattern Sequence Diagram

50 Visitor Pattern - Consequences Consequences Visitor makes adding new operations easy visitors can be easily created to be run across many objects A visitor gathers related operations and separates unrelated ones you end up with tighter coupling behaviourally, meaning if a behaviour needs modification, it s located in a single place Adding new concrete objects is hard since you need to make a new operation for this object in all visitor classes. You need to make the decision if you will be frequently changing your algorithms or your object structure Visiting can occur across classes Unlike Iterator, that requires each visited node to be of the same type, Visitors can visit classes which are not in the same hierarchy, as long as they have an accept method, and a subsequently appropriate Visit method defined Accumulating state visitors can take on the responsibility of accumulating the state of each element in the object structure. Without this, the state would have to be stored and passed independently Breaking Encapsulation One of the key consequences of visitor is that it requires you to build public methods which have access to state variables within the class directly. This can easily end up breaking the encapsulation of your code!

51 Visitor Pattern - Example Problem We have a well-defined (and not likely to change) structure called an Abstract Syntax Tree Abstract Syntax Tree has various node types, including Variable assignment. A compiler needs to perform various operations on it, including type checking and code generation. Task Use the Visitor pattern to solve the above

52 Visitor Pattern Example Solution

53 Visitor Pattern Another Example Problem When you buy groceries in the supermarket, they come in various types: some need to be weighed, others have a barcode that can be scanned, etc. When it is time to pay, the cash computer will calculate the total price, print a receipt, etc. Task Use the Visitor design pattern to design a solution. How does it work? Show a sequence diagram. How does it work? Show skeleton of Java code.

54 Composite Pattern (S) Problem Sometimes we want to represent only portions of a hierarchy of objects We want our clients to be able to treat individual objects and compositions of objects Intent Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly Consequences Primitive objects (Leaf) and composites can be used interchangeably Clients can treat all related objects the same way, and don t need to worry if they are dealing with a composite or a leaf. This means they don t need complex logic on their end. Makes adding new components easy newly defined composite or leaf subclasses work automatically with existing structures and client code. Clients don t have to be changed for new Component classes to work You need to runtime check if things belong you cannot rely on hierarchy structures to type check you have correct class the solution becomes too general Related Patterns Chain of Responsibility, Decorator, Flyweight, Iterator, Visitor

55 Composite - Standard Solution Notes The composite class is both a component of and an implementation of the component. The Leaf is any class that has no children and is the building block of our composition. You usually will have many classes like Leaf The client uses the component interface to manipulate the Leaf objects stored inside the composite.

56 Composite Example Hierarchy acomposite acomposite aleaf aleaf aleaf aleaf

57 Composite Example in Python Let s build a simple class structure that follows the composite pattern that allows us to add shapes, and print the shape + its name. We will start with code that has only an Ellipse, and will add on a circle and square. Then we will show how the hierarchy of composite can be used.

58 Flyweight Pattern (S) Problem Sometimes we want to represent lots of objects with very similar details, but this would take up too much space Think of things like each character of this document they c an be MAde of many different properties Intent Use Sharing to support large numbers of fine-grained objects efficiently Consequences Flyweight is entirely about a cost of storage to cost of compute trade off. It is very expensive computationally to extrinsically store state for objects, but storing the state on every instance is going to cost even more storage Reducing the number of instances of large objects is the goal of flyweight Related Patterns Composite, State, Strategy Flyweights are often stored using composite pattern to better build a hierarchy of the various states State and Strategy patterns quite often use flyweight objects in their representations

59 Flyweight - Standard Solution ConcreteFlyweight: Implements the flyweight interface and adds storage for intrinsic state, if any. A ConcreteFlyweight object must be shareable. The state must be independent of the context of the object. UnsharedConcreteFlyweight: Not all flyweight subclasses need to be shared. They flyweight interface enables sharing; it doesn t enforce it.

60 Flyweight When to use When to use flyweight Use flyweight when all of the following statements are true about your application: There are a large number of objects storage costs are high because of this quantity of objects most object states can be made extrinsic Many groups of objects can be replaced by a relatively small number of shared objects after making properties extrinsic The application does not depend on object identity

61 Bridge Pattern (S) Problem We want to be able to switch implementations of a abstract class when selected at runtime Changes to the implementation of an abstraction sometimes require recompiling from client side code utilizing them, we want to decouple this Sometimes we want to extend an abstraction independent of the extension of its implementation, or vice versa Intent Decouple an abstraction from its implementation so that the two can vary independently Consequences Decoupling of interface and implementation An implementation is not permanently bound to it s interface. This allows us to even go as far as to switch implementations of an object at runtime Improved extensibility You can extend the abstraction and implementer hierarchies independently Hiding implementation details from clients You can shield implementation details from clients Related Patterns Abstract Factory, Adapter The adapter is the afterthought version of bridge

62 Bridge - Standard Solution

63 Bridge Example in Python Let s look at a simple example in python. We will have two different drawing API s that can be used to draw a simple circle. When we run the code, even though our object types are the same, the API that gets called will be different, due to the storage of the drawing API in the super class Shape at runtime.

64 Prototype Pattern (C) Problem Sometimes we run into situations with complex class hierarchies of both objects and factories that need to expand any time new classes are created Sometimes we have classes that there are only a few possible initial states, and manual instantiation is slow We sometimes don t know how to instantiate a class until runtime, and need to decide then Intent Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype Consequences Very similar to Abstract Factory and Builder pattern in terms of consequences Adding and removing products at runtime Prototypes let you add and remove concrete product classes simply by registering a prototype instance. This allows for clients to add or remove prototypes at runtime Reduced subclassing since you don t need to have a creator class for each concrete class, you reduce the overall complexity of code Related Patterns Composite, Decorator. Competing pattern with Abstract Factory

65 Prototype - Standard Solution

66 Prototype When to use We want to limit our use of prototype to when a system should be independent of how its products are created, composed, and represented, and: The concrete products we want are specified at runtime We don t want to build a factory hierarchy that parallels our object hierarchy When the possible states for a class to be in are limited This requires us to understand what specific states our objects can be in up front. We also need to consider at what point doing hard copying (cloning) is more efficient than instantiating a class this will vary widely, by language.

67 Proxy Pattern (S) Problem Some objects are very expensive to instantiate and we d like to not load the entire object at initialization, but need certain information about that object at runtime We want to limit access to a certain object, so that it only occurs under certain circumstances, but we don t know if those circumstances exist yet Intent Provide a surrogate or placeholder for another object to control access to it Consequences There are several forms of proxies Remote proxy Can be used to hide the fact that an object resides at a different address space Virtual proxy can perform optimizations such as creating objects on demand, when needed Protection proxy Allow for additional housekeeping tasks to occur when an object is accessed Related Patterns Adapter proxy and adapter are similar in that they both provide an altered interface, proxy interfaces match subject exactly Decorator Decorator is like a proxy for responsibility, where a proxy is interested in access and creation

68 Proxy - Standard Solution The Proxy class s DoAction will call upon the RealSubject s DoAction

69 Proxy Example On Initial Load Proxy Once User Scrolls Proxy When a user loads a word document, which contains a large image, the document loads a proxy of the image, which will only fully be loaded dynamically once the user scrolls to the point where it is on screen. If the proxy object was not in place, the rest of the formatting of the document couldn t occur, as the image itself creates constraints on how the text in the document formats.

70 Proxy Sequence Diagram

71 Builder Pattern (C) Problem Telescoping / Cascading constructors we have too many options for how to create an object. We either need to have many different processes for creation, or we need to unify across all implementations (not always practical) We want to be able to separate the logic for object creation from the logic for the object itself Intent Separate the construction of a complex object from its representation so that the same construction process can create different representations Consequences You can vary the internal representation Since your product is not in your consumer s hands until the final execution, all you need to do to modify the built representation is modify the builder (or add another builder) It isolates construction from representation This improves modularity within code greatly. It gives you finer control over the construction process since the builder does not release the product to the director until it is in the final build state, you actually have a lot finer control over what is happening Related Patterns Abstract Factory, Composite

72 Builder - Standard Solution

73 Builder Sequence Diagram

74 Builder Example The Pizza Builder Previously, we used a decorator to create a pizza. It may also make sense to use a builder to build something like a pizza, which has many optional parts, and once it has been settled on, these parts cannot be changed. Let s see how it d work in java!

75 Command Pattern (B) Problem Sometimes we want to develop templates for things like UI s, but do not know what our clients are going to want to produce as actions on elements, such as menus or buttons Intent Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations. Consequences Command decouples the object that invokes the operation from that which performs it Commands are first=class objects that can thus be manipulated like any other object It s easy to add new commands because you can just extend Composite commands can be created (following the composite pattern s behaviour) Related Patterns Composite, Memento, Prototype

76 Command - Standard Solution

77 Command Sequence Diagram

78 Command Example

79 State Pattern (B) Problem Our object s operations are dependent on the state of the object, and have large conditional blocks which are mirrored to each other, and we d like to reduce the class complexity Intent Allow an object to alter its behaviour when its internal state changes. The object will appear to change its class. Consequences It localizes state-specific behaviour All state-specific code becomes encapsulated in an object, it means that introducing new states does not impact objects, and updating one state only requires changes to that state object and not the class that will be in said state It makes state transition specific Since the type of object that State is subclassed to will result in the state, it becomes very explicit when a transition has occurred State objects can be shared If a state has no specific instance variables associated with it, it can be shared between multiple objects, and essentially becomes a flyweight Related Patterns Flyweight

80 State - Standard Solution State is an abstract class Context will contain a state instance variable instantiated with the specific concrete state belonging to the current state of context. When context methods are called, if they are state specific, they will call upon the state object that is currently held resulting in the state-specific behaviour

81 State Simplifying code Consider the code to the left. We have code for a door class. The door has two states Open and Closed. Inside each method within our code, we need to check if the door is in an open state, or a closed state before we can proceed to completing our actions. Fix this code using State pattern on board! public void msgstate() { if (this.dooropen) { System.out.println("The door is open"); } else { System.out.println("The door is closed"); } } public void enter() { if (this.dooropen) { currentroom = nextroom(); } else { door.open(); currentroom = nextroom(); } }

82 Memento Pattern (B) Problem Sometimes we want to be able to undo actions that have occurred, either due to error, or change in user behaviour We want to be able to complete the above behaviour without violating the objects encapsulation of data Intent Without violating encapsulation, capture and externalize an object s internal state so that the object can be restored to that state later. Consequences Consequences will be on the slide following the pattern, as they require some understanding of it s inner workings Related Patterns Command, Iterator memento s can be used as iterators (Can anyone think of how?)

83 Memento - Standard Solution

84 Memento - Consequences Preserves encapsulation boundaries By storing information external to the originator, but only storing what is necessary to maintain state, the memento preserves encapsulation Simplifies originator Without the memento, the originator would have to store several previous states, and require logic for how and when to access these pieces of information Using Mementos can be expensive If we follow a naïve approach to how the details are stored, the amount of space required, and processor use to store this information can become very large. Defining narrow and wide interfaces It can be difficult to ensure that only the originator has access to the memento s state in certain languages (NOTE: This isn t just about python think about how best to do this in Java) Hidden costs in caring for mementos A caretaker is responsible for deleting mementos, however, the caretaker has no idea how much stat is in the memento. Thus, a caretaker which may seem lightweight can actually be much larger than is expected

85 Memento Sequence Diagram Note: The caretaker may never actually call on getstate, as the originator will not need to be reverted. Mementos are passive, only the originator will assign or retrieve a state. The memento has no activities it completes.

86 Mediator Pattern (B) Problem Sometimes our systems have series of complex objects that intercommunicate in well-defined ways, which we want to decouple Reusing objects like these has become difficult due to their close coupling 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 interactions independently. Consequences It limits subclassing the mediator localizes behaviour that traditionally would be distributed across many subclasses Decouples classes by pulling out interaction behaviour, classes stop being closely coupled with one another It abstracts how objects communicate objects can be focused on their tasks, and not need to worry about how they will update each other Centralizes control the mediator class in the centre takes care of all of the other classes Related Patterns Different than façade in that mediator focuses on objects vs sub-systems. Observer is often used for communication

87 Mediator - Standard Solution The Mediator object will store a list of Colleagues, and have functions for when specific colleagues have changed. This behaviour will be setup using an Observer pattern.

88 Mediator - Example Let s look at a simple example of a web form, where a user can select multiple entries from a list. Once the selection is made, we want the text field above the list to update. We don t want the list object or the text box object to know about each other directly. [Draw sequence diagram for this on board]

89 Hollywood Principle Don t call us. We will call you. Template Method Pattern Problem We want to be able to represent invariant parts of algorithms in different ways We want to refactor common elements of subclasses into a unique area, even when these aren t in the same method Intent Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template method lets subclasses redefine certain steps of an algorithm without changing the algorithm s structure. Consequences Template methods are common in class libraries and implement what is often called the Hollywood principle*, as the parent class calls the methods of the subclass Template methods can run in several forms they can either override parent behaviour entirely, partially, or not at all Related Patterns Strategy strategy is the equivalent of template method for an entire algorithm, as opposed to a portion

90 Template Method - Standard Solution The Abstract class has a templated method, made up of several primitive operations, which are usually not defined at the Abstract class level. Each concrete class implementing the abstract class will then implement these primitive operations. When TemplateMethod is called, it will incorporate the subclass specific versions of these pieces of the method.

91 Interpreter Pattern (B) Problem We want to be able to represent a language by it s grammar independently of it s interpretation Intent Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentence in that language. Consequences The grammar is easy to extend or change since classes represent the grammar rules, you can use inheritance to change or extend the grammar Implementing the grammar is easy The classes for the grammar become simple to write, resulting in an easy way to implement a language Complex grammars become hard to maintain Each rule in the grammar requires at least one class, this can quickly become complicated to follow as the grammar gets larger Related Patterns Composite, flyweight, iterator, visitor

92 Interpreter - Standard Solution

93 Questions?

94 QUIZ 1 GRADES % of Class 60.75% of Class

CSCD01 Engineering Large Software Systems. Design Patterns. Joe Bettridge. Winter With thanks to Anya Tafliovich

CSCD01 Engineering Large Software Systems. Design Patterns. Joe Bettridge. Winter With thanks to Anya Tafliovich CSCD01 Engineering Large Software Systems Design Patterns Joe Bettridge Winter 2018 With thanks to Anya Tafliovich Design Patterns Design patterns take the problems consistently found in software, and

More information

CSCD01 Engineering Large Software Systems. Design Patterns. Joe Bettridge. Winter With thanks to Anya Tafliovich

CSCD01 Engineering Large Software Systems. Design Patterns. Joe Bettridge. Winter With thanks to Anya Tafliovich CSCD01 Engineering Large Software Systems Design Patterns Joe Bettridge Winter 2018 With thanks to Anya Tafliovich Design Patterns Design patterns take the problems consistently found in software, and

More information

Design Pattern. CMPSC 487 Lecture 10 Topics: Design Patterns: Elements of Reusable Object-Oriented Software (Gamma, et al.)

Design Pattern. CMPSC 487 Lecture 10 Topics: Design Patterns: Elements of Reusable Object-Oriented Software (Gamma, et al.) Design Pattern CMPSC 487 Lecture 10 Topics: Design Patterns: Elements of Reusable Object-Oriented Software (Gamma, et al.) A. Design Pattern Design patterns represent the best practices used by experienced

More information

SDC Design patterns GoF

SDC Design patterns GoF SDC Design patterns GoF Design Patterns The design pattern concept can be viewed as an abstraction of imitating useful parts of other software products. The design pattern is a description of communicating

More information

Produced by. Design Patterns. MSc in Communications Software. Eamonn de Leastar

Produced by. Design Patterns. MSc in Communications Software. Eamonn de Leastar Design Patterns MSc in Communications Software Produced by Eamonn de Leastar (edeleastar@wit.ie) Department of Computing, Maths & Physics Waterford Institute of Technology http://www.wit.ie http://elearning.wit.ie

More information

EPL 603 TOPICS IN SOFTWARE ENGINEERING. Lab 6: Design Patterns

EPL 603 TOPICS IN SOFTWARE ENGINEERING. Lab 6: Design Patterns EPL 603 TOPICS IN SOFTWARE ENGINEERING Lab 6: Design Patterns Links to Design Pattern Material 1 http://www.oodesign.com/ http://www.vincehuston.org/dp/patterns_quiz.html Types of Design Patterns 2 Creational

More information

The Strategy Pattern Design Principle: Design Principle: Design Principle:

The Strategy Pattern Design Principle: Design Principle: Design Principle: Strategy Pattern The Strategy Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it. Design

More information

Object-Oriented Oriented Programming

Object-Oriented Oriented Programming Object-Oriented Oriented Programming Composite Pattern CSIE Department, NTUT Woei-Kae Chen Catalog of Design patterns Creational patterns Abstract Factory, Builder, Factory Method, Prototype, Singleton

More information

Topics in Object-Oriented Design Patterns

Topics in Object-Oriented Design Patterns Software design Topics in Object-Oriented Design Patterns Material mainly from the book Design Patterns by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides; slides originally by Spiros Mancoridis;

More information

Design Patterns Reid Holmes

Design Patterns Reid Holmes Material and some slide content from: - Head First Design Patterns Book - GoF Design Patterns Book Design Patterns Reid Holmes GoF design patterns $ %!!!! $ "! # & Pattern vocabulary Shared vocabulary

More information

Ingegneria del Software Corso di Laurea in Informatica per il Management. Design Patterns part 1

Ingegneria del Software Corso di Laurea in Informatica per il Management. Design Patterns part 1 Ingegneria del Software Corso di Laurea in Informatica per il Management Design Patterns part 1 Davide Rossi Dipartimento di Informatica Università di Bologna Pattern Each pattern describes a problem which

More information

Object-Oriented Design

Object-Oriented Design Object-Oriented Design Lecture 20 GoF Design Patterns Behavioral Department of Computer Engineering Sharif University of Technology 1 GoF Behavioral Patterns Class Class Interpreter: Given a language,

More information

Using Design Patterns in Java Application Development

Using Design Patterns in Java Application Development Using Design Patterns in Java Application Development ExxonMobil Research & Engineering Co. Clinton, New Jersey Michael P. Redlich (908) 730-3416 michael.p.redlich@exxonmobil.com About Myself Degree B.S.

More information

Modellistica Medica. Maria Grazia Pia, INFN Genova. Scuola di Specializzazione in Fisica Sanitaria Genova Anno Accademico

Modellistica Medica. Maria Grazia Pia, INFN Genova. Scuola di Specializzazione in Fisica Sanitaria Genova Anno Accademico Modellistica Medica Maria Grazia Pia INFN Genova Scuola di Specializzazione in Fisica Sanitaria Genova Anno Accademico 2002-2003 Lezione 9 OO modeling Design Patterns Structural Patterns Behavioural Patterns

More information

Design patterns. Jef De Smedt Beta VZW

Design patterns. Jef De Smedt Beta VZW Design patterns Jef De Smedt Beta VZW Who Beta VZW www.betavzw.org Association founded in 1993 Computer training for the unemployed Computer training for employees (Cevora/Cefora) 9:00-12:30 13:00-16:00

More information

Design Patterns. Manuel Mastrofini. Systems Engineering and Web Services. University of Rome Tor Vergata June 2011

Design Patterns. Manuel Mastrofini. Systems Engineering and Web Services. University of Rome Tor Vergata June 2011 Design Patterns Lecture 2 Manuel Mastrofini Systems Engineering and Web Services University of Rome Tor Vergata June 2011 Structural patterns Part 2 Decorator Intent: It attaches additional responsibilities

More information

Design Patterns. An introduction

Design Patterns. An introduction Design Patterns An introduction Introduction Designing object-oriented software is hard, and designing reusable object-oriented software is even harder. Your design should be specific to the problem at

More information

Brief Note on Design Pattern

Brief Note on Design Pattern Brief Note on Design Pattern - By - Channu Kambalyal channuk@yahoo.com This note is based on the well-known book Design Patterns Elements of Reusable Object-Oriented Software by Erich Gamma et., al.,.

More information

Design of Software Systems (Ontwerp van SoftwareSystemen) Design Patterns Reference. Roel Wuyts

Design of Software Systems (Ontwerp van SoftwareSystemen) Design Patterns Reference. Roel Wuyts Design of Software Systems (Ontwerp van SoftwareSystemen) Design Patterns Reference 2015-2016 Visitor See lecture on design patterns Design of Software Systems 2 Composite See lecture on design patterns

More information

Object Oriented Paradigm

Object Oriented Paradigm Object Oriented Paradigm Ming-Hwa Wang, Ph.D. Department of Computer Engineering Santa Clara University Object Oriented Paradigm/Programming (OOP) similar to Lego, which kids build new toys from assembling

More information

Design Patterns. Manuel Mastrofini. Systems Engineering and Web Services. University of Rome Tor Vergata June 2011

Design Patterns. Manuel Mastrofini. Systems Engineering and Web Services. University of Rome Tor Vergata June 2011 Design Patterns Lecture 1 Manuel Mastrofini Systems Engineering and Web Services University of Rome Tor Vergata June 2011 Definition A pattern is a reusable solution to a commonly occurring problem within

More information

Slide 1. Design Patterns. Prof. Mirco Tribastone, Ph.D

Slide 1. Design Patterns. Prof. Mirco Tribastone, Ph.D Slide 1 Design Patterns Prof. Mirco Tribastone, Ph.D. 22.11.2011 Introduction Slide 2 Basic Idea The same (well-established) schema can be reused as a solution to similar problems. Muster Abstraktion Anwendung

More information

Software Design Patterns. Background 1. Background 2. Jonathan I. Maletic, Ph.D.

Software Design Patterns. Background 1. Background 2. Jonathan I. Maletic, Ph.D. Software Design Patterns Jonathan I. Maletic, Ph.D. Department of Computer Science Kent State University J. Maletic 1 Background 1 Search for recurring successful designs emergent designs from practice

More information

Facade and Adapter. Comp-303 : Programming Techniques Lecture 19. Alexandre Denault Computer Science McGill University Winter 2004

Facade and Adapter. Comp-303 : Programming Techniques Lecture 19. Alexandre Denault Computer Science McGill University Winter 2004 Facade and Adapter Comp-303 : Programming Techniques Lecture 19 Alexandre Denault Computer Science McGill University Winter 2004 March 23, 2004 Lecture 19 Comp 303 : Facade and Adapter Page 1 Last lecture...

More information

DESIGN PATTERN - INTERVIEW QUESTIONS

DESIGN PATTERN - INTERVIEW QUESTIONS DESIGN PATTERN - INTERVIEW QUESTIONS http://www.tutorialspoint.com/design_pattern/design_pattern_interview_questions.htm Copyright tutorialspoint.com Dear readers, these Design Pattern Interview Questions

More information

Design Patterns Reid Holmes

Design Patterns Reid Holmes Material and some slide content from: - Head First Design Patterns Book - GoF Design Patterns Book Design Patterns Reid Holmes GoF design patterns $ %!!!! $ "! # & Pattern vocabulary Shared vocabulary

More information

Socket attaches to a Ratchet. 2) Bridge Decouple an abstraction from its implementation so that the two can vary independently.

Socket attaches to a Ratchet. 2) Bridge Decouple an abstraction from its implementation so that the two can vary independently. Gang of Four Software Design Patterns with examples STRUCTURAL 1) Adapter Convert the interface of a class into another interface clients expect. It lets the classes work together that couldn't otherwise

More information

Software Eningeering. Lecture 9 Design Patterns 2

Software Eningeering. Lecture 9 Design Patterns 2 Software Eningeering Lecture 9 Design Patterns 2 Patterns covered Creational Abstract Factory, Builder, Factory Method, Prototype, Singleton Structural Adapter, Bridge, Composite, Decorator, Facade, Flyweight,

More information

Design Patterns Lecture 2

Design Patterns Lecture 2 Design Patterns Lecture 2 Josef Hallberg josef.hallberg@ltu.se 1 Patterns covered Creational Abstract Factory, Builder, Factory Method, Prototype, Singleton Structural Adapter, Bridge, Composite, Decorator,

More information

Tuesday, October 4. Announcements

Tuesday, October 4. Announcements Tuesday, October 4 Announcements www.singularsource.net Donate to my short story contest UCI Delta Sigma Pi Accepts business and ICS students See Facebook page for details Slide 2 1 Design Patterns Design

More information

Introduction to Software Engineering: Object Design I Reuse & Patterns

Introduction to Software Engineering: Object Design I Reuse & Patterns Introduction to Software Engineering: Object Design I Reuse & Patterns John T. Bell Department of Computer Science University of Illinois, Chicago Based on materials from Bruegge & DuToit 3e, Chapter 8,

More information

THOMAS LATOZA SWE 621 FALL 2018 DESIGN PATTERNS

THOMAS LATOZA SWE 621 FALL 2018 DESIGN PATTERNS THOMAS LATOZA SWE 621 FALL 2018 DESIGN PATTERNS LOGISTICS HW3 due today HW4 due in two weeks 2 IN CLASS EXERCISE What's a software design problem you've solved from an idea you learned from someone else?

More information

Design Patterns. Comp2110 Software Design. Department of Computer Science Australian National University. Second Semester

Design Patterns. Comp2110 Software Design. Department of Computer Science Australian National University. Second Semester Design Patterns Comp2110 Software Design Department of Computer Science Australian National University Second Semester 2005 1 Design Pattern Space Creational patterns Deal with initializing and configuring

More information

Think of drawing/diagramming editors. ECE450 Software Engineering II. The problem. The Composite pattern

Think of drawing/diagramming editors. ECE450 Software Engineering II. The problem. The Composite pattern Think of drawing/diagramming editors ECE450 Software Engineering II Drawing/diagramming editors let users build complex diagrams out of simple components The user can group components to form larger components......which

More information

What is Design Patterns?

What is Design Patterns? Paweł Zajączkowski What is Design Patterns? 1. Design patterns may be said as a set of probable solutions for a particular problem which is tested to work best in certain situations. 2. In other words,

More information

Applying the Observer Design Pattern

Applying the Observer Design Pattern Applying the Observer Design Pattern Trenton Computer Festival Professional Seminars Michael P. Redlich (908) 730-3416 michael.p.redlich@exxonmobil.com About Myself Degree B.S. in Computer Science Rutgers

More information

An Introduction to Patterns

An Introduction to Patterns An Introduction to Patterns Robert B. France Colorado State University Robert B. France 1 What is a Pattern? - 1 Work on software development patterns stemmed from work on patterns from building architecture

More information

Design Patterns V Structural Design Patterns, 2

Design Patterns V Structural Design Patterns, 2 Structural Design Patterns, 2 COMP2110/2510 Software Design Software Design for SE September 17, 2008 Department of Computer Science The Australian National University 19.1 1 2 Formal 3 Formal 4 Formal

More information

Object-oriented Software Design Patterns

Object-oriented Software Design Patterns Object-oriented Software Design Patterns Concepts and Examples Marcelo Vinícius Cysneiros Aragão marcelovca90@inatel.br Topics What are design patterns? Benefits of using design patterns Categories and

More information

Composite Pattern. IV.4 Structural Pattern

Composite Pattern. IV.4 Structural Pattern IV.4 Structural Pattern Motivation: Compose objects to realize new functionality Flexible structures that can be changed at run-time Problems: Fixed class for every composition is required at compile-time

More information

Design Patterns IV Structural Design Patterns, 1

Design Patterns IV Structural Design Patterns, 1 Structural Design Patterns, 1 COMP2110/2510 Software Design Software Design for SE September 17, 2008 Class Object Department of Computer Science The Australian National University 18.1 1 2 Class Object

More information

SOFTWARE PATTERNS. Joseph Bonello

SOFTWARE PATTERNS. Joseph Bonello 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

More information

Keywords: Abstract Factory, Singleton, Factory Method, Prototype, Builder, Composite, Flyweight, Decorator.

Keywords: Abstract Factory, Singleton, Factory Method, Prototype, Builder, Composite, Flyweight, Decorator. Comparative Study In Utilization Of Creational And Structural Design Patterns In Solving Design Problems K.Wseem Abrar M.Tech., Student, Dept. of CSE, Amina Institute of Technology, Shamirpet, Hyderabad

More information

Goals of Lecture. Lecture 27: OO Design Patterns. Pattern Resources. Design Patterns. Cover OO Design Patterns. Pattern Languages of Programming

Goals of Lecture. Lecture 27: OO Design Patterns. Pattern Resources. Design Patterns. Cover OO Design Patterns. Pattern Languages of Programming Goals of Lecture Lecture 27: OO Design Patterns Cover OO Design Patterns Background Examples Kenneth M. Anderson Object-Oriented Analysis and Design CSCI 6448 - Spring Semester, 2001 April 24, 2001 Kenneth

More information

1 Software Architecture

1 Software Architecture Some buzzwords and acronyms for today Software architecture Design pattern Separation of concerns Single responsibility principle Keep it simple, stupid (KISS) Don t repeat yourself (DRY) Don t talk to

More information

Object Oriented Methods with UML. Introduction to Design Patterns- Lecture 8

Object Oriented Methods with UML. Introduction to Design Patterns- Lecture 8 Object Oriented Methods with UML Introduction to Design Patterns- Lecture 8 Topics(03/05/16) Design Patterns Design Pattern In software engineering, a design pattern is a general repeatable solution to

More information

Design Patterns IV. Alexei Khorev. 1 Structural Patterns. Structural Patterns. 2 Adapter Design Patterns IV. Alexei Khorev. Structural Patterns

Design Patterns IV. Alexei Khorev. 1 Structural Patterns. Structural Patterns. 2 Adapter Design Patterns IV. Alexei Khorev. Structural Patterns Structural Design Patterns, 1 1 COMP2110/2510 Software Design Software Design for SE September 17, 2008 2 3 Department of Computer Science The Australian National University 4 18.1 18.2 GoF Structural

More information

Application Architectures, Design Patterns

Application Architectures, Design Patterns Application Architectures, Design Patterns Martin Ledvinka martin.ledvinka@fel.cvut.cz Winter Term 2017 Martin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design Patterns Winter Term

More information

Applying Design Patterns to accelerate development of reusable, configurable and portable UVCs. Accellera Systems Initiative 1

Applying Design Patterns to accelerate development of reusable, configurable and portable UVCs. Accellera Systems Initiative 1 Applying Design Patterns to accelerate development of reusable, configurable and portable UVCs. Accellera Systems Initiative 1 About the presenter Paul Kaunds Paul Kaunds is a Verification Consultant at

More information

The GoF Design Patterns Reference

The GoF Design Patterns Reference The GoF Design Patterns Reference Version.0 / 0.0.07 / Printed.0.07 Copyright 0-07 wsdesign. All rights reserved. The GoF Design Patterns Reference ii Table of Contents Preface... viii I. Introduction....

More information

Design Patterns. SE3A04 Tutorial. Jason Jaskolka

Design Patterns. SE3A04 Tutorial. Jason Jaskolka SE3A04 Tutorial Jason Jaskolka Department of Computing and Software Faculty of Engineering McMaster University Hamilton, Ontario, Canada jaskolj@mcmaster.ca November 18/19, 2014 Jason Jaskolka 1 / 35 1

More information

Information systems modelling UML and service description languages

Information systems modelling UML and service description languages Internet Engineering Tomasz Babczyński, Zofia Kruczkiewicz Tomasz Kubik Information systems modelling UML and service description languages Overview of design patterns for supporting information systems

More information

Software Engineering Prof. Rushikesh K.Joshi IIT Bombay Lecture-15 Design Patterns

Software Engineering Prof. Rushikesh K.Joshi IIT Bombay Lecture-15 Design Patterns Software Engineering Prof. Rushikesh K.Joshi IIT Bombay Lecture-15 Design Patterns Today we are going to talk about an important aspect of design that is reusability of design. How much our old design

More information

Last Lecture. Lecture 17: Design Patterns (part 2) Kenneth M. Anderson Object-Oriented Analysis and Design CSCI 4448/ Spring Semester, 2005

Last Lecture. Lecture 17: Design Patterns (part 2) Kenneth M. Anderson Object-Oriented Analysis and Design CSCI 4448/ Spring Semester, 2005 1 Lecture 17: Design Patterns (part 2) Kenneth M. Anderson Object-Oriented Analysis and Design CSCI 4448/6448 - Spring Semester, 2005 2 Last Lecture Design Patterns Background and Core Concepts Examples

More information

Lecture 20: Design Patterns II

Lecture 20: Design Patterns II Lecture 20: Design Patterns II Software System Design and Implementation ITCS/ITIS 6112/8112 001 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte Nov.

More information

A Reconnaissance on Design Patterns

A Reconnaissance on Design Patterns A Reconnaissance on Design Patterns M.Chaithanya Varma Student of computer science engineering, Sree Vidhyanikethan Engineering college, Tirupati, India ABSTRACT: In past decade, design patterns have been

More information

Second Midterm Review

Second Midterm Review Second Midterm Review Comp-303 : Programming Techniques Lecture 24 Alexandre Denault Computer Science McGill University Winter 2004 April 5, 2004 Lecture 24 Comp 303 : Second Midterm Review Page 1 Announcements

More information

Applying the Factory Method Design Pattern

Applying the Factory Method Design Pattern Applying the Factory Method Design Pattern Trenton Computer Festival Professional Seminars Michael P. Redlich (908) 730-3416 michael.p.redlich@exxonmobil.com About Myself Degree B.S. in Computer Science

More information

Software Design COSC 4353/6353 D R. R A J S I N G H

Software Design COSC 4353/6353 D R. R A J S I N G H Software Design COSC 4353/6353 D R. R A J S I N G H Design Patterns What are design patterns? Why design patterns? Example DP Types Toolkit, Framework, and Design Pattern A toolkit is a library of reusable

More information

Design Patterns. (and anti-patterns)

Design Patterns. (and anti-patterns) Design Patterns (and anti-patterns) Design Patterns The Gang of Four defined the most common object-oriented patterns used in software. These are only the named ones Lots more variations exist Design Patterns

More information

Idioms and Design Patterns. Martin Skogevall IDE, Mälardalen University

Idioms and Design Patterns. Martin Skogevall IDE, Mälardalen University Idioms and Design Patterns Martin Skogevall IDE, Mälardalen University 2005-04-07 Acronyms Object Oriented Analysis and Design (OOAD) Object Oriented Programming (OOD Software Design Patterns (SDP) Gang

More information

Design Patterns. CSC207 Fall 2017

Design Patterns. CSC207 Fall 2017 Design Patterns CSC207 Fall 2017 Design Patterns A design pattern is a general description of the solution to a well-established problem using an arrangement of classes and objects. Patterns describe the

More information

Design Patterns: Structural and Behavioural

Design Patterns: Structural and Behavioural Design Patterns: Structural and Behavioural 3 April 2009 CMPT166 Dr. Sean Ho Trinity Western University See also: Vince Huston Review last time: creational Design patterns: Reusable templates for designing

More information

Applying the Decorator Design Pattern

Applying the Decorator Design Pattern Applying the Decorator Design Pattern Trenton Computer Festival Professional Seminars Michael P. Redlich (908) 730-3416 michael.p.redlich@exxonmobil.com About Myself Degree B.S. in Computer Science Rutgers

More information

The Design Patterns Matrix From Analysis to Implementation

The Design Patterns Matrix From Analysis to Implementation The Design Patterns Matrix From Analysis to Implementation This is an excerpt from Shalloway, Alan and James R. Trott. Design Patterns Explained: A New Perspective for Object-Oriented Design. Addison-Wesley

More information

administrivia today UML start design patterns Tuesday, September 28, 2010

administrivia today UML start design patterns Tuesday, September 28, 2010 administrivia Assignment 2? promise to get past assignment 1 back soon exam on monday review slides are posted your responsibility to review covers through last week today UML start design patterns 1 Unified

More information

Design Patterns. CSC207 Winter 2017

Design Patterns. CSC207 Winter 2017 Design Patterns CSC207 Winter 2017 Design Patterns A design pattern is a general description of the solution to a well-established problem using an arrangement of classes and objects. Patterns describe

More information

Ingegneria del Software Corso di Laurea in Informatica per il Management. Design Patterns part 1

Ingegneria del Software Corso di Laurea in Informatica per il Management. Design Patterns part 1 Ingegneria del Software Corso di Laurea in Informatica per il Management Design Patterns part 1 Davide Rossi Dipartimento di Informatica Università di Bologna Pattern Each pattern describes a problem which

More information

Last Lecture. Lecture 26: Design Patterns (part 2) State. Goals of Lecture. Design Patterns

Last Lecture. Lecture 26: Design Patterns (part 2) State. Goals of Lecture. Design Patterns Lecture 26: Design Patterns (part 2) Kenneth M. Anderson Object-Oriented Analysis and Design CSCI 6448 - Spring Semester, 2003 Last Lecture Design Patterns Background and Core Concepts Examples Singleton,

More information

Modellistica Medica. Maria Grazia Pia, INFN Genova. Scuola di Specializzazione in Fisica Sanitaria Genova Anno Accademico

Modellistica Medica. Maria Grazia Pia, INFN Genova. Scuola di Specializzazione in Fisica Sanitaria Genova Anno Accademico Modellistica Medica Maria Grazia Pia INFN Genova Scuola di Specializzazione in Fisica Sanitaria Genova Anno Accademico 2002-2003 Lezione 8 OO modeling Design Patterns Introduction Creational Patterns Software

More information

Design patterns. OOD Lecture 6

Design patterns. OOD Lecture 6 Design patterns OOD Lecture 6 Next lecture Monday, Oct 1, at 1:15 pm, in 1311 Remember that the poster sessions are in two days Thursday, Sep 27 1:15 or 3:15 pm (check which with your TA) Room 2244 + 2245

More information

Design Pattern What is a Design Pattern? Design Pattern Elements. Almas Ansari Page 1

Design Pattern What is a Design Pattern? Design Pattern Elements. Almas Ansari Page 1 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 problem Novelists, playwrights and other writers rarely

More information

DESIGN PATTERNS FOR MERE MORTALS

DESIGN PATTERNS FOR MERE MORTALS DESIGN PATTERNS FOR MERE MORTALS Philip Japikse (@skimedic) skimedic@outlook.com www.skimedic.com/blog Microsoft MVP, ASPInsider, MCSD, MCDBA, CSM, CSP Consultant, Teacher, Writer Phil.About() Consultant,

More information

Lectures 24 and 25 Introduction to Architectural Styles and Design Patterns

Lectures 24 and 25 Introduction to Architectural Styles and Design Patterns Lectures 24 and 25 Introduction to Architectural Styles and Design Patterns Software Engineering ITCS 3155 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte

More information

6.3 Patterns. Definition: Design Patterns

6.3 Patterns. Definition: Design Patterns Subject/Topic/Focus: Analysis and Design Patterns Summary: What is a pattern? Why patterns? 6.3 Patterns Creational, structural and behavioral patterns Examples: Abstract Factory, Composite, Chain of Responsibility

More information

What is Design Patterns?

What is Design Patterns? Paweł Zajączkowski What is Design Patterns? 1. Design patterns may be said as a set of probable solutions for a particular problem which is tested to work best in certain situations. 2. In other words,

More information

SOLID DESIGN PATTERNS FOR MERE MORTALS

SOLID DESIGN PATTERNS FOR MERE MORTALS SOLID DESIGN PATTERNS FOR MERE MORTALS Philip Japikse (@skimedic) skimedic@outlook.com www.skimedic.com/blog Microsoft MVP, ASPInsider, MCSD, MCDBA, CSM, PSM, PSD Consultant, Teacher, Writer Phil.About()

More information

An Introduction to Patterns

An Introduction to Patterns An Introduction to Patterns Robert B. France Colorado State University Robert B. France 1 What is a Pattern? Patterns are intended to capture the best available software development experiences in the

More information

Design Patterns. Dr. Rania Khairy. Software Engineering and Development Tool

Design Patterns. Dr. Rania Khairy. Software Engineering and Development Tool Design Patterns What are Design Patterns? What are Design Patterns? Why Patterns? Canonical Cataloging Other Design Patterns Books: Freeman, Eric and Elisabeth Freeman with Kathy Sierra and Bert Bates.

More information

Trusted Components. Reuse, Contracts and Patterns. Prof. Dr. Bertrand Meyer Dr. Karine Arnout

Trusted Components. Reuse, Contracts and Patterns. Prof. Dr. Bertrand Meyer Dr. Karine Arnout 1 Last update: 2 November 2004 Trusted Components Reuse, Contracts and Patterns Prof. Dr. Bertrand Meyer Dr. Karine Arnout 2 Lecture 5: Design patterns Agenda for today 3 Overview Benefits of patterns

More information

Design Patterns. Gunnar Gotshalks A4-1

Design Patterns. Gunnar Gotshalks A4-1 Design Patterns A4-1 On Design Patterns A design pattern systematically names, explains and evaluates an important and recurring design problem and its solution Good designers know not to solve every problem

More information

APPLYING DESIGN PATTERNS TO SCA IMPLEMENTATIONS

APPLYING DESIGN PATTERNS TO SCA IMPLEMENTATIONS APPLYING DESIGN PATTERNS TO SCA IMPLEMENTATIONS Adem Zumbul (TUBITAK-UEKAE, Kocaeli, Turkey, ademz@uekae.tubitak.gov.tr); Tuna Tugcu (Bogazici University, Istanbul, Turkey, tugcu@boun.edu.tr) ABSTRACT

More information

be used for more than one use case (for instance, for use cases Create User and Delete User, one can have one UserController, instead of two separate

be used for more than one use case (for instance, for use cases Create User and Delete User, one can have one UserController, instead of two separate UNIT 4 GRASP GRASP: Designing objects with responsibilities Creator Information expert Low Coupling Controller High Cohesion Designing for visibility - Applying GoF design patterns adapter, singleton,

More information

LECTURE NOTES ON DESIGN PATTERNS MCA III YEAR, V SEMESTER (JNTUA-R09)

LECTURE NOTES ON DESIGN PATTERNS MCA III YEAR, V SEMESTER (JNTUA-R09) LECTURE NOTES ON DESIGN PATTERNS MCA III YEAR, V SEMESTER (JNTUA-R09) Mr. B KRISHNA MURTHI M.TECH, MISTE. Assistant Professor DEPARTMENT OF MASTER OF COMPUTER APPLICATIONS CHADALAWADA RAMANAMMA ENGINEERING

More information

CSCI Object Oriented Design: Frameworks and Design Patterns George Blankenship. Frameworks and Design George Blankenship 1

CSCI Object Oriented Design: Frameworks and Design Patterns George Blankenship. Frameworks and Design George Blankenship 1 CSCI 6234 Object Oriented Design: Frameworks and Design Patterns George Blankenship Frameworks and Design George Blankenship 1 Background A class is a mechanisms for encapsulation, it embodies a certain

More information

Design Patterns. CSC207 Fall 2017

Design Patterns. CSC207 Fall 2017 Design Patterns CSC207 Fall 2017 Design Patterns A design pattern is a general description of the solution to a well-established problem using an arrangement of classes and objects. Patterns describe the

More information

Object-Oriented Design

Object-Oriented Design Object-Oriented Design Lecturer: Raman Ramsin Lecture 20: GoF Design Patterns Creational 1 Software Patterns Software Patterns support reuse of software architecture and design. Patterns capture the static

More information

2.1 Design Patterns and Architecture (continued)

2.1 Design Patterns and Architecture (continued) MBSE - 2.1 Design Patterns and Architecture 1 2.1 Design Patterns and Architecture (continued) 1. Introduction 2. Model Construction 2.1 Design Patterns and Architecture 2.2 State Machines 2.3 Timed Automata

More information

2.1 Design Patterns and Architecture (continued)

2.1 Design Patterns and Architecture (continued) MBSE - 2.1 Design Patterns and Architecture 1 2.1 Design Patterns and Architecture (continued) 1. Introduction 2. Model Construction 2.1 Design Patterns and Architecture 2.2 State Machines 2.3 Abstract

More information

COSC 3351 Software Design. Design Patterns Behavioral Patterns (I)

COSC 3351 Software Design. Design Patterns Behavioral Patterns (I) COSC 3351 Software Design Design Patterns Behavioral Patterns (I) Spring 2008 Purpose Creational Structural Behavioral Scope Class Factory Method Adapter(class) Interpreter Template Method Object Abstract

More information

Review Software Engineering October, 7, Adrian Iftene

Review Software Engineering October, 7, Adrian Iftene Review Software Engineering October, 7, 2013 Adrian Iftene adiftene@info.uaic.ro Software engineering Basics Definition Development models Development activities Requirement analysis Modeling (UML Diagrams)

More information

Summary of the course lectures

Summary of the course lectures Summary of the course lectures 1 Components and Interfaces Components: Compile-time: Packages, Classes, Methods, Run-time: Objects, Invocations, Interfaces: What the client needs to know: Syntactic and

More information

Design Patterns. GoF design patterns catalog

Design Patterns. GoF design patterns catalog Design Patterns GoF design patterns catalog OMT notations - classes OMT notation - relationships Inheritance - triangle Aggregation - diamond Acquaintance keeps a reference solid line with arrow Creates

More information

3 Product Management Anti-Patterns by Thomas Schranz

3 Product Management Anti-Patterns by Thomas Schranz 3 Product Management Anti-Patterns by Thomas Schranz News Read above article, it s good and short! October 30, 2014 2 / 3 News Read above article, it s good and short! Grading: Added explanation about

More information

Software Engineering I (02161)

Software Engineering I (02161) Software Engineering I (02161) Week 10 Assoc. Prof. Hubert Baumeister DTU Compute Technical University of Denmark Spring 2016 Last Time Project Planning Non-agile Agile Refactoring Contents Basic Principles

More information

Factory Method. Comp435 Object-Oriented Design. Factory Method. Factory Method. Factory Method. Factory Method. Computer Science PSU HBG.

Factory Method. Comp435 Object-Oriented Design. Factory Method. Factory Method. Factory Method. Factory Method. Computer Science PSU HBG. Comp435 Object-Oriented Design Week 11 Computer Science PSU HBG 1 Define an interface for creating an object Let subclasses decide which class to instantiate Defer instantiation to subclasses Avoid the

More information

Design Pattern and Software Architecture: IV. Design Pattern

Design Pattern and Software Architecture: IV. Design Pattern Design Pattern and Software Architecture: IV. Design Pattern AG Softwaretechnik Raum E 3.165 Tele.. 60-3321 hg@upb.de IV. Design Pattern IV.1 Introduction IV.2 Example: WYSIWYG Editor Lexi IV.3 Creational

More information

Lecture 17: Patterns Potpourri. Copyright W. Howden 1

Lecture 17: Patterns Potpourri. Copyright W. Howden 1 Lecture 17: Patterns Potpourri Copyright W. Howden 1 GOF Patterns GOF: Gamma, Helm, Johnson, Vlissides Design Patterns, Addison Wesley, 1995 Patterns we have seen so far Creational Patterns e.g. Factory,

More information

Produced by. Design Patterns. MSc in Communications Software. Eamonn de Leastar

Produced by. Design Patterns. MSc in Communications Software. Eamonn de Leastar Design Patterns MSc in Communications Software Produced by Eamonn de Leastar (edeleastar@wit.ie) Department of Computing, Maths & Physics Waterford Institute of Technology http://www.wit.ie http://elearning.wit.ie

More information

Topics. Software Process. Agile. Requirements. Basic Design. Modular Design. Design Patterns. Testing. Quality. Refactoring.

Topics. Software Process. Agile. Requirements. Basic Design. Modular Design. Design Patterns. Testing. Quality. Refactoring. CS310 - REVIEW Topics Process Agile Requirements Basic Design Modular Design Design Patterns Testing Quality Refactoring UI Design How these things relate Process describe benefits of using a software

More information