CSCD01 Engineering Large Software Systems. Design Patterns. Joe Bettridge. Winter With thanks to Anya Tafliovich
|
|
- Silvester Pierce
- 5 years ago
- Views:
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 2018 With thanks to Anya Tafliovich Design Patterns Design patterns take the problems consistently found in software, and
More informationCSCD01 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 informationDesign 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 informationSDC 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 informationProduced 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 informationEPL 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 informationThe 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 informationObject-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 informationTopics 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 informationDesign 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 informationIngegneria 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 informationObject-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 informationUsing 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 informationModellistica 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 informationDesign 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 informationDesign 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 informationDesign 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 informationBrief 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 informationDesign 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 informationObject 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 informationDesign 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 informationSlide 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 informationSoftware 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 informationFacade 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 informationDESIGN 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 informationDesign 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 informationSocket 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 informationSoftware 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 informationDesign 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 informationTuesday, 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 informationIntroduction 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 informationTHOMAS 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 informationDesign 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 informationThink 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 informationWhat 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 informationApplying 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 informationAn 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 informationDesign 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 informationObject-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 informationComposite 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 informationDesign 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 informationSOFTWARE 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 informationKeywords: 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 informationGoals 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 information1 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 informationObject 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 informationDesign 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 informationApplication 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 informationApplying 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 informationThe 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 informationDesign 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 informationInformation 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 informationSoftware 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 informationLast 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 informationLecture 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 informationA 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 informationSecond 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 informationApplying 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 informationSoftware 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 informationDesign 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 informationIdioms 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 informationDesign 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 informationDesign 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 informationApplying 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 informationThe 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 informationadministrivia 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 informationDesign 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 informationIngegneria 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 informationLast 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 informationModellistica 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 informationDesign 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 informationDesign 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 informationDESIGN 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 informationLectures 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 information6.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 informationWhat 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 informationSOLID 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 informationAn 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 informationDesign 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 informationTrusted 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 informationDesign 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 informationAPPLYING 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 informationbe 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 informationLECTURE 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 informationCSCI 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 informationDesign 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 informationObject-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 information2.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 information2.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 informationCOSC 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 informationReview 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 informationSummary 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 informationDesign 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 information3 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 informationSoftware 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 informationFactory 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 informationDesign 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 informationLecture 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 informationProduced 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 informationTopics. 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