designing object oriented software - lecture slides 2013
DESCRIPTION
Slides from the course Designing Object Oriented Software (spring 2013). The course focuses on the principles, patterns and practices behind sound software designs.TRANSCRIPT
![Page 1: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/1.jpg)
Designing Object-Oriented Software
Jouni Smed 2013
![Page 2: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/2.jpg)
Course Syllabus
l Credits: 5 cp l Teaching methods: lectures, voluntary
exercise work ¡ Thursdays 10–12, Auditorium Alpha ¡ from March 14 to April 25
l Assessment: examination only l Course web page: http://bit.ly/doos2013
![Page 3: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/3.jpg)
Examinations
l Electronic examination ¡ opens May 6, 2013 ¡ closes September 30, 2013
l You can take the examination at most three (3) times
l For instructions and examination time reservations, see https://tenttis.utu.fi/
![Page 4: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/4.jpg)
Voluntary Exercise Work
l Four group sessions ¡ in April (the exact dates are to be
announced) ¡ organized by Antero Järvi and Aki Salmi
l Hands-on exercises in software design
l Active participation can give you extra points for the assessment
![Page 5: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/5.jpg)
Assessment
l Examination: 18 points l Voluntary exercise work: 2 bonus
points l Grading (based on 18 points):
¡ points: [9, 10] ⇒ grade: 1 ¡ points: (10, 12] ⇒ grade: 2 ¡ points: (12, 14] ⇒ grade: 3 ¡ points: (14, 16] ⇒ grade: 4 ¡ points: (16, 20] ⇒ grade: 5
![Page 6: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/6.jpg)
Textbook for the Course
l Martin, Robert C., and Martin, Micah: Agile Principles, Patterns and Practices in C#, Prentice-Hall, 2006, ISBN: 0-13-185725-8
Or the older version: l Martin, Robert C.: Agile Software
Development: Principles, Patterns, and Practices, Prentice-Hall, 2003, ISBN: 0-13-597444-5
![Page 7: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/7.jpg)
Outline of the Course Lecture Topics Note 1. March 14 Introduction. Models for software
production. Design smells. 2. March 21 Design principles: SRP, OCP, LSP.
3. March 28 Design principles: DIP, ISP. Design patterns.
4. April 4 Design patterns.
5. April 11 Package design principles: REP, CRP, CCP, ADP, SDP, SAP.
6. April 18 Design patterns.
7. April 25 Design patterns. Conclusions
![Page 8: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/8.jpg)
What is Design?
l Design is a creative process ¡ there is no algorithm
l Designing software systems is a creative process, where the designer has a goal given by the customer
![Page 9: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/9.jpg)
What is Object Oriented?
l Object oriented means a way of dividing a complex whole into independent, co-operating components
l The challenge is to find a natural division ¡ “natural” can mean different things in
different situations
![Page 10: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/10.jpg)
What is a System?
l A system is a task (small or large) automatized by software ¡ the scope is normally defined by the
customer l If the system is not defined well, the
software design process will fail ¡ the system will not be helpful ¡ the system will not be used the end-
users nor will help their work
![Page 11: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/11.jpg)
A SHORT HISTORY OF SOFTWARE DESIGN
![Page 12: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/12.jpg)
Programming in the 1940s and 1950s
l Programming = instructing the machine operations ¡ machine language or assembler ¡ machine-oriented programming
l Far from the way programmers (humans) think l The problem domain remained close to the
machine world ¡ making calculations, sorting data etc.
l Main goals of design ¡ enable the programmer to write the software ¡ focus on the design of algorithms and data structures.
l Implementing the design was difficult
![Page 13: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/13.jpg)
Programming in the 1960s and 1970s
l ‘High-level’ programming languages ¡ Algol, Fortran, Pascal, Ada, C, … ¡ problem-oriented programming
l Innovations ¡ reducing machine dependency: portability ¡ managing complex and large problems: structured
programming, modular programming and information hiding
l Main goals of design ¡ enable an automatic transformation of an analysis model
to a program structure ¡ managing the work of many simultaneous programmers ¡ keeping the system maintainable
![Page 14: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/14.jpg)
Programming in the 1960s and 1970s (cont’d) l Programming comprised
¡ creating and manipulating complex data structures and algorithms
¡ realizing subroutines ¡ dealing with the physical organization of the software
l The problem domain took a big leap towards the real world ¡ commercial information systems, traffic, science…
l This was the era of waterfall way of building systems, which led to the so-called software crisis
![Page 15: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/15.jpg)
Programming in the 1980s and 1990s
l Rise of the object-oriented (OO) paradigm ¡ real-world concepts are directly supported with programming
language constructs (e.g. classes) l Detailed design
¡ how to implement an analysis model with OO mechanisms? ¡ class-level reuse, specifying the programming task for a
programmer, understandability and maintainability of the source code
l Architecture design ¡ how to create, describe and manage the big picture of a
system ¡ maintainability of the system, manageability during design
(multiple team development), handling non-functional properties of the system, high-level reuse, adaptability of the system…
l Programming was still seen as realizing the design
![Page 16: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/16.jpg)
Programming Now l The new software crisis: the bloat of design work
¡ expensive ¡ opposes maintainability and adaptability
l Iterative way of building large systems changes the role of design ¡ the design is created piece by piece as the understanding of
the problem grows l Programming and detailed design are unifying
¡ high-level constructs allow to express the design in the code ¡ design patterns allow even to express the architecture design
l The role of the programmer is rising ¡ operates at the design level ¡ understands the profound object-oriented principles
![Page 17: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/17.jpg)
Three Perspectives on Software Development
l Conceptual ¡ represents the concepts in the
problem-domain ¡ objects defined in the terms of
responsibilities l Specification
¡ focuses on the software at the level of interfaces (not the implementation)
¡ how the modules are connected l Implementation
¡ looks inside the modules, the code ¡ probably the most often used
perspective (should not be) ¡ objects are seen as encapsulating data
and providing access to services
Design
Programming
![Page 18: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/18.jpg)
Traditional Engineering… l The design is expressed in the blueprints l Engineers try to make absolutely sure that
¡ the design is correct ¡ requirements are met ¡ the product will function as specified
l Why? ¡ building the product is expensive ¡ construction cannot be undone (or it is
expensive to do so) l Construction is done by different people → The blueprints must contain all information needed for construction
![Page 19: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/19.jpg)
…and Software Engineering
l Source code is the blueprints l Compiler does the actual
construction work l Since construction is virtually
costless it can be redone over and over again! ¡ traditional engineering ≠ software
engineering
![Page 20: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/20.jpg)
What Makes Software Systems Complicated? l The problem being solved
¡ finding and understanding the requirements l The software itself
¡ managing and understanding the software ¡ finding a solution that meet the requirements
l The software organization ¡ managing the employees working on the same system
l The software industry ¡ constantly changing environments ¡ market situation ¡ platform technologies
![Page 21: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/21.jpg)
Programming vs. Design? l Complexity and volatile requirements → iterative approach with feedback
l Construction is cheap ¡ no need to speculate by building models, prototypes, simulations
l Iteration can cover analysis-design-implementation-testing phases → the act of design in software engineering
l Programming is ¡ constructing the software (i.e. programming) ¡ designing the software
l Not designing the program but programming the design
![Page 22: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/22.jpg)
MODELS FOR SOFTWARE PRODUCTION
![Page 23: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/23.jpg)
The Waterfall Model
Requirements
Design
Implementation
Verification
Maintenance
![Page 24: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/24.jpg)
The Spiral Model
pict
ure
sour
ce:
Wik
imed
ia C
omm
ons
![Page 25: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/25.jpg)
Agile Software Development
l Values good old engineering skills over the exact process management of business people
l Reduces the overhead from process management to minimum
l Requires that the developers can self-organize
![Page 26: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/26.jpg)
The Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more
![Page 27: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/27.jpg)
Agile Methods
l Refers to a family of methods that agree with the values given in the Agile Manifesto ¡ Extreme programming (XP) ¡ Scrum ¡ DSDM ¡ Crystal
![Page 28: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/28.jpg)
TESTING AND REFACTORING
![Page 29: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/29.jpg)
Development
l Planning l Testing l Refactoring
![Page 30: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/30.jpg)
Planning l Initial exploration
¡ developers and customers identify all significant user stories ¡ estimate the cost of the stories
l splitting and merging l velocity ← cost and priority of a story
l Release planning ¡ a crude selection of stories to be implemented in the first
release l business decisions
¡ developers and customers agree on a date for the first release l typically 2–4 months in the future
l Iteration planning ¡ developers and customers agree on the iteration length
l typically 2 weeks
![Page 31: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/31.jpg)
Iteration l Start:
¡ developers and customers get together ¡ customers choose stories to be implemented
l no more than velocity allows l cannot be changed once the iteration has begun
¡ task planning: developers break the stories down to development tasks (implementable in 4–16 h)
l Halfway point: ¡ the team meats and assesses the progress so far
l End: ¡ iteration ends on the specified date (regardless whether the
stories are done) ¡ developers demonstrate the current running executable to the
customers for evaluation ¡ the velocity is updated
![Page 32: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/32.jpg)
Testing l Writing unit tests is an act of
¡ design ¡ documentation ¡ verification
l Test driven development: design tests before you design the program
l Effects ¡ backstop for further development: add and change
without fear of breaking the existing software ¡ different point of view: write from the vantage point of a
caller of the program → interface and function of a program
¡ forces to decouple the software ¡ documentation: how to call a function? check the test!
![Page 33: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/33.jpg)
Testing (cont’d)
l Unit tests ¡ white-box tests that verify individual
mechanisms ¡ do not verify that the system works as a whole ¡ documents the internals of a system
l Acceptance tests ¡ black-box tests that verify that customer
requirements are being met ¡ written by people (customers, QA) who do not
know the internal mechanisms of the system ¡ documents the features of a system
![Page 34: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/34.jpg)
Refactoring
l Practical definition: altering the source code systematically to improve its design ¡ easier to understand ¡ cheaper to modify ¡ does not change its observable behavior ¡ the goal is not better performance
![Page 35: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/35.jpg)
Benefits of Refactoring
l Improves the design of the software ¡ creates the design in the existing code ¡ adjusts the design piece by piece to changing
functionality l Helps in finding bugs
¡ clarifies the purpose of the code to a point where you simply cannot avoid seeing the bugs
l Helps in programming faster ¡ without refactoring you start faster but lose
speed after a while
![Page 36: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/36.jpg)
When to Refactor? l Rule of three
¡ first time: just do it ¡ second time: you may duplicate ¡ third time: refactor
l Refactor when you add functionality ¡ refactor the code that is going to change before you make the
change to understand it deeply ¡ if the change does not fit in easily, refactor the design to
enable smooth addition of the new feature l Refactor when you need to fix a bug
¡ a bug indicates that the code is not easy to understand l Refactor in a code review
¡ if you are going through the code, why not go through the design as well
l Refactor all the time ¡ it is an integral part of designing and programming
![Page 37: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/37.jpg)
DESIGN SMELLS
![Page 38: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/38.jpg)
Design Smells
l A design smell is a sign that the design process is out of control
l A serious case can result in missed deadlines and increasing costs
l This can be avoided by ¡ incremental design ¡ constant refactoring at many levels
![Page 39: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/39.jpg)
What Goes Wrong with Software?
l You start with a clear picture in your mind l Then something goes wrong
¡ changes and additions are harder and harder to make
¡ you are forced to let go of the original design ideas
¡ eventually even the simplest changes terrify you because of rippling unexpected effects, and you must redesign the whole software.
l You started with good intentions, so what went wrong?
![Page 40: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/40.jpg)
Design Smells a.k.a Seven Deadly Sins a.k.a. Symptoms of Poor Design 1. Rigidity 2. Fragility 3. Immobility 4. Viscosity 5. Needless complexity 6. Needless repetition 7. Opacity
![Page 41: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/41.jpg)
Rigidity
l The design is hard to change ¡ changes propagate via dependencies to
other modules ¡ no continuity in the code
l Management reluctance to change anything becomes the policy
l Telltale sign: ‘Huh, it was a lot more complicated than I thought.’
![Page 42: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/42.jpg)
Fragility l The design is easy to break
¡ changes cause cascading effects to many places
¡ the code breaks in unexpected places that have no conceptual relationship with the changed area
¡ fixing the problems causes new problems l Telltale signs
¡ some modules are constantly on the bug list ¡ time is used finding bugs, not fixing them ¡ programmers are reluctant to change anything
in the code
![Page 43: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/43.jpg)
Immobility
l The design is hard to reuse ¡ the code is so tangled that it is
impossible to reuse anything l Telltale sign: a module could be
reused but the effort and risk of separating it from the original environment is too high
![Page 44: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/44.jpg)
Viscosity l Viscosity of the software
¡ changes or additions are easier to implement by doing the wrong thing
l Viscosity of the environment ¡ the development environment is slow and inefficient ¡ high compile times, long feedback time in testing,
laborious integration in a multi-team project l Telltale signs
¡ when a change is needed, you are tempted to hack rather than to preserve the original design
¡ you are reluctant to execute a fast feedback loop and instead tend to code larger pieces
![Page 45: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/45.jpg)
Needless Complexity
l Design contains elements that are not currently useful ¡ too much anticipation of future needs ¡ developers try to protect themselves against
probable future changes ¡ agile principles state that you should never
anticipate future needs l Extra complexity is needed only when
designing an application framework or customizable component
l Telltale sign: investing in uncertainty
![Page 46: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/46.jpg)
Needless Repetition
l The same code appears over and over again, in slightly different forms ¡ developers are missing an abstraction ¡ bugs found in a repeating unit have to
be fixed in every repetition l Telltale sign: overuse of copy-and-
paste
![Page 47: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/47.jpg)
Opacity
l The tendency of a module to become more difficult to understand ¡ every module gets more opaque over time ¡ a constant effort is needed to keep the code
readable l easy to understand l communicates its design
l Telltale sign: you are reluctant to fix somebody else’s code – or even your own!
E
E E E
E
E
E E
E
E
E E E
![Page 48: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/48.jpg)
DESIGN PRINCIPLES
![Page 49: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/49.jpg)
How to Avoid the Design Smells
l There are five central design priciples that guide towards good design and good coding practices
l If the right design principles are well understood, they will lead the design in the right direction without the need for extensive planning
![Page 50: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/50.jpg)
The Five Principles
1. Single-Responsibility Principle 2. Open–Closed Principle 3. Liskov Substitution Principle 4. Depency-Inversion Principle 5. Interface-Segregation Principle
![Page 51: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/51.jpg)
SRP: The Single-Responsibility Principle
l Cohesion: how good a reason the elements of a module have to be in the same module
l Cohesion and SRP: the forces that cause the module to change
A class should have only one reason to change.
![Page 52: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/52.jpg)
Responsibility l Rationale behind SRP
¡ changes in requirements → changes in class responsibilities
¡ a ‘cohesive’ responsibility is a single axis of chance → a class should have only one responsibility
¡ responsibility = a reason to change l Violation of SRP causes spurious transitive
dependencies between modules that are hard to anticipate → fragility
l Separating the responsibilities into interfaces decouples them as far as rest of the application is concerned
![Page 53: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/53.jpg)
SRP Example: Rectangle Separated responsibilities
Computational Geometry Application
Graphical Application
GUI
Geometric Rectangle
+area(): double
Rectangle
+draw()
Computational Geometry Application
Graphical Application
More than one responsibility
GUI Rectangle
+draw() +area(): double
![Page 54: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/54.jpg)
SRP Example: Modem 1(2)
public interface Modem {
public void dial(String pno);
public hangup();
public void send(char c);
public char receive();
}
![Page 55: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/55.jpg)
SRP Example: Modem 2(2)
public interface Connection {
public void dial(String pno);
public hangup();
}
public interface DataChannel {
public void send(char c);
public char receive();
}
![Page 56: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/56.jpg)
OCP: The Open–Closed Principle
l ‘Open for extension’: the behaviour of a module can be extended with new behaviours to satisfy the changing requirements
l ‘Closed for modification’: extending the module must not result in changes to the source or even binary code of the module
Software entities should be open for extension, but closed for modification.
– Bertrand Meyer
![Page 57: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/57.jpg)
OCP (cont’d)
l Reduces rigidity ¡ a change does not cause a cascade of related
changes in dependent modules l Changing the module without changing its
source code – a contradiction?! l How to avoid dependency on a concrete
class? ¡ abstraction ¡ dynamic binding
![Page 58: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/58.jpg)
Basic OCP Designs
Client «interface» Client Interface
Server
STRATEGY
Policy +policyFunction() -serviceFunction()
Implementation
-serviceFunction()
TEMPLATE METHOD
![Page 59: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/59.jpg)
Strategic Closure l Conforming to the OCP is expensive, since it can
incur needless complexity l All changes cannot be anticipated
¡ apply OCP to the most obvious changes l Otherwise: ‘Fool me once, shame on you. Fool
me twice, shame on me.’ ¡ once a change has occurred, it is more probable that a
similar kind of change will occur later ¡ apply OCP when it is needed for the first time
l A good strategy: stimulate early changes ¡ fast iterations ¡ constant feedback
![Page 60: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/60.jpg)
OCP: Simple Heuristics
l Make all object-data private ¡ changes to public data are always at risk to
‘open’ the module ¡ all clients of a module with public data
members are open to one misbehaving module ¡ errors can be difficult to find and fixes may
cause errors elsewhere l No global variables
¡ it is impossible to close a module against a global variable
![Page 61: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/61.jpg)
LSP: The Liskov Substitution Principle
l Functions that refer to base classes must be able to use objects of both existing and future derived classes without knowing it
l Inheritance must be used in a way that any property proved about supertype objects also holds for the subtype objects
Subtypes must be substitutable for their base types.
– Barbara Liskov
![Page 62: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/62.jpg)
LSP and OCP l LSP is motived by OCP (at least partly)
¡ abstraction and polymorphism allows us to achieve OCP, but how to use them?
¡ key mechanism in statically typed languages: inheritance
l LSP restricts the use of inheritance in a way that OCP holds
l LSP addresses the questions of ¡ what are the inheritance hierarchies that give designs
conforming to OCP ¡ what are the common mistakes we make with
inheritance regarding OCP? l Violation of LSP is a latent violation of OCP
![Page 63: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/63.jpg)
Example: Inheritance Has Its Limits
public abstract class Bird { public abstract void fly(); } public class Parrot extends Bird { public void fly() { /* implementation */ } public void speak() { /* implementation */ } } public class Penguin extends Bird { public void fly() { throw new UnsupportedOperationException(); } }
![Page 64: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/64.jpg)
Example (cont’d) public static void playWith(Bird bird) { bird.fly(); } Parrot myPet; playWith(myPet); // myPet "is-a" bird and can fly() Penguin myOtherPet; playWith(myOtherPet); // myOtherPet "is-a" bird // and cannot fly()?!
![Page 65: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/65.jpg)
Example (cont’d) l What went wrong?
¡ we did not model ‘Penguins cannot fly’ ¡ we modelled ‘Penguins may fly, but if they try it is an
error’ l The design fails LSP
¡ a property assumed by the client about the base type does not hold for the subtype
¡ Penguin is not a subtype of Bird l Subtypes must respect what the client of the
base class can reasonably expect about the base class ¡ but how can we anticipate what some client will expect?
![Page 66: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/66.jpg)
Design by Contract l A class declares its behaviour
¡ requirements (preconditions) that must be fulfilled ¡ promises (postconditions) that will hold afterwards
l This forms a contract between the class and a client using its services ¡ tells explicitly what the client may expect
l B. Mayer (1988): When redefining a method in a derived (or inherited) class ¡ the precondition can be replaced only by a weaker one ¡ the postcondition can be replaced only by a stronger one
l A derived class should require no more and provide no less than the base class
![Page 67: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/67.jpg)
LSP: Simple Heuristic l Telltale signs of LSP violation:
¡ degenerate functions in derived classes (i.e. overriding a base-class method with a method that does nothing)
¡ throwing exceptions from derived classes l Solution 1: inverse the inheritance relation
¡ if the base class has only additional behaviour l Solution 2: extract common a base class
¡ if both initial and derived classes have different behaviors
¡ penguins → Bird, FlyingBird, Penguin l Sometimes it is not possible to edit the base class
¡ example: Java Collections Hierarchy
![Page 68: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/68.jpg)
Example: java.util.Collection public interface Collection<E> extends Iterable<E> { //-- Basic operations public int size(); public boolean isEmpty(); public boolean contains(Object o); public boolean add(E o); // Optional public boolean remove(Object o); // Optional public Iterator<E> iterator(); //-- Collection operations public boolean containsAll(Collection<?> c); public boolean addAll(Collection<? extends E> c); // Optional public boolean removeAll(Collection<?> c); // Optional public boolean retainAll(Collection<?> c); // Optional public void clear(); // Optional //-- Array operations public Object[] toArray(); public <T> T[] toArray(T[] a); }
![Page 69: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/69.jpg)
DIP: The Dependency-Inversion Principle
High-level modules should not depend on low-level modules. Both should depend on abstractions.
Abstractions should not depend on details. Details should depend on abstractions.
– Robert Martin
![Page 70: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/70.jpg)
DIP (cont’d) l Modules with detailed implementations are not
depended upon, but depend themselves upon abstractions
l High-level modules contain the important business model of the application, the policy ¡ independent of details ¡ should be the focus of reuse ¡ greatest benefits are achievable here
l Results from the rigorous use of LSP and OCP ¡ OCP states the goal ¡ LSP enables it ¡ DIP shows the mechanism to achieve the goal
![Page 71: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/71.jpg)
Example: Naïve Layering Scheme
Policy Layer
Mechanism Layer
Utility Layer
![Page 72: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/72.jpg)
Example: Inverted Layers
Policy Layer
Mechanism Layer
Policy
Mechanism
Utility
«interface» Policy Service Interface
«interface» Mechanism Service Interface
Utility Layer
![Page 73: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/73.jpg)
Design to an Interface l Rationale
¡ abstract classes/interfaces tend to change less frequently ¡ abstractions are ‘hinge points’ where it is easier to extend/modify ¡ no need to modify classes/interfaces that represent the abstraction
l All relationships should terminate to an abstract class or interface ¡ no variable should refer to a concrete class
l use inheritance to avoid direct bindings to concrete classes ¡ no class should derive from a concrete class
l concrete classes tend to be volatile ¡ no method should override an implemented method of any of its base
classes l Exceptions
¡ some classes are very unlikely to change → a little benefit in inserting an abstraction layer l you can depend on a concrete class that is not volatile (e.g. String
class) ¡ a module that creates objects automatically depends on them
![Page 74: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/74.jpg)
ISP: The Interface-Segregation Principle
l Many client-specific interfaces are better than one general purpose interface ¡ no ‘fat’ interfaces ¡ no non-cohesive interfaces
l Related to SRP
Clients should not be forced to depend upon methods that they do not use.
![Page 75: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/75.jpg)
Fat Interfaces l Fat interface = general purpose interface ≠
client-specific interface ¡ can cause bizarre couplings between its clients ¡ when one client forces a change, all other clients are
affected l Break a fat interface into many separate
interfaces ¡ targeted to a single client or a group of clients ¡ clients depend only on the methods they use (and not
on other clients’ needs) ¡ impact of changes to one interface are not as big ¡ probability of a change reduces ¡ no interface pollution
![Page 76: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/76.jpg)
Example: Door and Timer public class Door { public void lock() { /* implementation */ } public void unlock() { /* implementation */ } public boolean isOpen() { /* implementation */ } } public class Timer { public void register(int timeout, TimerClient client) { /* implementation */ } } public interface TimerClient { public void timeout(); }
![Page 77: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/77.jpg)
+timeout()
Example: Timer Client at Top of Hierarchy
Timer
Door
«interface» TimerClient
TimedDoor
0..*
![Page 78: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/78.jpg)
Example: Separation Through Delegation
+timeout()
Timer Door «interface» TimerClient
TimedDoor
0..*
DoorTimer Adapter +timeout() +doorTimeout()
«creates»
«registers»
![Page 79: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/79.jpg)
Example: Separation Through Multiple Inheritence
+timeout()
Timer Door «interface» TimerClient
TimedDoor
0..*
+timeout()
«registers»
![Page 80: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/80.jpg)
Role-Based Interface Design l Interfaces are designed from the viewpoint of the
service user, not the service provider ¡ clients own the interfaces
l Interfaces should represent roles that clients take when using the services of a class or component
l Classes implement many interfaces, interfaces are implemented by many classes ¡ example: flying birds (as well as bats) implement
interface FlyingCreature, but penguins do not l Version control by adding new interfaces for
clients requiring new services → less viscosity
![Page 81: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/81.jpg)
Five Principles (revisited)
1. Single-Responsibility Principle 2. Open–Closed Principle 3. Liskov Substitution Principle 4. Depency-Inversion Principle 5. Interface-Segregation Principle
![Page 82: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/82.jpg)
DESIGN PATTERNS
![Page 83: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/83.jpg)
Design Patterns: Background l Architectural design patterns
¡ Christopher Alexander et al.: A Pattern Language, 1977 ¡ Christopher Alexander: The Timeless Way of Building,
1979 l World consists of repeating instances of various
patterns ¡ a pattern is (possibly hidden) design know-how that
should be made explicit ¡ ‘a quality without name’: not measurable but
recognizable l User-centred design
¡ capture the quality in a pattern language ¡ inhabitants should design their own buildings together
with a professional using the patterns
![Page 84: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/84.jpg)
Alexander’s Patterns l What do high-quality contructs have in common? l Structures cannot be separated from the
problems they are solving l Similarities in the solution structures → a pattern l Each pattern defines subproblems solved by other
smaller patterns l A pattern is a rule that expresses a relation
between ¡ a context ¡ a problem and ¡ a solution
![Page 85: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/85.jpg)
Alexander’s Patterns (cont’d)
‘Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.’
– C. Alexander, The Timeless Way of Building, 1979
![Page 86: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/86.jpg)
Software Design Patterns ‘[Patterns] are descriptions
of communicating objects and classes that are customized to solve a general design problem in a particular context.’ ‘A design pattern names, abstracts, and identifies the key aspects of a common design structure that make it useful for creating a reusable object- oriented design.’
– E. Gamma (1995):
![Page 87: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/87.jpg)
Software Design Patterns (cont’d) l Reusable solutions to general design problems l Represent solutions to problems that arise when
developing software within a particular context ¡ design pattern = problem–solution pair in a context ¡ basic steps remain the same but the exact way of
applying a pattern is always different l Capture well-proven experience in software
development ¡ static and dynamic structure ¡ collaboration among the key participants
l Facilitate the reuse of successful software architectures and designs
![Page 88: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/88.jpg)
Definition of a Design Pattern
l Not specific to any language, environment etc. l Described as a semiformal document l Addresses a common problem l Can be applied at architecture or detailed design level l Appears in a context that defines certain requirements or
forces
A general solution to a frequently occurring architecture/design problem in a context.
![Page 89: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/89.jpg)
Motivation l Reusing the solutions
¡ learn from other good designs, not your own mistakes ¡ architectural building blocks for new designs
l Estabishing a common terminology ¡ communication and teamwork ¡ documenting the system
l Giving a higher-level perspective on the problem and the process of design and object orientation ¡ articulate the design rationale ¡ make hidden design knowledge explicit and available ¡ name and explicate higher-level structures which are
not directly supported by a programming language
![Page 90: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/90.jpg)
The ‘Gang-of-Four’ Design Patterns
l Gamma et al. describe and document 23 design patterns using a semi-formal procedure
l GoF patterns are ¡ not very problem-specific ¡ small and low-level patterns ¡ focusing on flexibility and reuse through decoupling of
classes l Underlying principles
¡ program to an interface, not to an implementation ¡ favour composition over inheritance ¡ find what varies and encapsulate it
![Page 91: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/91.jpg)
![Page 92: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/92.jpg)
Describing a Design Pattern Name Increases the design vocabulary
Intent The purpose of the pattern
Problem Description of the problem and its context, presumptions, example
Solution How the pattern provides a solution to the problem in the context in which it shows up
Participants The entities involved in the pattern
Consequences Benefits and drawbacks of applying the design pattern; investigates the forces at play in the pattern
Implementation Different choices in the implementation of the design pattern, possibly language-dependent
![Page 93: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/93.jpg)
Benefits of Design Patterns
l Patterns improve developer communication
l Patterns enhance understanding by documenting the architecture of a system
l Patterns enable large-scale reuse of software architectures
l Patterns do not provide solutions, they inspire solutions!
![Page 94: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/94.jpg)
Design Patterns – the Flip Side l Patterns are not without potential problems
¡ design fragmentation: more classes, more complicated dependencies
¡ overkilling problems ¡ excessive dynamic binding, potentional performance problem ¡ ‘object schitzophrenia’, splitting objects ¡ wrong design pattern can cause much harm
l Integrating patterns into a software development process is a human-intensive activity ¡ not a piece of ready-to-use code ¡ can be implemented in many ways ¡ not a general remedy to improve your system
l Patterns can be deceptively simple ¡ condensed and abstracted experience and wisdom
l Patterns are not written in stone! ¡ reject or modify them to suit your needs
![Page 95: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/95.jpg)
Design Patterns: Set 1
l COMMAND and ACTIVE OBJECT l TEMPLATE METHOD and STRATEGY l FACADE and MEDIATOR l SINGLETON and MONOSTATE l NULL OBJECT
![Page 96: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/96.jpg)
COMMAND
+do()
«interface» Command Sensor
RelayOn Command
RelayOff Command
MotorOn Command
MotorOff Command
ClutchOn Command
ClutchOff Command
![Page 97: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/97.jpg)
COMMAND (cont’d) l A function object; a
method wrapped in an object
l The method can be passed to other methods or objects as a parameter
l Decouples the object that invokes the operation from the one performing it ¡ physical and temporal
decoupling l Cf. java.lang.Runnable
+do() +undo()
«interface» Command
![Page 98: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/98.jpg)
ACTIVE OBJECT: Example public interface Command { public void execute(); } public class ActiveObjectEngine { private List<Command> commands = new LinkedList<Command>(); public void addCommand(Command c) { commands.add(c); } public void run() { while (!commands.isEmpty()) { Command c = commands.getFirst(); commands.remove(c); c.execute(); } } }
![Page 99: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/99.jpg)
TEMPLATE METHOD and STRATEGY
Application
+run() #init() #idle() #cleanup()
Implementation
#init() #idle() #cleanup()
Application Runner
«interface» Application
Strategy1 Strategy2 Strategy3
+init() +idle() +cleanup()
+run()
![Page 100: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/100.jpg)
TEMPLATE METHOD and STRATEGY (cont’d) l Defines the skeleton of an
algorithm ¡ some steps are deferred
to subclasses ¡ subclasses redefine the
steps without changing the overall structure
l Used prominently in frameworks
l Cf. java.applet.Applet, javax.swing.JApplet
l Defines a family of algorithms ¡ encapsulated,
interchangeable ¡ algorithm can vary
independently from clients that use it
l Identify the protocol that provides the level of abstraction, control, and interchangeability for the client → abstract base class
l All conditional code → concrete derived classes
![Page 101: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/101.jpg)
FACADE
+operation1() +operation2() …
Facade Client
Database
Connection Driver Manager Statement
ResultSet SQL Exception
Prepared Statement
![Page 102: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/102.jpg)
FACADE (cont’d) l A unified interface to a set of interfaces in
a subsystem ¡ encapsulates a complex subsystem within a
single interface object ¡ makes the subsystem easier to use
l Decouples the subsystem from its clients ¡ if it is the only access point, it limits the
features and flexibility l Imposes a policy ‘from above’
¡ everyone uses the facade instead the subsystem
¡ visible and constraining
![Page 103: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/103.jpg)
MEDIATOR l Imposes a policy ‘from
below’ ¡ hidden and
unconstraining l Promotes loose coupling
¡ objects do not have to refer to one another
¡ simplifies communication l Problem: monolithism l Example:
QuickEntryMediator ¡ binds text-entry field to a
list ¡ when text is entered, the
first element matching in the list is highlighted
«anonymous» Document Listener
QuickEntry Mediator
JList JTextField
![Page 104: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/104.jpg)
SINGLETON: Example public class Singleton {
private static Singleton
theInstance = null;
private Singleton() { /* nothing */ }
public static Singleton create() {
if (theInstance == null)
theInstance = new Singleton();
return theInstance;
} }
![Page 105: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/105.jpg)
MONOSTATE: Example public class Monostate<T> {
private static T itsValue = null;
public Monostate() { /* nothing */ }
public void set(T value) {
itsValue = value;
}
public T get() {
return itsValue;
} }
![Page 106: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/106.jpg)
Comparison
l SINGLETON ¡ applicable to any class ¡ lazy evaluation: if not used, not created ¡ not inherited: a derived class is not singleton ¡ can be created through derivation ¡ non-transparent: the user knows… ¡ cf. java.lang.Integer.MAX_VALUE, java.util.Collections.EMPTY_SET
l MONOSTATE ¡ inherited: a derived class is monostate ¡ polymorphism: methods can be overridden ¡ normal class cannot be converted through derivation ¡ transparent: the user does not need to know…
![Page 107: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/107.jpg)
NULL OBJECT
Application «interface» Employee
NullEmployee Employee Implementation
«creates»
«creates»
![Page 108: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/108.jpg)
NULL OBJECT: Example public interface Employee { public boolean isTimeToPay(Date payDate); public void pay(); public static final Employee NULL =
new Employee() { public boolean isTimeToPay(Date payDate) { return false; } public void pay() { /* nothing */ } }; }
![Page 109: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/109.jpg)
PACKAGE DESIGN
![Page 110: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/110.jpg)
Six Principles of Package Design
1. Reuse–Release Equivalence Principle
2. Common-Reuse Principle 3. Common-Closure Principle 4. Acyclic-Dependencies Principle 5. Stable-Dependencies Principle 6. Stable-Abstractions Principle
Coupling
Cohesion
![Page 111: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/111.jpg)
Package Cohesion and Coupling
l Cohesion within a package ¡ ‘bottom–up’ view of partitioning ¡ classes in a packages must have a good reason to be
there ¡ classes belong together according to some criteria
l political factors l dependencies between the packages l package responsibilities
l Coupling between packages ¡ dependencies accross package boundaries ¡ relationships between packages
l technical l political l volatile
![Page 112: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/112.jpg)
REP: The Reuse–Release Equivalence Principle
l Anything we reuse must also be released and tracked l Package author should guarantee
¡ maintanance ¡ notifications on future changes ¡ option for a user to refuse any new versions ¡ support for old versions for a time
The granule of reuse is the granule of release.
![Page 113: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/113.jpg)
REP (cont’d)
l Primary political issues ¡ software must be partitioned so that
humans find it convenient l Reusable package must contain
reusable classes ¡ either all the classes in a package are
reusable or none of them are l Reusable by the same audience
![Page 114: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/114.jpg)
CRP: The Common-Reuse Principle
The classes in a package are reused together.
If you reuse one of the classes in a package, you reuse them all.
![Page 115: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/115.jpg)
CRP (cont’d) l If one class in a package uses another package,
there is a dependency between the packages ¡ whenever the used package is released, the using
package must be revalidated and re-released ¡ when you depend on a package, you depend on every
class in that package! l Classes that are tightly bound with class
relationships should be in the same package ¡ these classes typically have tight coupling ¡ example: container class and its iterators
l The classes in the same package should be inseparable – impossible to reuse one without another
![Page 116: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/116.jpg)
CCP: The Common-Closure Principle
The classes in a package should be closed together against the same kind of changes.
A change that affects a closed package affects all the classes in that package and no other packages.
![Page 117: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/117.jpg)
CCP (cont’d) l SRP restated for packages
¡ a package should not have multiple reason to change l Maintainability often more important than
reusability ¡ changes should occur all in one package ¡ minimizes workload related releasing, revalidating and
redistributing l Closely related to OCP
¡ strategic closure: close against types of changes that are probable
¡ CCP guides to group together classes that are open to the same type of change
![Page 118: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/118.jpg)
Recap: Cohesion
l Reuse–Release Equivalence Principle ¡ partition so that it is convenient to the
users of the package l Common-Reuse Principle
¡ partition so that the classes are tightly bound together
l Common-Closure Principle ¡ partition so that a change is limited to
one package only
![Page 119: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/119.jpg)
ADP: The Acyclic-Dependencies Principle
l Without cycles it is easy to compile, test and release ‘bottom-up’ when building the whole software
l The packages in a cycle will become de facto a single package ¡ compile-times increase ¡ testing becomes difficult since a complete build is needed to test a
single package ¡ developers can step over one another since they must be using
exactly the same release of each other’s packages
Allow no cycles in the package dependency graph.
![Page 120: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/120.jpg)
The ‘Morning-After Syndrome’ l Developers are modifying the same source files
trying to make it work with the latest changes somebody else did → no stable version
l Solution #1: the weekly build ¡ developers work alone most of the week and integrate
on Friday ¡ works on medium-sized projects ¡ for bigger projects, the iteration gets longer (monthly
build?) → rapid feedback is lost l Solution #2:
¡ partition the development environment into releasable packages
¡ ensure ADP
![Page 121: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/121.jpg)
Release-Control l Partition the development environment into releasable
packages ¡ package = unit of work ¡ developer modifies the package privately ¡ developer releases the working package ¡ everyone else uses the released package while the developer
can continue modifying it privately for the next release l No developer is at the mercy of the others
¡ everyone works independently on their own packages ¡ everyone can decide independently when to adapt the
packages to new releases of the packages they use ¡ no ‘big bang’ integration but small increments
l To avoid the ‘morning-after syndrome’ the dependency tree must not have any cycles
![Page 122: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/122.jpg)
Package Structure as a Directed Acyclic Graph
MyApplication
Message Window
Task Window MyTasks
Database
Tasks MyDialogs
Windows
![Page 123: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/123.jpg)
Breaking the Cycle with DIP
MyApplication
Y
MyDialogs
X
MyApplication
Y
MyDialogs
X «interface» X Server
![Page 124: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/124.jpg)
Breaking the Cycle with a New Package
MyApplication
Message Window
Task Window MyTasks
Database
Tasks MyDialogs
Windows NewPackage
![Page 125: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/125.jpg)
Breaking the Cycle – a Corollary
l The package structure cannot be designed top–down but it evolves as the system grows and changes
l Package depency diagrams are not about the function of the application but they are a map to the buildability of the application
![Page 126: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/126.jpg)
SDP: The Stable-Dependencies Principle
l Designs cannot be completely static ¡ some volatility is required so that the design can be maintained ¡ CCP: some packages are sensitive to certain types of changes
l A volatile package should not be depended on by a package that is difficult to change ¡ a package designed to be easy to change can (accidentally)
become hard to change by someone else hanging a dependency on it!
Depend in the direction of stability.
![Page 127: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/127.jpg)
Stable and Instable Packages
l ‘Stable’ = not easy to change ¡ how much effort is needed to change a package: size,
complexity, clarity, incoming dependencies l If other packages depend on a package, it is hard
to change (i.e. stable)
X
Y
![Page 128: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/128.jpg)
Stability Metrics
l Affarent couplings Ca ¡ the number of classes
outside this package that depend on classes within this package
l Efferent couplings Ce ¡ the number of classes
inside this package that depend on classes outside this package
l Instability I ¡ I = Ce / (Ca + Ce) ¡ I = 0: maximally
stable package ¡ I = 1: maximally
instable package l Dependencies
¡ C++: #include ¡ Java: import, qualified
names
![Page 129: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/129.jpg)
SDP
l The I metric of a package should be larger than the I metrics of the packages that depends on
Stable
Instable Instable Instable
I = 1 I = 1 I = 1
I = 0
Flexible
I > 0
![Page 130: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/130.jpg)
Fixing the Stability Violation Using DIP
Flexible
C
Stable
U
Flexible
C
Stable
U «interface» IU
UInterface
![Page 131: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/131.jpg)
SAP: The Stable-Abstractions Principle
l A stable package should be abstract so that stability does not prevent it from being extended
l An instable package should be concrete since the instability allows the concrete code to be changed easily
l SDP + SAP = DIP for packages ¡ dependencies run in the direction of abstractions
l Since packages have varying degrees of abstractness, we need a metric to measure the abstractness of a package
A package should be as abstract as it is stable.
![Page 132: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/132.jpg)
Measuring Abstractness
l The number of classes in the package Nc
l The number of abstract classes in the package Na ¡ abstract class = at least one pure interface and
cannot be instantiated l Abstractness A
¡ A = Na / Nc
¡ A = 0: no abstract classes ¡ A = 1: only abstract classes
![Page 133: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/133.jpg)
The Abstractness–Instability Graph
A
I
(0,1) (1,1)
(1,0) (0,0)
![Page 134: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/134.jpg)
Recap: Package Cohesion and Coupling l REP, CRP, and CCP: cohesion within a package
¡ ‘bottom–up’ view of partitioning ¡ classes in a packages must have a good reason to be
there ¡ classes belong together according to some criteria
l political factors l dependencies between the packages l package responsibilities
l ADP, SDP, and SAP: coupling between packages ¡ dependencies accross package boundaries ¡ relationships between packages
l technical l political l volatile
![Page 135: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/135.jpg)
FACTORY
l DIP: prefer dependencies on abstract classes ¡ avoid dependencies on concrete (and volatile!)
classes ¡ any line of code that uses the new keyword
violates DIP: Circle c = new Circle(origin, 1);
¡ the more likely a concrete class is to change, the more likely depending on it will lead to trouble
l How to create instances of concrete objects while depending only on abstract interfaces → FACTORY
![Page 136: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/136.jpg)
Example: Creating Shapes Violates DIP
Application
«interface» Shape
Square Circle
«creates»
![Page 137: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/137.jpg)
Example: Shapes Using FACTORY
+makeSquare() +makeCircle()
«interface» ShapeFactory
Application
ShapeFactory Implementation
«interface» Shape
Square Circle
«creates»
![Page 138: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/138.jpg)
Example: Removing the Dependency Cycle public interface ShapeFactory { public Shape make(Class<? extends Shape> t); } public class ShapeFactoryImplementation
implements ShapeFactory { public Shape make(Class<? extends Shape> t) { if (t == Circle.class) return new Circle(); else if (t == Square.class) return new Square(); throw new Error(); } } ShapeFactory sf = new ShapeFactoryImplementation(); Shape s1 = sf.make(Circle.class); Shape s2 = sf.make(Square.class);
![Page 139: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/139.jpg)
Benefits of FACTORY
l Implementations can be substituted easily l Allows testing by spoofing the actual
implementation
«interface» ShapeFactory
Application
ShapeFactory Implementation 2
«interface» Shape
Square
Circle «creates»
ShapeFactory Implementation 1
ShapeFactory Implementation 3
«creates»
«creates»
![Page 140: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/140.jpg)
FACTORY – the Flip Side
l Factory is a powerful abstraction ¡ strictly thinking DIP entails that you
should use factories for every volatile class
l Do not start out using factories ¡ can cause unnecessary complexity ¡ add them when the need becomes great
enough
![Page 141: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/141.jpg)
Design Patterns: Set 2
l COMPOSITE l OBSERVER l ABSTRACT SERVER l ADAPTER l BRIDGE l PROXY l STAIRWAY TO HEAVEN
![Page 142: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/142.jpg)
COMPOSITE
«interface» Shape
Square
Circle
+draw()
+add(Shape) +draw()
Composite Shape
0..*
«delegates»
![Page 143: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/143.jpg)
COMPOSITE and COMMAND
l Sensor and Command: one-to-one association l COMPOSITE provides a way to have one-to-many
behaviour without one-to-many association ¡ list management and iteration appears only once in
the composite class l Cf. java.awt.geom.GeneralPath
Sensor Command
Composite Command
0..*
![Page 144: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/144.jpg)
OBSERVER
l Service call can be seen as a global event to which the related modules can react ¡ creator and handler(s) of the event do not have to know
one another → no direct dependency l Define an object keeps the data model (Subject) l Delegate all ‘view’ functionality to decoupled and
distinct Observer objects ¡ register to Subject at creation
l When Subject changes, it notifies all registered Observers ¡ Observer can query Subject for the data that it is
responsible for monitoring l The number and type of Observers can be
configured dynamically at run time
![Page 145: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/145.jpg)
Synchronous Event-Handling
a = 50% b = 30% c = 20%
a b c
x 60 30 10
y 50 30 20
z 80 10 10
Subject
a b c
Observers
change notifications
requests, modifications
![Page 146: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/146.jpg)
OBSERVER: Pull Model
«interface» Observer
+update() +register(Observer) +unregister(Observer) #notify()
Subject 0..*
+update()
Concrete Observer
+getState() +setState()
Concrete Subject
«observes»
«registers»
![Page 147: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/147.jpg)
OBSERVER: Push Model
Observer
+update(Message) +register(Observer) +unregister(Observer) +notify(Message)
Subject 0..*
Concrete Observer
+getState() +setState()
Concrete Subject
«observes»
«registers»
![Page 148: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/148.jpg)
Features l Use Observer when
¡ an abstraction has two aspects, one dependent on the other
¡ a change to one object requires changing others, and you do not know how many objects need to be changed
¡ an object should be able to notify other objects without assumptions about these objects
l Observer is a widely used pattern: once you understand it, you see uses for it everywhere ¡ you can register observers with all kinds of objects
rather than writing those objects to explicitly call you l Cf.
¡ java.awt.event.ActionListener ¡ java.util.Observer and java.util.Observable
![Page 149: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/149.jpg)
ABSTRACT SERVER – A Motivating Example l Design software for
a simple table lamp ¡ switch: on/off ¡ light: on/off
l The simple design violates ¡ DIP ¡ OCP
Switch
+turnOn() +turnOff()
Light
![Page 150: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/150.jpg)
Example: A Bad Way to Extend Switch
Switch
+turnOn() +turnOff()
Light
FanSwitch
+turnOn() +turnOff()
Fan
![Page 151: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/151.jpg)
Example: Extending Switch with ABSTRACT SERVER
«interface» Switchable Switch
+turnOn() +turnOff()
Light
+turnOn() +turnOff()
+turnOn() +turnOff()
Fan
![Page 152: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/152.jpg)
Who Owns the Interface?
l Interfaces belong to the client, not to the derivative ¡ Switch cannot be deployed without Switchable ¡ Switchable can deployed without Light
l Inheritance hierarchies usually should not be packaged together ¡ package clients with the interfaces they control
l Cf. ¡ java.io.Closeable, java.io.Flushable ¡ javax.swing.table.TableModel
![Page 153: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/153.jpg)
ADAPTER
l Potential SRP violation in ABSTRACT SERVER: ¡ Light and Switchable may not change
for the same reasons ¡ what if Light cannot be inherited?
l Solution: add a class that can be adapted to the interface ¡ drawback: extra classes, instantations
![Page 154: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/154.jpg)
Example: Object-Form Adapter
«interface» Switchable Switch
+turnOn() +turnOff()
Light Adapter
+turnOn() +turnOff()
+turnOn() +turnOff()
Light «delegates»
![Page 155: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/155.jpg)
Example: Class-Form Adapter
«interface» Switchable Switch
+turnOn() +turnOff()
Light Adapter
+turnOn() +turnOff()
+turnOn() +turnOff()
Light
![Page 156: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/156.jpg)
BRIDGE – A Motivating Example l Modelling animal characteristics
¡ each type of animal can have different number of legs (integer) ¡ each type of animal can have different type of movement: fly, walk or
crawl ¡ an animal must be able to return the number of legs when asked ¡ an animal must be able to calculate how long it would take to move a
distance given the type of terrain l Variation in number of legs: a member variable with get/set
methods l Variation in movement type:
¡ a member variable to indicate the type and to select different code for movement l tight coupling, messy code
¡ animal types are derived from a base class l need to manage subtypes of animals l no animals with more than one type of movement l subtyping based on one property; what about classifying them as
mammals, reptiles and birds?
![Page 157: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/157.jpg)
Example: Bridging Two Hierarchies
l Encapsulate the behaviour (i.e. movement) into a class
l The animal class contains an object that has the appropriate behaviour
Animal
Bird Reptile Mammal
«delegates» Movement
Fly Walk Crawl
+move()
![Page 158: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/158.jpg)
Commonality and Variability l Commonality analysis
¡ what are the common elements among the elements ¡ define a family to which the elements belong and a
context where things vary ¡ find the structure that is unlikely to change over time
l Variability analysis ¡ how things vary within the context of commonality
(variability only makes sense within a given commonality)
¡ find the structure that is likely to change l Shortly: When the type hierarchy has more than
one degree of freedom ¡ separate the hierarchies ¡ tie them together with a bridge
![Page 159: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/159.jpg)
PROXY
l Allows to cross a barrier without either of the participants knowing about it ¡ database ¡ network
l Theory: PROXY can be inserted in between two collaborating objects without them knowing about it
l Reality: not so trivial…
![Page 160: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/160.jpg)
Example: Web Shopping Cart
Order Customer
-quantity
Item
-date -status
-name -price -sku
Product
0..*
-name -address -billingInfo
0..*
![Page 161: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/161.jpg)
Example: Order Proxy
l Interface that declares all the methods that clients need to invoke
l Class that implements those methods without knowledge of the database
l Proxy that knows about the database
«interface» Order
DB Order DB Proxy
Order Implementation
«delegates»
![Page 162: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/162.jpg)
Example: Order Proxy (cont’d) public interface Order { public String getCustomerId(); public void addItem(Product p, int quantity); public int total(); } public class OrderImp implements Order { private List<Item> itsItems; public int total() { int total = 0; for (Item item : itsItems) total += item.getProduct().getPrice() * item.getQuantity(); return total; } /* rest of the implementation omitted */ }
![Page 163: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/163.jpg)
Example: Order Proxy (cont’d) public class OrderProxy implements Order { public int total() { OrderImp imp = new OrderImp(getCustomerId()); ItemData[] itemDataArray =
DB.getItemsForOrder(orderId); for (ItemData item : itemDataArray) imp.addItem(new ProductProxy(item.sku), item.qty); return imp.total(); } /* rest of the implementation omitted */ }
![Page 164: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/164.jpg)
STAIRWAY TO HEAVEN
l Achieves dependency inversion (like PROXY)
l Employs a variation on the class form of ADAPTER
l Only useful in languages supporting multiple inheritence
l Completely seperates knowledge of the database away from the business rules of the application
![Page 165: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/165.jpg)
STAIRWAY TO HEAVEN (cont’d)
Persistent Object
Product
Assembly
+write() +read()
Persistent Assembly
Persistent Product
![Page 166: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/166.jpg)
Design Patterns: Set 3
l The VISITOR family ¡ VISITOR ¡ ACYCLIC VISITOR
¡ DECORATOR ¡ EXTENSION OBJECT
l STATE
![Page 167: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/167.jpg)
VISITOR
l The VISITOR family allows new methods to be added to existing hierarchies without modifying the hierarchies
l Every derivative of the visited hierarchy has a method in VISITOR
l Dual dispatch: two polymorphic dispatches
![Page 168: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/168.jpg)
Example: Modem Hierarchy
«interface» Modem
+dial() +send() +hangup() +receive()
Hayes Zoom Ernie
![Page 169: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/169.jpg)
Example: Modem Hierarchy (cont’d)
«interface» Modem
+dial() +send() +hangup() +receive() +accept(ModemVisitor)
Hayes Zoom Ernie
«interface» ModemVisitor
+visit(Hayes) +visit(Zoom) +visit(Ernie)
UnixModem Configurator
WindowsModem Configurator
![Page 170: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/170.jpg)
Example: Modem Hierarchy (cont’d)
public interface Modem { public void dial(String pno); public void hangup(); public void send(char c); public char receive(); public void accept(ModemVisitor v); } public interface ModemVisitor { public void visit(HayesModem modem); public void visit(ZoomModem modem); public void visit(ErnieModem modem); }
![Page 171: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/171.jpg)
Example: Modem Hierarchy (cont’d) public class HayesModem implements Modem { public void accept(ModemVisitor v) { v.visit(this); } /* rest of the implementation omitted */ } public class UnixModemConfigurator implements ModemVisitor { public void visit(HayesModem m) { m.setConfigurationString("&s1=4&D=3"); } public void visit(ZoomModem m) { m.setConfigurationValue(42); } public void visit(ErnieModem m) { m.setInternalPattern("C is too slow"); } }
![Page 172: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/172.jpg)
Example: Modem Hierarchy (cont’d)
l To configure a modem for Unix, create an instance of the visitor and pass it to accept
l The appropriate derivative calls visit(this)
l New OS configuration can be added by adding a new derivative of the visitor
![Page 173: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/173.jpg)
VISITOR as a Matrix
Unix Windows
Hayes Initialization of Hayes in Unix
Initialization of Hayes in Windows
Zoom Initialization of Zoom in Unix
Initialization of Zoom in Windows
Ernie Initialization of Ernie in Unix
Initialization of Ernie in Windows
![Page 174: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/174.jpg)
Observations l In VISITOR
¡ the visited hierarchy depends on the base class of the visitor hierarchy
¡ the base class of the visitor hierarchy has a function for each derivative of the visited hierarchy
l A cycle of dependencies ties all the visited derivatives together ¡ difficult to compile incrementally ¡ difficult to add new derivatives of visited hierarchy
l Visitor work well if the hierarchy is not modified often
![Page 175: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/175.jpg)
ACYCLIC VISITOR
l For a volatile hierarchy ¡ new derivatives are created ¡ quick compilation time is needed
l ACYCLIC VISITOR breaks the dependency cycle by making the visitor base class degenerate (i.e. it has no methods)
![Page 176: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/176.jpg)
Example: Modem Hierarchy «interface» Modem +dial() +send() +hangup() +receive() +accept(ModemVisitor)
Hayes Zoom Ernie
«degenerate» ModemVisitor
«interface» HayesVisitor +visit(Hayes)
«interface» ZoomVisitor +visit(Zoom)
«interface» ErnieVisitor +visit(Ernie)
UnixModem Configurator
![Page 177: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/177.jpg)
Example: Modem Hierarcy (cont’d)
public interface Modem {
public void dial(String pno);
public void hangup();
public void send(char c);
public char receive();
public void accept(ModemVisitor v);
}
public interface ModemVisitor {
}
![Page 178: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/178.jpg)
Example: Modem Hierarchy (cont’d)
public interface ErnieModemVisitor { public void visit(ErnieModem m); } public class ErnieModem implements Modem { public void accept(ModemVisitor v) { try { ErnieModemVisitor ev =
(ErnieModemVisitor)v; ev.visit(this); } catch (ClassCastException e) { } } /* rest of the implementation omitted */ }
![Page 179: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/179.jpg)
Example: Modem Hierarchy (cont’d)
public class UnixModemConfigurator implements ModemVisitor, HayesVisitor, ZoomVisitor,
ErnieVisitor { public void visit(HayesModem m) { m.setConfigurationString("&s1=4&D=3"); } public void visit(ZoomModem m) { m.setConfigurationValue(42); } public void visit(ErnieModem m) { m.setInternalPattern("C is too slow"); } }
![Page 180: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/180.jpg)
Observations
l Breaking the dependency cycle ⇒ ¡ easier to add visited derivatives ¡ solution is much more complex ¡ timing of the type casting is hard to
characterize l ACYCLIC VISITOR is like a sparse
matrix ¡ visitor classes do no have to implement
visit functions for all visited derivatives
![Page 181: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/181.jpg)
DECORATOR
l Allows attaching additional responsibilities to an object dynamically (i.e. at runtime)
l Provides a flexible alternative to subclassing for extending functionality
l Allows adding responsibilities to an object without adding methods to its interface
![Page 182: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/182.jpg)
Example: Loud Dial Modem
«interface» Modem
+dial(…) +setVolume(int)
HayesModem
ZoomModem
ErnieModem
LoudDial Modem
«delegates»
itsModem
public void dial(…) { itsModem.setVolume(11); itsModem.dial(…); }
![Page 183: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/183.jpg)
Example: Loud Dial Modem (cont’d) public interface Modem { public void dial String(pno); public void setSpeakerVolume(int volume); } public class HayesModem implements Modem { private String itsPhoneNumber; private int itsSpeakerVolume; public void dial(String pno) { itsPhoneNumber = pno; } public void setSpeakerVolume(int volume) { itsSpeakerVolume = volume; } }
![Page 184: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/184.jpg)
Example: Loud Dial Modem (cont’d) public class LoudDialModem implements Modem { private Modem itsModem; public LoudDialModem(Modem m) { itsModem = m; } public void dial(String pno) { itsModem.setSpeakerVolume(11); itsModem.dial(pno); } public void setSpeakerVolume(int volume) { itsModem.setSpeakerVolume(volume); } }
![Page 185: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/185.jpg)
Observations
l Multiple decorators: base class decorator ¡ supplies the delegation code ¡ actual decorators derive from the base class
and override only those methods they need l Cf.
¡ Java I/O streams: BufferedReader keyboard = new BufferedReader( new InputStreamReader(System.in));
¡ javax.swing.JScrollPane
![Page 186: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/186.jpg)
EXTENSION OBJECT
l More complex than VISITOR but more powerful
l Each object in the hierarchy ¡ maintains a list of special extension objects ¡ provides a method that allows the extension
object to be looked up by name l Extension object provides methods that
manipulate the original hierarchy object
![Page 187: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/187.jpg)
Example: Bill-of-Materials
Part
Assembly
+getExtension(String) +addExtension(String,
PartExtension)
«marker» PartExtension
«marker» BadPartExtension
PiecePart
0..* «interface» XMLPartExtension
+getXMLElement()
XMLAssembly Extension
XMLPiecePart Extension
«interface» CSVPartExtension
+getCSV()
CSVAssembly Extension
CSVPiecePart Extension
0..*
![Page 188: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/188.jpg)
STATE
l Allows an object to alter its behaviour when its internal state changes ¡ the object will appear to change its class
l Typically used to change the behaviour according to a state transition diagram
l Other implementations for an FSM ¡ nested switch/case statement ¡ transition table
![Page 189: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/189.jpg)
Example: Turnstile FSM
Locked
Unlocked
coin/unlock
pass/lock
pass/alarm
coin/thankyou
![Page 190: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/190.jpg)
Example: Turnstile
Turnstile
+coin() +pass() #lock() #unlock() #thankyou() #alarm()
«interface» TurnstileState
+coin(Turnstile) +pass(Turnstile)
Turnstile LockedState
Turnstile UnlockedState
![Page 191: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/191.jpg)
Example: Turnstile (cont’d) public interface TurnstileState { public void coin(Turnstile t); public void pass(Turnstile t); } public class LockedTurnstileState implements TurnstileState { public void coin(Turnstile t) { t.setUnlocked(); t.unlock(); } public void pass(Turnstile t) { t.alarm(); } } public class UnlockedTurnstileState implements TurnstileState { public void coin(Turnstile t) { t.thankyou(); } public void pass(Turnstile t) { t.setLocked(); t.lock(); } }
![Page 192: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/192.jpg)
Example: Turnstile (cont’d) public class Turnstile { private static TurnstileState lockedState = new LockedTurnstileState(); private static TurnstileState unlockedState = new UnlockedTurnstileState(); private TurnstileController turnstileController; private TurnstileState state = lockedState; public Turnstile(TurnstileController action) { turnstileController = action; } public void coin() { state.coin(this); } public void pass() { state.pass(this); } public void setLocked() { state = lockedState; } public void setUnLocked() { state = unlockedState; } public boolean isLocked() { return state == lockedState; } public boolean isUnlocked() { return state == unlockedState; } protected void thankyou() { turnstileController.thankyou(); } protected void alarm() { turnstileController.alarm(); } protected void lock() { turnstileController.lock(); } protected void unlock() { turnstileController.unlock(); } }
![Page 193: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/193.jpg)
STATE vs. STRATEGY
l Common ¡ context class ¡ delegation to a polymorphic base class that
has several derivatives l Difference
¡ STATE: derivatives hold a reference back to the context class
¡ STRATEGY: no such constraint or intent l All instances of STATE are also instances of
STRATEGY
![Page 194: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/194.jpg)
Observations l Very strong separation between actions and the
logic of state machine ¡ action in the context class ¡ logic distributed through the derivatives of the state
class l Simple to change one without affecting the other
¡ reuse the context class with different state logic ¡ create subclasses of context class that modify the action
without affecting the logic l Costs
¡ writing state derivatives is tedious ¡ the logic is distributed, no single place to see it all
![Page 195: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/195.jpg)
RECAPITULATION AND CONCLUSIONS
![Page 196: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/196.jpg)
Null Object
State
Strategy
Template Method
Factory Monostate
Singleton Facade
Mediator Observer
Acyclic Visitor
Extension Object
Decorator
Visitor
Composite Active Object
Command
Abstract Server
Bridge Adapter Stairway to Heaven
Proxy
Factory Method Prototype
Flyweight
Interpreter
Iterator
Memento Builder
Chain of Responsibility
Design Patterns (revisited)
![Page 197: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/197.jpg)
Design Principles (revisited)
1. Single-Responsibility Principle 2. Open–Closed Principle 3. Liskov Substitution Principle 4. Depency-Inversion Principle 5. Interface-Segregation Principle
![Page 198: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/198.jpg)
Principles, Patterns, and Practices
System
Context
Theory
Practice
Principles Patterns
Abstraction of practices
research, experience
Forces
needs
concretization
motivation, synthesis
know-how
![Page 199: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/199.jpg)
Examinations
l Electronic examination ¡ opens May 6, 2013 ¡ closes September 30, 2013
l You can take the examination at most three (3) times
l For instructions and examination time reservations, see https://tenttis.utu.fi/
![Page 200: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/200.jpg)
Assessment
l Examination: 18 points l Voluntary exercise work: 2 bonus
points l Grading (based on 18 points):
¡ points: [9, 10] ⇒ grade: 1 ¡ points: (10, 12] ⇒ grade: 2 ¡ points: (12, 14] ⇒ grade: 3 ¡ points: (14, 16] ⇒ grade: 4 ¡ points: (16, 20] ⇒ grade: 5
![Page 201: Designing Object Oriented Software - lecture slides 2013](https://reader035.vdocuments.mx/reader035/viewer/2022081813/554bd699b4c905ac708b4fbf/html5/thumbnails/201.jpg)
Fin.