TDDB84: Design PatternsTDDB84/lectures/2013/Lecture01/slides/Lect… · • Massimiliano Raciti,...
Transcript of TDDB84: Design PatternsTDDB84/lectures/2013/Lecture01/slides/Lect… · • Massimiliano Raciti,...
TDDB84: Design Patterns
fredag 6 september 13
Last year’s edition
• Great course!
• 4.2 in KURT
fredag 6 september 13
Labs• Register before
September 10
• Register in pairs
• Demonstrate individually
• Calculate the number of hours to spend from the course credits
fredag 6 september 13
During the break, find a lab partner here
Course Literature
fredag 6 september 13
This year’s edition
fredag 6 september 13
Tentabaserat lärande & valbara föreläsningsämnen
Föregående års föreläsningar om designmönster som följer Head First kommer användas
This year’s edition
• Much material the same ...
fredag 6 september 13
Tentabaserat lärande & valbara föreläsningsämnen
Föregående års föreläsningar om designmönster som följer Head First kommer användas
This year’s edition
• Much material the same ...
• New staff
fredag 6 september 13
Tentabaserat lärande & valbara föreläsningsämnen
Föregående års föreläsningar om designmönster som följer Head First kommer användas
This year’s edition
• Much material the same ...
• New staff
• New students
fredag 6 september 13
Tentabaserat lärande & valbara föreläsningsämnen
Föregående års föreläsningar om designmönster som följer Head First kommer användas
This year’s edition
• Much material the same ...
• New staff
• New students
• ...
fredag 6 september 13
Tentabaserat lärande & valbara föreläsningsämnen
Föregående års föreläsningar om designmönster som följer Head First kommer användas
This year’s edition
• Much material the same ...
• New staff
• New students
• ...
• And two new features to make it even better
fredag 6 september 13
Tentabaserat lärande & valbara föreläsningsämnen
Föregående års föreläsningar om designmönster som följer Head First kommer användas
I
fredag 6 september 13
Exam-based learning
fredag 6 september 13
An Adapter decouples a client from a complex
interface ○ True ○ False
Justification: ........
fredag 6 september 13
II
fredag 6 september 13
Lecture N Lecture N+1
Head First Design Patterns
fredag 6 september 13
Lecture N Lecture N+1
Head First Design Patterns
fredag 6 september 13
Lecture N Lecture N+1
How does that work in Ruby?
Head First Design Patterns
fredag 6 september 13
Lecture N Lecture N+1
How does that work in Ruby?Java 8?
Head First Design Patterns
fredag 6 september 13
Lecture N Lecture N+1
How does that work in Ruby?Java 8?
Lisp?
Head First Design Patterns
fredag 6 september 13
Lecture N Lecture N+1
How does that work in Ruby?Java 8?
C#?
Lisp?
Head First Design Patterns
fredag 6 september 13
Lecture N Lecture N+1
How does that work in Ruby?
SOLID Java 8?
C#?
Lisp?
Head First Design Patterns
fredag 6 september 13
Lecture N Lecture N+1
How does that work in Ruby?
MVC, MVVM ...
SOLID Java 8?
C#?
Lisp?
Head First Design Patterns
fredag 6 september 13
Lecture N Lecture N+1
Domain-Specific Languages
How does that work in Ruby?
MVC, MVVM ...
SOLID Java 8?
C#?
Lisp?
Head First Design Patterns
fredag 6 september 13
Lecture N Lecture N+1
Domain-Specific Languages
How does that work in Ruby?
Dependency Injection
MVC, MVVM ...
SOLID Java 8?
C#?
Lisp?
Head First Design Patterns
fredag 6 september 13
Lecture N Lecture N+1
Domain-Specific Languages
How does that work in Ruby?
Dependency Injection
MVC, MVVM ...
SOLID Java 8?
C#?
Convention-over-configuration
Lisp?
Head First Design Patterns
fredag 6 september 13
Lecture N Lecture N+1
Domain-Specific Languages
How does that work in Ruby?
Dependency Injection
MVC, MVVM ...
SOLID Java 8?
C#?
Convention-over-configuration
Lisp?
Head First Design Patterns
Fluent API:s
fredag 6 september 13
Staff
• Ola Leifler, Examiner
• Massimiliano Raciti, Course assistant
• Liselotte Lundberg, Course secretary
• Amir Aminifar, AssistantIvan Ukhov, AssistantSimon Ståhlberg, Assistant
fredag 6 september 13
Contact
• E-mail: [email protected]
• https://www.facebook.com/TDDB84HT2013
• http://www.ida.liu.se/~TDDB84
fredag 6 september 13
Course goalsTo give knowledge of design patterns, standard
solutions for standard problems in software designs. To understand software evolution mechanisms such as refactorings. To understand implementation patterns
(idoms) in several domains.
fredag 6 september 13
Course goalsTo give knowledge of design patterns, standard
solutions for standard problems in software designs. To understand software evolution mechanisms such as refactorings. To understand implementation patterns
(idoms) in several domains.
fredag 6 september 13
Course activities
• Lectures x 9
• Seminar x 3
• Lab sessions x 10 per group
fredag 6 september 13
Seminar 1: Practical information about the labs and about UML
What is design?
fredag 6 september 13
fredag 6 september 13
fredag 6 september 13
Imposing structures, intended to show off
fredag 6 september 13
Empty structures
fredag 6 september 13
Design
fredag 6 september 13
(noun) a specification of an object, manifested by an agent, intended to accomplish goals, in a particular environment, using a set of primitive components,
satisfying a set of requirements, subject to constraints;(verb, transitive) to create a design, in an environment
(where the designer operates)
Design
fredag 6 september 13
Or..
fredag 6 september 13
Do what you should the best you can given what
you must
fredag 6 september 13
You Aint Gonna Need ItYAGNI
fredag 6 september 13
Do The Simplest Thing That Could Possibly
WorkDTSTTCPW
fredag 6 september 13
History
fredag 6 september 13
1963: SketchpadIvan Sutherland
fredag 6 september 13
fredag 6 september 13
fredag 6 september 13
1979: MVCTrygve Reenskaug, Xerox Parc
fredag 6 september 13
THING-MODEL-VIEW-EDITOR 12 May 1979 page 3 of 11
The overall structure of our Model (= the Smalltalk representation of a network model of aproject) is thus as follows: .
Within this general framework, we may now add information about our project that may beconnected to the network as a whole, and to each of its activities. To the network, we may forexample add the fields plannedStart and plannedFinish. To the definition of class Activitywe may add the fields duration, earlyStart, lateStart, and resourccRcquirements. We mayalso add fields for late start and late finish, but decide to compute these quantities wheneverneeded. (From duration and earlyStart or lateStart).Note that the network Model with its sub-Models for each activity contains no informationabout how the information may be shown on the screen, it is a clean representation of theabstract project model.
VIEWDEFINITIONTo any given Model there is attached one or more Views, each View being capable ofshowing one or more pictorial representations of the Model on the screen and on hardcopy. AView is also able to perform such operations upon the Model that is reasonabely associatedwith that View.
COMMENTThe implementation of all Views would be simplified if they were based upon the Form-Path-Image metaphors.
EXAMPLE 1: List of networksThis View belongs to a super-network, i.e. a collection of networks. It isthus slightly outside the scope of the Models discussed so far, but isincluded for completeness. The appearance of a list of networks isshown to the left.A list of networks is an instance of class NetworkList, which is asubclass of ListView.
fredag 6 september 13
THING-MODEL-VIEW-EDITOR 12 May 1979 page 5 of 11
to react to messages about the activity that are initiated by the user through an Editor. One setof such messages apply to modification of the data presented in the View, this is taken care ofby the superclass TextView. The probably most important command to ActivityText itself isaccept, requsting the View to check its present contents and to pass the information on to thenetwork Model as an update of the attributes of the activity.This View could be greatly improved if the class was made subclass of a tabular View ratherthan the present running text
EXAMPLE 4: Network diagram
The diagram above is an instance of class DiagramView. It is the only example where the datain the View cannot be fully deduced from its Model, and it must have fields containing theshape and position of all the symbols, since this information is not part of the Model itself.(Programs exist for the automatic positioning of symbols within a diagram. but we assume that at least somemanual editing will be required). The placement of the arrows may be deduced from thedependencies between the activitities, this information may be fetched from theNetworkModel whenever needed for the display. Such a procedure will be very slow,however, and we assume that the Diagram View keeps a copy of that information forefficiency reasons.Just as all the other views, a Diagram View will need to supply the two operations needed toselect an activity, and the operations needed for scrolling (this time in two dimensions). Inaddition, it will need some operations on the View itself, they have to do with the positioningof the symbols in the diagram. Other operations have to do with network Model, for examplemodify dependencies of an activity and transfer activity from one network to another.
THING-MODEL-VIEW-EDITOR 12 May 1979 page 6 of 11
EXAMPLE 5: A variation on the network diagram
This View provides an alternative to the previous example. The symbols are smaller, and ittherefore possible to present a larger part of the network on the screen. The small symbol sizemakes it impractical to print the activity name in the symbol, and the user must get thisinformation by some other means.The network diagram is presented on a gridded background. This is used when the user islaying out the diagram, and the dots define the permissible positions of the activity symbols.This View could be implemented as a subclass of DiagramView, or both could be subclassesof some common View. In the present implementation, however, both Views may begenerated alternately by the same object: class Diagram View has has a field displayType thatmay take the values #large or #small, and the various display methods are controlled by thatfield. The gridding is displayed in the diagram through a separate method.
THING-MODEL-VIEW-EDITOR 12 May 1979 page 7 of 11
EXAMPLE 6: Gantt diagram
This View shows the activities along the vertical axis and time along the horizontal axis. Inthis particular view, only one time schedule for each activity is shown. Through varying theshading, it is quite easy to extend the presentation to include how much each activity mayfloat in time without upsetting the overall project schedule.The diagram is an instance of class GanttView, which is a subclass of ChartView. ChartViewknows about the diagram background: axis with legend, gridding etc. It does not knowanything about the information to be put into the diagram, in this case the horizontal bars. Itaids its subclasses in presenting this information, however, through providing methods forconversion from whatever coordinate system is used externally to the frame coordinates of thediagram.Class GanttView understands a number of messages from the user, most commonly giventhrough an Editor. One such message is viewNetwork:, this message provides the name ofthe current NetworkModel. It will also be able to answer a question about which activitybelongs to the bar under a given point in the diagram, and to select the bar belonging to agiven activity. It is also able to pass on operations on the network and its activities that arerelated to this particular View. Typical operations have to do with modifying the currentschedule. Operations should be provided for planning the network as a whole (backload: andfrontload:), for modifying the schedule of a single activity (plannedStart: andplanncdFinish:), and for letting the consequences of such a modification work its waytowards the front or back end of the network.The NetworkModel must be able to answer a few questions rom a GanttPane giving a list ofall activities, the schedule of the network as a whole, and the schedule of each individualactivity.
fredag 6 september 13
1979: The Timeless Way of BuildingChristopher Alexander
fredag 6 september 13
fredag 6 september 13
fredag 6 september 13
fredag 6 september 13
1995: Design Patterns - Elements of Reusable
Object-Oriented Software
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
fredag 6 september 13
Design Patterns:Descriptions of common solutions to common
problems in object-oriented programming (in C++)
fredag 6 september 13
Design Patterns:Emulation of a human compiler if you’re stuck with
languages that descend from C (C++, C#, Java)
fredag 6 september 13
Design Patterns:A language for communicating solutions with others
fredag 6 september 13
Some words of caution:
fredag 6 september 13
Design patterns are not a substitute for thinking
fredag 6 september 13
Class names and directory structures
!= good design
fredag 6 september 13
Design Patterns have tradeoffs
fredag 6 september 13
A Mediator does not remove any complexity in the interaction between different component, it merely centralizes the management of this complexity in one place
Design Patterns strongly depend on
programming language
fredag 6 september 13
Language restrictions in C++ and Java may necessitate some design patterns regarding how objects are created and manipulated, while more dynamic languages with less restrictions introduce other means of solving the same problems. See Peter Norvigs introduction on the Useful links section of the course home page. If you’re interested, I’ll talk more about that
Describing Design Patterns
fredag 6 september 13
Describing Design Patterns
• Pattern Name and Classification
fredag 6 september 13
Describing Design Patterns
• Pattern Name and Classification
• Intent
fredag 6 september 13
Describing Design Patterns
• Pattern Name and Classification
• Intent
• Also Known As
fredag 6 september 13
Describing Design Patterns
• Pattern Name and Classification
• Intent
• Also Known As
• Justification
fredag 6 september 13
Describing Design Patterns
• Pattern Name and Classification
• Intent
• Also Known As
• Justification
• Applicability
fredag 6 september 13
Describing Design Patterns
• Pattern Name and Classification
• Intent
• Also Known As
• Justification
• Applicability
• Structure
fredag 6 september 13
Describing Design Patterns
• Pattern Name and Classification
• Intent
• Also Known As
• Justification
• Applicability
• Structure
• Participants
fredag 6 september 13
Describing Design Patterns
• Pattern Name and Classification
• Intent
• Also Known As
• Justification
• Applicability
• Structure
• Participants
• Collaborations
fredag 6 september 13
Describing Design Patterns
• Pattern Name and Classification
• Intent
• Also Known As
• Justification
• Applicability
• Structure
• Participants
• Collaborations
• Consequences
fredag 6 september 13
Describing Design Patterns
• Pattern Name and Classification
• Intent
• Also Known As
• Justification
• Applicability
• Structure
• Participants
• Collaborations
• Consequences
• Implementation
fredag 6 september 13
Describing Design Patterns
• Pattern Name and Classification
• Intent
• Also Known As
• Justification
• Applicability
• Structure
• Participants
• Collaborations
• Consequences
• Implementation
• Sample Code
fredag 6 september 13
Describing Design Patterns
• Pattern Name and Classification
• Intent
• Also Known As
• Justification
• Applicability
• Structure
• Participants
• Collaborations
• Consequences
• Implementation
• Sample Code
• Known Uses
fredag 6 september 13
Describing Design Patterns
• Pattern Name and Classification
• Intent
• Also Known As
• Justification
• Applicability
• Structure
• Participants
• Collaborations
• Consequences
• Implementation
• Sample Code
• Known Uses
• Related Patterns
fredag 6 september 13
Describing Design Patterns
• Pattern Name and Classification
• Intent
• Also Known As
• Justification
• Applicability
• Structure
• Participants
• Collaborations
• Consequences
• Implementation
• Sample Code
• Known Uses
• Related Patterns
fredag 6 september 13
Describing Design Patterns
• Pattern Name and Classification
• Intent
• Also Known As
• Justification
• Applicability
• Structure
• Participants
• Collaborations
• Consequences
• Implementation
• Sample Code
• Known Uses
• Related Patterns
fredag 6 september 13
Time for some code!
fredag 6 september 13
SimUDuck
fredag 6 september 13
Demo: Write some classes in Java,
SimUDuck
There should be swimming ducks!
fredag 6 september 13
Demo: Write some classes in Java,
SimUDuck
There should be swimming ducks!
and quacking ducks!
fredag 6 september 13
Demo: Write some classes in Java,
SimUDuck
There should be swimming ducks!
and quacking ducks!
and Mallard Ducks!
fredag 6 september 13
Demo: Write some classes in Java,
SimUDuck
There should be swimming ducks!
and quacking ducks!
and Mallard Ducks! and Red Ducks!
fredag 6 september 13
Demo: Write some classes in Java,
SimUDuck
There should be swimming ducks!
and quacking ducks!
and Mallard Ducks! and Red Ducks!
and flying ducks!
fredag 6 september 13
Demo: Write some classes in Java,
fredag 6 september 13
and rubber ducks!
fredag 6 september 13
fredag 6 september 13
Let q(x) be a property provable about objects x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T
fredag 6 september 13
SOLID
Let q(x) be a property provable about objects x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T
fredag 6 september 13
SOLID
Let q(x) be a property provable about objects x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T
fredag 6 september 13
Liskov Substitution Principle
SOLID
Let q(x) be a property provable about objects x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T
fredag 6 september 13
Magic rules
fredag 6 september 13
• Encapsulate what varies
Magic rules
fredag 6 september 13
• Encapsulate what varies
• Program to an interface, not to an implementation
Magic rules
fredag 6 september 13
• Encapsulate what varies
• Program to an interface, not to an implementation
• Favor composition over inheritance
Magic rules
fredag 6 september 13
• Encapsulate what varies
• Program to an interface, not to an implementation
• Favor composition over inheritance
• ...
Magic rules
fredag 6 september 13
fredag 6 september 13
Strategy
fredag 6 september 13
Strategy• When related classes only
differ in behavior
• You need different variants of an algorithm
• An algorithm uses data the clients don’t need to know
• A class uses conditionals for selecting behavior
fredag 6 september 13
Strategy• When related classes only
differ in behavior
• You need different variants of an algorithm
• An algorithm uses data the clients don’t need to know
• A class uses conditionals for selecting behavior
Abstract Factory
• A system should be independent of how its products are created
• A system should be configured with one of multiple families of products
• You want to provide a class library of products, and only expose their interfaces
fredag 6 september 13
Strategy• When related classes only
differ in behavior
• You need different variants of an algorithm
• An algorithm uses data the clients don’t need to know
• A class uses conditionals for selecting behavior
Abstract Factory
• A system should be independent of how its products are created
• A system should be configured with one of multiple families of products
• You want to provide a class library of products, and only expose their interfaces
Behavioral
fredag 6 september 13
Strategy• When related classes only
differ in behavior
• You need different variants of an algorithm
• An algorithm uses data the clients don’t need to know
• A class uses conditionals for selecting behavior
Abstract Factory
• A system should be independent of how its products are created
• A system should be configured with one of multiple families of products
• You want to provide a class library of products, and only expose their interfaces
Behavioral Structural
fredag 6 september 13
An Adapter decouples a client from a complex
interface ○ True ○ False
Justification: ........False, an Adapter simply changes the interface of an
object into one that is expected by a client. The Façade provides clients with a simplified interface to
a complex systemfredag 6 september 13