MSO Lecture 6. Wouter Swierstra. September 24, 2015
|
|
- Silvester Higgins
- 6 years ago
- Views:
Transcription
1 1 MSO Lecture 6 Wouter Swierstra September 24, 2015
2 2 LAST LECTURE Case study: CAD/CAM system What are design patterns? Why are they important? What are the Facade and Adapter patterns?
3 3 THIS LECTURE What is the strategy patten? What is the bridge pattern?
4 4 DESIGN IN AN AGILE SETTING Agile programming emphasises not too invest too much time in Big Design Up Front. Does that mean that design patterns are no longer relevant? Shalloway and Trott argue that by learning design patterns you will learn the qualities of good code and good design.
5 5 AGILE VS DESIGN PATTERNS Agile practices focus on: No redundancy; Readability; Testability. But Design Patterns value the same principles!
6 6 NO REDUNDANCY Never duplicate code. Copy-paste is a sin. Why? This leads to strange coupling behaviour and unmaintainable code. Instead: encapsulate behind a well defined interface. Applying design patterns can encourage code reuse.
7 7 READABILITY Choose the names of objects and methods to reveal their intent. Whenever you feel the need to comment something, write a method instead. (Martin Fowler) Aim for short, cohesive methods in line with design pattern philosophy.
8 8 TESTABILITY You may not have experienced this first hand, but some code is very hard to test. In particular, code that is tightly coupled or weakly cohesive is harder to test. You need to do a lot of work to set up your tests it may even be impossible (tightly coupled); Your tests may not measure the right thing (weakly cohesive). Decoupling these issues and writing cohesive classes and methods makes testing easier: exactly what is advocated by our three design principles and design patterns in general.
9 9 INCREMENTAL DELIVERY Agile focuses on delivering new product increments in every iteration. But some features are too big to implement in a single iteration. Instead, you may want to lay the groundwork and implement a partial solution first. And extend this later. But how can you design a partial solution that is easy to extend?
10 10 IN SUMMARY... Although the design pattern philosophy may seem at odds with Agile/XP practices they share the same ideas about what makes great code.
11 11 EXAMPLE: VIDEO RENTAL STORE Customer statement() 1 * Rental daysrented:int * 1 Movie pricecode : int title : string
12 12 INITIAL CLASSES The Movie class defines three price codes as integer constants: CHILDREN = 0 STANDARD = 1 NEW = 2 The Rental class tracks the number of days a particular movie has been rented. Finally, the Customer class records a list Rentals.
13 13 GETTING RID OF SWITCHES switch (v.getmovie().getpricecode()) { case Movie.STANDARD : v_price = 3 euro * v.daysrented; break case Movie.NEW : v_price = 5 euro * v.daysrented; break case Movie.CHILDREN : v_price = 2 euro * v.daysrented }
14 How can we get rid of this switch statement? 14
15 Use inheritance! 15
16 16 Movie calculaterate(int days) ChildensMovie StandardMovie NewMovie Question: What do you think of this design? Does it solve the original problem? What kind of change might be hard to handle?
17 17 BUT THEN... The video store owner calls.
18 18 BUT THEN... The video store owner calls. The Hunger Games is not so new anymore.
19 19 BUT THEN... The video store owner calls. The Hunger Games is not so new anymore. Can you change it from a New movie to a Standard movie?
20 20 Requirements always change.
21 21 THE VIDEO PROBLEM How can we solve the video rental problem? We could write a hack conversion from New movies to Standard movies but this would break abstraction. Can we do better?
22 22 WHY DESIGN? If requirements always change, what good are design patterns? Or any upfront design? Isn t quick-and-dirty programming just as effective?
23 23 AN ANALOGY Every time I print a document, it is easier for me to put it on my desk, than file it away. This works fine if I only ever have ten documents to manage. But if I need to handle more documents, I need to invest in maintaining some kind of system. Lesson: Cutting corners in the short term, may have a price to pay in the long term.
24 24 EXCUSES, EXCUSES... We don t know what requirements are going to change. If we try to see how things will change, we ll stay in analysis... If we try to write our software that is extensible, we ll stay in design forever. We don t have the money. We don t have the time. I ll get to it later...
25 25 PICK YOUR POISON It would seem that there are only two choices: Overdesign. Quick and dirty.
26 26 A THIRD WAY You don t need to fix the design upfront but you do need to think about where the changes are most likely to happen. If you think about this beforehand, the investment to write adaptable code is much lower than having to refactor a large code base post hoc.
27 27 SOME PRINCIPLES OF GOOD DESIGN Program to an interface, not an implementation. Favor aggregation over inheritance. Encapsulate the concept that varies. Applying these can help write code that is robust to change.
28 28 CASE STUDY: E-COMMERCE Suppose I need to write software for an online retailer (Amazon, Bol,... ). I know that different countries have different address formats, tax rules, or shipping costs. Even if I do not yet know which countries I will ship to, or how these issues will be implemented exactly, I do know where to expect variation.
29 29 GENERAL ARCHITECTURE Introduce a controller object that processes sales requests. It delegates the handling of sales to a SalesOrder class: Allows for filling out the order with a GUI; Handles tax calculation; Processes the order; Prints a receipt. (Possibly with the help of other classes.)
30 30 HANDLING NEW CASES How can I handle new taxation rules? There are a few alternatives you may already be familiar with: Copy-and-paste; Switches or ifs; Function pointers; Inheritance. But these techniques all have drawbacks...
31 31 COPY-AND-PASTE Need new rules for calculating tax? Copy-and-paste the old rules and update them where necessary. Golden rule: Never, ever copy-and-paste code. You end up with two versions of the same code, which leads to maintenance nightmares.
32 32 CONDITIONALS public int computetax(mynation) switch(mynation) { case "NL": return price * 1.21; break; case "UK": // Insert code here break; } This works fine how extensible is it?
33 public int computeshipping(mynation) switch(mynation) { case "NL": // Insert code here break; case "UK": // Insert code here break; } 33
34 public int convertcurrency(mynation) switch(mynation) { case "NL": // Insert code here break; case "UK": // Insert code here break; } 34
35 35 HANDLING CHANGE What happens if I want to start shipping to Germany? Suddenly, I need to change lots of pieces of code, spread over different files. What happens if I need to ship to both French-speaking and Dutch-speaking parts of Belgium? Even more complex cases...
36 36 FUNCTION POINTERS AND DELEGATES CS students who have already done the Functional Programming course may wonder why you don t pass a function as argument, describing how to compute the tax. Now all you need to do is pass a different function as argument to the sales processing. This is essentially the same idea as the Strategy pattern.
37 37 INHERITANCE SalesOrder calculatetax() NLOrder UKOrder
38 38 INHERITANCE: A CRITICAL EVALUATION Introducing this class hierarchy enables us to vary the tax calculation in every subclass. But what about handling other variations: Different languages (like in Belgium); Different date formats; Different shipping costs; Different address formats;... How can I share code between subclasses? Many modification may require us to revisit the entire hierarchy.
39 39 A BETTER APPROACH Find what varies and encapsulate it in a class of its own. 2. Contain this class in the original class.
40 40 MORE CONCRETELY 1. The tax calculation across different countries is different. We need to introduce a separate class, CalcTax. 2. Every SalesOrder should have a CalcTax.
41 41 SalesOrder CalcTax calculatetax(price : double) NLTax UKTax
42 42 ANOTHER EXAMPLE 1. Different kinds of movies have different rental rates. We need to introduce a separate class, RateCalculator. 2. Every Rental should have a RateCalculator.
43 43 Rental RateCalculator calculaterate(daysrented : int) NewMovie ChildrensMovie StandardMovie
44 44 OR IN CODE public class Rental { private ratecalculator RateCalculator;... }
45 abstract class RateCalculator { public abstract int calculaterate(days int) } 45
46 46 class NewMovieRateCalculator : RateCalculator { public override int calculaterate(days int) { // New movies cost 5 euros per day to rent return 5 * daysrented; } } And similar implementations for other price classes.
47 47 WHY IS THIS BETTER THAN INHERITANCE? Cohesion is stronger There is one place where all rate calculation happens. Easier to shift responsibility. Users of the SalesOrder or Movie class do not need to decide how to compute taxes or rental prices this would be the case if we used inheritance. We can change the behaviour of an object by assigning it a new RateCalculator. For example, when a New movie is no longer New.
48 48 IS INHERITANCE BAD? This solution still uses inheritance (NewMovieCalculator is a subclass of RateCalculator). But it uses it very carefully, to capture a single kind of variation.
49 49 THE STRATEGY PATTERN Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from the clients that use it. The Gang of Four, describing the Strategy pattern s intent.
50 STRATEGY PATTERN Intent: Use different business rules or algorithms depending on the context. Problem: The selection of a computation that needs to be performed depends on the client making the request or the data being acted on. Solution: Separate the selection of algorithm from the implementation of the algorithm. Allows for the selection to be made in context. Participants: The Strategy class specifies the different algorithms; ConcreteStrategy implements such an algorithm; Context uses a specific ConcreteStrategy. Consequences: Defines a family of algorithms; Switches/conditionals can be eliminated; You invoke all algorithms in the same way. 50
51 51 STRATEGY: IMPLEMENTATION Client Context Strategy computation(...) ConcreteStrategyA computation(..) ConcreteStrategyB computation(..) ConcreteStrategyC computation(..)
52 52 NOTES ON USING THE STRATEGY PATTERN The computation in the ConcreteStrategy classes may need extra information. It is the responsibility of the Context to gather the required information and pass it to the computations. Applying the Strategy class makes it easier to test code. You can write unit tests for individual ConcreteStrategy objects, without having to worry about the rest of the context.
53 53 THE BRIDGE PATTERN Intent: Decouple an abstraction from its implementation so the two can vary independently.
54 54 THE BRIDGE PATTERN Intent: Decouple an abstraction from its implementation so the two can vary independently. Huh?
55 55 THE BRIDGE PATTERN The Bridge pattern is one of the most complicated patterns we ll see but once you understand the principles of object oriented design, it should make sense. So remember: Favour aggregation over inheritance; Find what varies and encapsulate it;
56 56 TOWARDS THE BRIDGE PATTERN Case study: Suppose I have to write a game that works on different platforms. Both these platforms have a similar graphics library, but there are subtle differences in the interface. How do I encapsulate the variation?
57 57 USE INHERITANCE! Mario +draw() ios Mario + draw() Android Mario + draw() ios Graphics + drawpixel(x,y) + setcolor(c) Android Graphics + setpixel(x,y,c) Question: Where might there be duplicate code? What happens when I need to ship to another platform?
58 58 CODE DUPLICATION The two draw methods are probably very similar. Duplicate code is a Very Bad Thing. Can we avoid this duplication?
59 59 INHERITANCE AND OVERLOADING Mario # setpixel(x,y,c) + draw() ios Mario #setpixel(x,y,c) Android Mario #setpixel(x,y,c) ios Graphics + drawpixel(x,y) + setcolor(c) Android Graphics + setpixel(x,y,c)
60 60 BUT THEN... Of course, the requirements will change. Suppose we need to draw both Mario and Luigi with both drawing programs... Introduce an abstract class Plumber; Introduce abstract subclasses, Mario and Luigi, of the Plumber class; Introduce two concrete implementations for both drawing programs for both the Mario and the Luigi class.
61 61 Plumber +draw() Mario +draw() #setpixel(x,y,c) Luigi +draw() #setpixel(x,y,c) ios Mario #setpixel(x,y,c) Android Mario #setpixel(x,y,c) ios Luigi #setpixel(x,y,c) Android Luigi #setpixel(x,y,c) ios Graphics Android Graphics
62 62 EVALUATING THIS DESIGN This solves our original problem but: introducing a new Plumber requires the definition of three new classes (one abstract and one implementation for each drawing program). introducing a new Graphics platform requires a new subclass for every Plumber. the abstraction (the different kinds of Plumbers) and their implementation (the different kinds of Graphics classes) are tightly coupled. there is redundancy the different concrete Luigi or Mario classes may share a lot of code.
63 63 CAN WE DO BETTER? So maybe this was not the right design choice. Perhaps we should introduce two abstract Plumber classes, one for each platform program...
64 64 Plumber +draw() Android Plumbers #setpixel(x,y,c) ios Plumbers #setpixel(x,y,c) AndroidMario +draw() AndroidLuigi +draw() ios Mario +draw() ios Luigi +draw() Android Graphics ios Graphics Question: Problem solved?
65 65 EVALUATING THIS DESIGN This design does split things up differently, but it still suffers from many of the same disadvantages as our previous approach: duplicate code in the Android Mario and ios Mario classes (and also for Luigi of course); introducing new platforms requires a new abstract class, together with a new concrete implementation for each different Plumber; introducing a new Plumber requires a new concrete implementation for each different Graphics platform. the implementations and abstractions are still too tightly coupled.
66 66 THE BRIDGE PATTERN Intent: Decouple an abstraction from its implementation so the two can vary independently. Here we have precisely this situation: we have different Plumbers (abstractions) that we want to draw with different Graphics platforms (implementations). How can we decouple the abstractions and implementations?
67 67 THE BRIDGE PATTERN Let s try to derive the Bridge pattern ourselves, by simply applying some of the principles of good object oriented design: Find what varies and encapsulate it; Favour aggregation over inheritance; Program to an interface, not an implementation.
68 68 COMMONALITY-VARIABILITY ANALYSIS We want to support different kinds of plumbers and different kinds of Graphics platforms: We want to be able to draw a Plumber (although Mario and Luigi get drawn differently); Our drawing programs support the drawing of individual pixels (even if they do so differently).
69 69 STARTING THE DESIGN... Plumber +draw() Graphics +setpixel(x,y,c) This tries to capture the commonality between the different Plumbers and the different Graphics platforms.
70 70 INTRODUCING VARIATION. Next we want to introduce some variation: We have two different kinds of Plumber; We have two different kinds of Graphics; Let s try adding some subclasses...
71 71 INTRODUCING VARIATION Plumber +draw() Graphics +setpixel(x,y,c) Mario +draw() Luigi +draw() Android Graphics +setpixel(x,y,c) ios Graphics +setpixel(x,y,c) Find what varies and encapsulate it.
72 72 HOW ARE THE TWO RELATED? Favour aggregation over inheritance let s not try to introduce any further subtypes for the moment. Should Graphics use a Plumber object? Probably not. Then the Graphics would need to inspect what kind of Plumber they have to figure out how to draw them. Should Plumber use Graphics? Why not? Then a Plumber does not need to know what kind of Graphics it is using. We are free to use different drawing programs, because the Plumber class programs to an interface, not an implementation.
73 73 THE BRIDGE PATTERN Plumber +draw() Graphics +setpixel(x,y,c) Mario +draw() Luigi +draw() Android Graphics +setpixel(x,y,c) ios Graphics +setpixel(x,y,c) ios Engine +drawpixel(x,y) +setcolor(c)
74 74 EVALUATING THE BRIDGE How well does this separate implementations (Graphics) from the abstractions (Plumbers)?
75 75 Plumbers (abstractions) Plumber +draw() Graphics (implementations) Graphics +setpixel(x,y,c) Mario +draw() Luigi +draw() Android Graphics +setpixel(x,y,c) ios Graphics +setpixel(x,y,c) ios Engine +drawpixel(x,y) +setcolor(c)
76 Did you spot the Adapter pattern? 76
77 77 Plumbers (abstractions) Plumber +draw() Graphics (implementations) Graphics +setpixel(x,y,c) Mario +draw() Luigi +draw() Android Graphics +setpixel(x,y,c) ios Graphics +setpixel(x,y,c) ios Engine +drawpixel(x,y) +setcolor(c)
78 78 THE BRIDGE PATTERN Intent: Decouple a set of implementations from the objects using them. Problem: The derivations of an abstract class must use multiple implementations, without causing an explosion in the number of classes; Solution: Define an interface for all implementations to use and have the derivations of the abstract class use that. Consequences: The decoupling of the implementations from the objects that use them increases extensibility. Client objects are not aware of implementation issues.
79 79 BRIDGE PATTERN: IMPLEMENTATION Abstraction +operation() Implementation +operationimpl() RefinedAbstraction +operation() ConcreteImpl1 +operationimpl() ConcreteImpl2 +operationimpl()
80 80 ONE RULE, ONE PLACE Design principle: If you have a rule for how to do something, only implement it once. Why? Maintainability: if the rule changes, there is only piece of code to update; Cohesion: the responsibility for this computation is in a single place;
81 81 DRAWBACKS OF THE BRIDGE PATTERN What happens if I want to add a new Plumber? If I can draw it using the setpixel method, all we need to do is define a new concrete subclass of the Plumber class.... but if I can t, I will need to change the interface that the abstract Graphics class defines, together with all its concrete implementations. Implementing the Bridge pattern solves one problem, but may introduce new problems or weaknesses in your design.
82 82 MATERIAL COVERED Design Patterns explained. Chapter 9 10.
MSO Lecture 6. Wouter Swierstra (adapted by HP) September 28, 2017
1 MSO Lecture 6 Wouter Swierstra (adapted by HP) September 28, 2017 2 LAST LECTURE Case study: CAD/CAM system What are design patterns? Why are they important? What are the Facade and Adapter patterns?
More informationMSO Refactoring. Hans Philippi. October 2, Refactoring 1 / 49
MSO Refactoring Hans Philippi October 2, 2018 Refactoring 1 / 49 This lecture What is refactoring?... or how to deal with the horrible code your colleagues have created... or how to deal with the horrible
More informationMSO Lecture 12. Wouter Swierstra (adapted by HP) October 26, 2017
1 MSO Lecture 12 Wouter Swierstra (adapted by HP) October 26, 2017 2 LAST LECTURE Analysis matrix; Decorator pattern; Model-View-Controller; Observer pattern. 3 THIS LECTURE How to create objects 4 CATEGORIES
More informationRDD and Strategy Pa.ern
RDD and Strategy Pa.ern CSCI 3132 Summer 2011 1 OO So1ware Design The tradi7onal view of objects is that they are data with methods. Smart Data. But, it is be.er to think of them as en##es that have responsibili#es.
More informationMSO Object Creation Singleton & Object Pool
MSO Object Creation Singleton & Object Pool Wouter Swierstra & Hans Philippi October 25, 2018 Object Creation: Singleton & Object Pool 1 / 37 This lecture How to create objects The Singleton Pattern The
More informationExpanding Our Horizons. CSCI 4448/5448: Object-Oriented Analysis & Design Lecture 9 09/25/2011
Expanding Our Horizons CSCI 4448/5448: Object-Oriented Analysis & Design Lecture 9 09/25/2011 1 Goals of the Lecture Cover the material in Chapter 8 of our textbook New perspective on objects and encapsulation
More informationAgile Architecture. The Why, the What and the How
Agile Architecture The Why, the What and the How Copyright Net Objectives, Inc. All Rights Reserved 2 Product Portfolio Management Product Management Lean for Executives SAFe for Executives Scaled Agile
More informationIndex Shalloway rev.qrk 9/21/04 5:54 PM Page 419. Index
Index Shalloway rev.qrk 9/21/04 5:54 PM Page 419 Index A Abandon (by) ship (date)!, 140 Abstract class type, 21 Abstract classes, 19, 22, 29 and common and variability analysis, 127 130 interfaces vs.,
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 informationObject-Oriented Concepts and Design Principles
Object-Oriented Concepts and Design Principles Signature Specifying an object operation or method involves declaring its name, the objects it takes as parameters and its return value. Known as an operation
More informationAntiPatterns. EEC 421/521: Software Engineering. AntiPatterns: Structure. AntiPatterns: Motivation
AntiPatterns EEC 421/521: Software Engineering Definition: An AntiPattern describes a commonly occurring solution to a problem that generates decidedly negative consequences Refactoring Reference: Refactoring
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 informationMSO Lecture 11. Wouter Swierstra. October 15, 2015
1 MSO Lecture 11 Wouter Swierstra October 15, 2015 2 REVIEW Object oriented analysis: RUP; requirements; use cases; domain models; GRASP principles; Design patterns: Facade Bridge Strategy Abstract Factory...
More informationRefactoring, Part 2. Kenneth M. Anderson University of Colorado, Boulder CSCI 4448/5448 Lecture 27 12/01/09. University of Colorado, 2009
Refactoring, Part 2 Kenneth M. Anderson University of Colorado, Boulder CSCI 4448/5448 Lecture 27 12/01/09 University of Colorado, 2009 1 Introduction Credit where Credit is Due Some of the material for
More informationMSO Lecture 11. Wouter Swierstra (adapted by HP) October 23, 2017
1 MSO Lecture 11 Wouter Swierstra (adapted by HP) October 23, 2017 2 REVIEW Object oriented analysis: UP requirements use cases domain models GRASP principles Design patterns: Facade Adapter Bridge Strategy
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 informationMSO Lecture 9. Wouter Swierstra (adapted by HP, AL) October 12, 2017
1 MSO Lecture 9 Wouter Swierstra (adapted by HP, AL) October 12, 2017 2 BEFORE WE START... Some notes on Kahoot! nicknames: Normaal: Anneke, Bastiaan, Pieter, Sjaak, Ruud,... Funny: Jeroen Fokker, Sergey
More informationRefactoring. Software Engineering, DVGC18 Faculty of Economic Sciences, Communication and IT Eivind Nordby
Refactoring Faculty of Economic Sciences, Communication and IT 2011-09-21 Why Refactor Refactoring is one factor in keeping your system in shape Without continuous refactoring, the system will rot It takes
More informationMSO Lecture 1. Wouter Swierstra (adapted by HP) September 11, 2017
1 MSO Lecture 1 Wouter Swierstra (adapted by HP) September 11, 2017 So you think you can program... 2 From nrc.nl 3 Question: why do ICT-projects fail so often? 4 5 Question: why do ICT-projects fail so
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: State, Bridge, Visitor
Design Patterns: State, Bridge, Visitor State We ve been talking about bad uses of case statements in programs. What is one example? Another way in which case statements are sometimes used is to implement
More informationOODP Session 4. Web Page: Visiting Hours: Tuesday 17:00 to 19:00
OODP Session 4 Session times PT group 1 Monday 18:00 21:00 room: Malet 403 PT group 2 Thursday 18:00 21:00 room: Malet 407 FT Tuesday 13:30 17:00 room: Malet 404 Email: oded@dcs.bbk.ac.uk Web Page: http://www.dcs.bbk.ac.uk/~oded
More informationCompositional Design Principles
Chapter 16 Compositional Design Principles Learning Objectives In this chapter, I will more formally introduce the three principles that form the 3-1- 2 process. The learning focus is understanding how
More informationExample of OO Design Refactoring
Example of OO Design Refactoring Robert B. France Colorado State University Fort Collins Colorado Robert B. France 1 What is design refactoring? Often an initial design is not a good design Design may
More information20 Years of. Improve the Design of your Code. Dr Dimitris Dranidis JAVA Meetup Group, Thessaloniki May 2015
20 Years of Design Patterns Improve the Design of your Code Dr Dimitris Dranidis JAVA Meetup Group, Thessaloniki May 2015 Dr Dimitris Dranidis Senior Lecturer in Computer Science Department Programme director
More informationChapter01.fm Page 1 Monday, August 23, :52 PM. Part I of Change. The Mechanics. of Change
Chapter01.fm Page 1 Monday, August 23, 2004 1:52 PM Part I The Mechanics of Change The Mechanics of Change Chapter01.fm Page 2 Monday, August 23, 2004 1:52 PM Chapter01.fm Page 3 Monday, August 23, 2004
More informationCS342: Software Design. November 21, 2017
CS342: Software Design November 21, 2017 Runnable interface: create threading object Thread is a flow of control within a program Thread vs. process All execution in Java is associated with a Thread object.
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 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 informationDeriving Strategy Pattern.... derived from the principles
Deriving Strategy Pattern... derived from the principles Customer Alphatown county: The pay station must: Last Alphatown county accept coins for payment show time bought print parking time receipts US:
More informationExam Questions. Object-Oriented Design, IV1350. Maximum exam score is 100, grade limits are as follows. Score Grade 90 A 80 B 70 C 60 D 50 E
Object-Oriented Design, IV1350 Maximum exam score is 100, grade limits are as follows. Score Grade 90 A 80 B 70 C 60 D 50 E The exam questions will be a subset of the questions below. The exam may contain
More information17 Multiple Inheritance and ADT Extensions
Object-Oriented Design Lecture 17 CS 3500 Spring 2010 (Pucella) Friday, Mar 19, 2010 17 Multiple Inheritance and ADT Extensions We looked last time at inheritance and delegation as two ways to reuse implementation
More informationCS 370 The Pseudocode Programming Process D R. M I C H A E L J. R E A L E F A L L
CS 370 The Pseudocode Programming Process D R. M I C H A E L J. R E A L E F A L L 2 0 1 5 Introduction At this point, you are ready to beginning programming at a lower level How do you actually write your
More informationUnderstading Refactorings
Understading Refactorings Ricardo Terra terra@dcc.ufmg.br Marco Túlio Valente mtov@dcc.ufmg.br UFMG, 2010 UFMG, 2010 Understanding Refactorings 1 / 36 Agenda 1 Overview 2 Refactoring 3 Final Considerations
More information16 Multiple Inheritance and Extending ADTs
Object-Oriented Design Lecture 16 CS 3500 Fall 2009 (Pucella) Tuesday, Nov 10, 2009 16 Multiple Inheritance and Extending ADTs We looked last time at inheritance and delegation as two ways to reuse implementation
More informationImplementing GUI context-sensitive help... ECE450 Software Engineering II. Implementing GUI context-sensitive help... Context-sensitive help
Implementing GUI context-sensitive help... ECE450 Software Engineering II Today: Design Patterns VIII Chain of Responsibility, Strategy, State ECE450 - Software Engineering II 1 ECE450 - Software Engineering
More informationA few important patterns and their connections
A few important patterns and their connections Perdita Stevens School of Informatics University of Edinburgh Plan Singleton Factory method Facade and how they are connected. You should understand how to
More informationPlan. A few important patterns and their connections. Singleton. Singleton: class diagram. Singleton Factory method Facade
Plan A few important patterns and their connections Perdita Stevens School of Informatics University of Edinburgh Singleton Factory method Facade and how they are connected. You should understand how to
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 informationTest Driven Development (TDD)
Test Driven Development (TDD) Test Driven Development Introduction Good programmers write code, great programmers write tests Never, in the field of programming, have so many owed so much to so few - Martin
More informationCOURSE 2 DESIGN PATTERNS
COURSE 2 DESIGN PATTERNS CONTENT Fundamental principles of OOP Encapsulation Inheritance Abstractisation Polymorphism [Exception Handling] Fundamental Patterns Inheritance Delegation Interface Abstract
More informationSoftware Engineering
Software Engineering CSC 331/631 - Spring 2018 Object-Oriented Design Principles Paul Pauca April 10 Design Principles DP1. Identify aspects of the application that vary and separate them from what stays
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 informationBridge Pattern. Used to decouple an abstraction from its implementation so that the two can vary independently
Bridge Pattern Used to decouple an abstraction from its implementation so that the two can vary independently What that means Abstraction and implementation are not related in the sense that the implementation
More informationTest-Driven Development (TDD)
Test-Driven Development (TDD) CS 4501 / 6501 Software Testing [Lasse Koskela, Test Driven, Chapters 2-3] 1 Agile Airplane Testing Test harness: Appearance matches Color coding in place Fly 6ft (or 2m)
More information/633 Introduction to Algorithms Lecturer: Michael Dinitz Topic: Sorting lower bound and Linear-time sorting Date: 9/19/17
601.433/633 Introduction to Algorithms Lecturer: Michael Dinitz Topic: Sorting lower bound and Linear-time sorting Date: 9/19/17 5.1 Introduction You should all know a few ways of sorting in O(n log n)
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 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 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 informationCSE 70 Final Exam Fall 2009
Signature cs70f Name Student ID CSE 70 Final Exam Fall 2009 Page 1 (10 points) Page 2 (16 points) Page 3 (22 points) Page 4 (13 points) Page 5 (15 points) Page 6 (20 points) Page 7 (9 points) Page 8 (15
More informationEssential Skills for the Agile Developer. Agile. copyright Net Objectives, Inc.
Essential Skills for the Agile Developer Agile copyright 2010. Net Objectives, Inc. Lean for Executives Product Portfolio Management Business Lean Enterprise ASSESSMENTS CONSULTING TRAINING COACHING Team
More informationThe State Pattern. State Design Pattern: Motivation
The State Pattern The State Pattern allows an object to alter its behavior when its internal state changes. The object will appear to change its class. Toni Sellarès Universitat de Girona State Design
More informationWelcome to Design Patterns! For syllabus, course specifics, assignments, etc., please see Canvas
Welcome to Design Patterns! For syllabus, course specifics, assignments, etc., please see Canvas What is this class about? While this class is called Design Patterns, there are many other items of critical
More informationProgramming in C++ Prof. Partha Pratim Das Department of Computer Science and Engineering Indian Institute of Technology, Kharagpur
Programming in C++ Prof. Partha Pratim Das Department of Computer Science and Engineering Indian Institute of Technology, Kharagpur Lecture - 43 Dynamic Binding (Polymorphism): Part III Welcome to Module
More informationObject Oriented Design and Programming Revision
M.Sc Computer Science Object Oriented Design and Programming Revision Oded Lachish Email: oded@dcs.bbk.ac.uk Web Page: http://www.dcs.bbk.ac.uk/~oded/oodp12/oodp2012.html Question 1 (a) What is the motivation
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 informationIntro. Scheme Basics. scm> 5 5. scm>
Intro Let s take some time to talk about LISP. It stands for LISt Processing a way of coding using only lists! It sounds pretty radical, and it is. There are lots of cool things to know about LISP; if
More informationOOP Design Conclusions and Variations
CS108, Stanford Handout #20 Fall, 2008-09 Osvaldo Jiménez OOP Design Conclusions and Variations Thanks to Nick Parlante for much of this handout Part 1 -- Mainstream OOP Design First, we have the standard,
More informationObject-Oriented Design
Object-Oriented Design Lecture 14: Design Workflow Department of Computer Engineering Sharif University of Technology 1 UP iterations and workflow Workflows Requirements Analysis Phases Inception Elaboration
More informationVOL. 4, NO. 12, December 2014 ISSN ARPN Journal of Science and Technology All rights reserved.
Simplifying the Abstract Factory and Factory Design Patterns 1 Egbenimi Beredugo Eskca, 2 Sandeep Bondugula, 3 El Taeib Tarik 1, 2, 3 Department of Computer Science, University of Bridgeport, Bridgeport
More informationIntroduction to Refactoring
Introduction to Refactoring Sutee Sudprasert 1 Credits Refactoring : Improving the design of existing code - Martin Fowler Design Patterns - GOF 2 What is refactoring? Refactoring is the process of changing
More informationMSO Lecture Design by Contract"
1 MSO Lecture Design by Contract" Wouter Swierstra (adapted by HP, AL) October 8, 2018 2 MSO SO FAR Recap Abstract Classes UP & Requirements Analysis & UML OO & GRASP principles Design Patterns (Facade,
More informationCPS122 Lecture: Cohesion and Coupling. 1. To introduce cohesion and coupling as criteria for evaluating designs
CPS122 Lecture: Cohesion and Coupling Objectives: Last revised March 27, 2015 1. To introduce cohesion and coupling as criteria for evaluating designs Materials: 1. Cohesion/coupling worksheet + projectable
More informationType Checking in COOL (II) Lecture 10
Type Checking in COOL (II) Lecture 10 1 Lecture Outline Type systems and their expressiveness Type checking with SELF_TYPE in COOL Error recovery in semantic analysis 2 Expressiveness of Static Type Systems
More informationLast Time: Object Design. Comp435 Object-Oriented Design. Last Time: Responsibilities. Last Time: Creator. Last Time: The 9 GRASP Patterns
Last Time: Object Design Comp435 Object-Oriented Design Week 7 Computer Science PSU HBG The main idea RDD: Responsibility-Driven Design Identify responsibilities Assign them to classes and objects Responsibilities
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 informationSoftware Design and Analysis for Engineers
Software Design and Analysis for Engineers by Dr. Lesley Shannon Email: lshannon@ensc.sfu.ca Course Website: http://www.ensc.sfu.ca/~lshannon/courses/ensc251 Simon Fraser University Slide Set: 2 Date:
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 informationTechnical Metrics for OO Systems
Technical Metrics for OO Systems 1 Last time: Metrics Non-technical: about process Technical: about product Size, complexity (cyclomatic, function points) How to use metrics Prioritize work Measure programmer
More informationEvolving Software. CMSC 433 Programming Language Technologies and Paradigms Spring Example. Some Motivations for This Refactoring
CMSC 433 Programming Language Technologies and Paradigms Spring 2007 Refactoring April 24, 2007 Lots of material taken from Fowler, Refactoring: Improving the Design of Existing Code 1 Evolving Software
More informationBack to ObjectLand. Contents at: Chapter 5. Questions of Interest. encapsulation. polymorphism. inheritance overriding inheritance super
korienekch05.qxd 11/12/01 4:06 PM Page 105 5 Back to ObjectLand Contents at: Chapter 5 #( encapsulation polymorphism inheritance overriding inheritance super learning the class hierarchy finding classes
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 informationvoid printowing(double amount) { printbanner(); printdetails(); void printdetails(double amount) {
Refactoring References: Martin Fowler, Refactoring: Improving the Design of Existing Code; ; Bruce Wampler, The Essence of Object-Oriented Oriented Programming with Java and UML A recent OO technique that
More informationThe Factory Pattern. Ballplayer joe = new Ballplayer("Dimaggio","OF");
Chapter 10 The Factory Pattern Now that we ve covered inheritance, we re in a position to understand the next simple-yet-ubiquitous design pattern, called Factory. It s a pretty easy one to grasp. Simply
More informationInheritance. Inheritance Reserved word protected Reserved word super Overriding methods Class Hierarchies Reading for this lecture: L&L
Inheritance Inheritance Reserved word protected Reserved word super Overriding methods Class Hierarchies Reading for this lecture: L&L 9.1 9.4 1 Inheritance Inheritance allows a software developer to derive
More informationCS-XXX: Graduate Programming Languages. Lecture 22 Class-Based Object-Oriented Programming. Dan Grossman 2012
CS-XXX: Graduate Programming Languages Lecture 22 Class-Based Object-Oriented Programming Dan Grossman 2012 PL Issues for OOP? OOP lets you: 1. Build some extensible software concisely 2. Exploit an intuitive
More informationLecture Transcript While and Do While Statements in C++
Lecture Transcript While and Do While Statements in C++ Hello and welcome back. In this lecture we are going to look at the while and do...while iteration statements in C++. Here is a quick recap of some
More informationAdministrivia. Programming Language Fall Example. Evolving Software. Project 3 coming out Midterm October 28. Refactoring October 14, 2004
CMSC 433 Programming Language Fall 2004 Project 3 coming out Midterm October 28 Administrivia Refactoring October 14, 2004 Lots of material taken from Fowler, Refactoring: Improving the Design of Existing
More informationOn the Web sun.com/aboutsun/comm_invest STAROFFICE 8 DRAW
STAROFFICE 8 DRAW Graphics They say a picture is worth a thousand words. Pictures are often used along with our words for good reason. They help communicate our thoughts. They give extra information that
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 informationGRASP Design Patterns A.A. 2018/2019
GRASP Design Patterns A.A. 2018/2019 Objectives Introducing design patterns Introduzione ai design pattern Designing objects and responsibilities GRASP design patterns A long corridor A passage room Does
More informationLesson 10A OOP Fundamentals. By John B. Owen All rights reserved 2011, revised 2014
Lesson 10A OOP Fundamentals By John B. Owen All rights reserved 2011, revised 2014 Table of Contents Objectives Definition Pointers vs containers Object vs primitives Constructors Methods Object class
More informationExtreme programming XP 6
Extreme programming XP 6 Planning Game 3 Planning Game Independent: Stories should be as independent as possible. When thinking of independence it is often easier to think of order independent. In other
More informationCS246 Software Abstraction and Specification Final Examination
CS246 Software Abstraction and Specification ination Spring 2007 Date: 04-Aug-2007 Time: 4.00 6.30pm Permitted Aids: None 14 pages Student Name: UW Student ID: Instructions: (Read carefully before the
More informationUnit 9 Tech savvy? Tech support. 1 I have no idea why... Lesson A. A Unscramble the questions. Do you know which battery I should buy?
Unit 9 Tech savvy? Lesson A Tech support 1 I have no idea why... A Unscramble the questions. 1. which battery / Do you know / should / buy / I? Do you know which battery I should buy? 2. they / where /
More informationPlan. Design principles: laughing in the face of change. What kind of change? What are we trying to achieve?
Plan Design principles: laughing in the face of change Perdita Stevens School of Informatics University of Edinburgh What are we trying to achieve? Review: Design principles you know from Inf2C-SE Going
More informationTecniche di Progettazione: Design Patterns
Tecniche di Progettazione: Design Patterns GoF: Startegy 1 Strategy pattern: the duck 2 Strategy pattern: the duck 3 The rubber duck 4 First solution Override fly() Class Rubberduck{ fly() { \\ do nothing
More information1: Introduction to Object (1)
1: Introduction to Object (1) 김동원 2003.01.20 Overview (1) The progress of abstraction Smalltalk Class & Object Interface The hidden implementation Reusing the implementation Inheritance: Reusing the interface
More informationIntroduction to Design Patterns
Introduction to Design Patterns First, what s a design pattern? a general reusable solution to a commonly occurring problem within a given context in software design It s not a finished design that can
More information6.170 Recitation #5: Subtypes and Inheritance
6.170 Recitation #5: Subtypes and Inheritance What is true subtyping? True Subtyping is not exactly the same as Inheritance. As seen in an earlier lecture, class A is a true subtype of class B if and only
More informationMore on Design. CSCI 5828: Foundations of Software Engineering Lecture 23 Kenneth M. Anderson
More on Design CSCI 5828: Foundations of Software Engineering Lecture 23 Kenneth M. Anderson Outline Additional Design-Related Topics Design Patterns Singleton Strategy Model View Controller Design by
More informationCredit where Credit is Due. Lecture 25: Refactoring. Goals for this lecture. Last Lecture
Credit where Credit is Due Lecture 25: Refactoring Kenneth M. Anderson Object-Oriented Analysis and Design CSCI 6448 - Spring Semester, 2002 Some of the material for this lecture and lecture 26 is taken
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 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 informationTutorial notes on. Object relational structural patterns
Tutorial notes on Object relational structural patterns Dr. C. Constantinides, P.Eng. Computer Science and Software Engineering Concordia University Page 1 of 14 Exercise 1. a) Briefly describe what is
More informationC++ (Non for C Programmer) (BT307) 40 Hours
C++ (Non for C Programmer) (BT307) 40 Hours Overview C++ is undoubtedly one of the most widely used programming language for implementing object-oriented systems. The C++ language is based on the popular
More informationFoundations of Software Engineering Design Patterns -- Introduction
Foundations of Software Engineering Design Patterns -- Introduction Fall 2016 Department of Computer Science Ben-Gurion university Based on slides of: Nurit Gal-oz, Department of Computer Science Ben-Gurion
More informationStrong signs your website needs a professional redesign
Strong signs your website needs a professional redesign Think - when was the last time that your business website was updated? Better yet, when was the last time you looked at your website? When the Internet
More informationIntroduction to Object-Oriented Programming
Polymorphism 1 / 19 Introduction to Object-Oriented Programming Today we ll learn how to combine all the elements of object-oriented programming in the design of a program that handles a company payroll.
More informationEMF Temporality. Jean-Claude Coté Éric Ladouceur
EMF Temporality Jean-Claude Coté Éric Ladouceur 1 Introduction... 3 1.1 Dimensions of Time... 3 3 Proposed EMF implementation... 4 3.1 Modeled Persistence... 4 3.2 Modeled Temporal API... 5 3.2.1 Temporal
More information