TDDB84: Design PatternsTDDB84/lectures/2013/Lecture01/slides/Lect… · • Massimiliano Raciti, Course assistant ... solutions for standard problems in software designs. To understand

TDDB84: Design Patterns

Ola [email protected]

fredag 6 september 13

mailto:[email protected]


Last year’s edition

• Great course!

• 4.2 in KURT


Labs• Register before

September 10

• Register in pairs

• Demonstrate individually

• Calculate the number of hours to spend from the course credits


During the break, find a lab partner here

Course Literature


This year’s edition


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


• Much material the same ...






• New staff






• New staff

• New students






• New staff

• New students

• ...






• New staff

• New students

• ...

• And two new features to make it even better




I


Exam-based learning


An Adapter decouples a client from a complex

interface ○ True ○ False

Justification: ........


II


Lecture N Lecture N+1

Head First Design Patterns






How does that work in Ruby?




How does that work in Ruby?Java 8?





Lisp?





C#?

Lisp?





SOLID Java 8?

C#?

Lisp?





MVC, MVVM ...

SOLID Java 8?

C#?

Lisp?




Domain-Specific Languages


MVC, MVVM ...

SOLID Java 8?

C#?

Lisp?






Dependency Injection

MVC, MVVM ...

SOLID Java 8?

C#?

Lisp?







MVC, MVVM ...

SOLID Java 8?

C#?

Convention-over-configuration

Lisp?







MVC, MVVM ...

SOLID Java 8?

C#?

Convention-over-configuration

Lisp?


Fluent API:s


Staff

• Ola Leifler, Examiner

• Massimiliano Raciti, Course assistant

• Liselotte Lundberg, Course secretary

• Amir Aminifar, AssistantIvan Ukhov, AssistantSimon Ståhlberg, Assistant


https://www.ida.liu.se/department/contact/contactcard.en.shtml?olale

https://www.ida.liu.se/department/contact/contactcard.en.shtml?olale

https://www.ida.liu.se/department/contact/contactcard.en.shtml?masra

https://www.ida.liu.se/department/contact/contactcard.en.shtml?masra

https://www.ida.liu.se/department/contact/contactcard.en.shtml?lislu40

https://www.ida.liu.se/department/contact/contactcard.en.shtml?lislu40

https://www.ida.liu.se/department/contact/contactcard.en.shtml?amiam

https://www.ida.liu.se/department/contact/contactcard.en.shtml?amiam

https://www.ida.liu.se/department/contact/contactcard.en.shtml?ivauk83

https://www.ida.liu.se/department/contact/contactcard.en.shtml?ivauk83

https://www.ida.liu.se/department/contact/contactcard.en.shtml?simst50

https://www.ida.liu.se/department/contact/contactcard.en.shtml?simst50

Contact

• E-mail: [email protected]

• https://www.facebook.com/TDDB84HT2013

• http://www.ida.liu.se/~TDDB84




https://www.facebook.com/TDDB84HT2013




http://www.ida.liu.se/~TDDB84

http://www.ida.liu.se/~TDDB84

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.


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.


Course activities

• Lectures x 9

• Seminar x 3

• Lab sessions x 10 per group


Seminar 1: Practical information about the labs and about UML

What is design?




Imposing structures, intended to show off


Empty structures


Design


(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


http://en.wikipedia.org/wiki/Object_(philosophy)

http://en.wikipedia.org/wiki/Object_(philosophy)

http://en.wikipedia.org/wiki/Agency_(philosophy)

http://en.wikipedia.org/wiki/Agency_(philosophy)

http://en.wikipedia.org/wiki/Goal

http://en.wikipedia.org/wiki/Goal

http://en.wikipedia.org/wiki/Environment_(systems)


http://en.wikipedia.org/wiki/Requirement

http://en.wikipedia.org/wiki/Requirement



Or..


Do what you should the best you can given what

you must


You Aint Gonna Need ItYAGNI


Do The Simplest Thing That Could Possibly

WorkDTSTTCPW


History


1963: SketchpadIvan Sutherland




1979: MVCTrygve Reenskaug, Xerox Parc


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.



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.


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.


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.


1979: The Timeless Way of BuildingChristopher Alexander





1995: Design Patterns - Elements of Reusable

Object-Oriented Software

Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides


Design Patterns:Descriptions of common solutions to common

problems in object-oriented programming (in C++)


Design Patterns:Emulation of a human compiler if you’re stuck with

languages that descend from C (C++, C#, Java)


Design Patterns:A language for communicating solutions with others


Some words of caution:


Design patterns are not a substitute for thinking


Class names and directory structures

!= good design


Design Patterns have tradeoffs


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


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



• Pattern Name and Classification




• Intent




• Intent

• Also Known As




• Intent

• Also Known As

• Justification




• Intent

• Also Known As

• Justification

• Applicability




• Intent

• Also Known As

• Justification

• Applicability

• Structure




• Intent

• Also Known As

• Justification

• Applicability

• Structure

• Participants




• Intent

• Also Known As

• Justification

• Applicability

• Structure

• Participants

• Collaborations




• Intent

• Also Known As

• Justification

• Applicability

• Structure

• Participants

• Collaborations

• Consequences




• Intent

• Also Known As

• Justification

• Applicability

• Structure

• Participants

• Collaborations

• Consequences

• Implementation




• Intent

• Also Known As

• Justification

• Applicability

• Structure

• Participants

• Collaborations

• Consequences

• Implementation

• Sample Code




• Intent

• Also Known As

• Justification

• Applicability

• Structure

• Participants

• Collaborations

• Consequences

• Implementation

• Sample Code

• Known Uses




• Intent

• Also Known As

• Justification

• Applicability

• Structure

• Participants

• Collaborations

• Consequences

• Implementation

• Sample Code

• Known Uses

• Related Patterns




• Intent

• Also Known As

• Justification

• Applicability

• Structure

• Participants

• Collaborations

• Consequences

• Implementation

• Sample Code

• Known Uses





• Intent

• Also Known As

• Justification

• Applicability

• Structure

• Participants

• Collaborations

• Consequences

• Implementation

• Sample Code

• Known Uses



Time for some code!


SimUDuck


Demo: Write some classes in Java,

SimUDuck

There should be swimming ducks!



SimUDuck


and quacking ducks!



SimUDuck


and quacking ducks!

and Mallard Ducks!



SimUDuck


and quacking ducks!

and Mallard Ducks! and Red Ducks!



SimUDuck


and quacking ducks!

and Mallard Ducks! and Red Ducks!

and flying ducks!




and rubber ducks!



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


SOLID



SOLID



Liskov Substitution Principle

SOLID



Magic rules


• Encapsulate what varies

Magic rules



• Program to an interface, not to an implementation

Magic rules




• Favor composition over inheritance

Magic rules




• Favor composition over inheritance

• ...

Magic rules



Strategy


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



differ in 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



differ in behavior




Abstract Factory




Behavioral



differ in behavior




Abstract Factory




Behavioral Structural


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

Documents

TDDB84: Design PatternsTDDB84/lectures/2013/Lecture01/slides/Lect… · • Massimiliano Raciti, Course assistant ... solutions for standard problems in software designs. To understand