object-oriented designe

8/13/2019 Object-Oriented Designe

1/29

Object-Oriented Design


2/29

Copyright 2009 Esko Luontola 2

You know the software is rotting when itstarts to exhibit any of the following odors

Rigidity The system is hard to change because every changeforces many other changes to other parts of the system

Fragility !hanges cause the system to break in places thathave no conceptual relationship to the part that was changed

Immobility "t is hard to disentangle the system intocomponents that can be reused in the other systems

Viscosity Doing things right is harder than doing things wrong

Needless Complexity The design contains infrastructure that

adds no direct benefit Needless Repetition The design contains repeating

structures that could be unified under a single abstraction

Opacity "t is hard to read and understand "t does not express

its intent wellAgile Software Development: Principles, Patterns, and Practicesch# p$$


3/29


%imple Design

&xtreme 'rogramming(s principle of Simple Design) inorder of importance*

+ ,uns all the tests

!ontains no duplication

. &xpresses the intent of the programmer/ 0inimi1es the number of classes and methods

Truly agile teams don(t allow the software to rot 2eeping the design clean and simple at all timesis the only way to

go fast "t makes the design flexible and easy to change 0aking a mess will always slow you down the next time that you

need to read or change the same code

Clean Codech+Extreme Programming Explained (1st Ed.)ch+3 p4#

http*55xprogrammingcom5xpmag5exp&mergentDesignAgile Software Development: Principles, Patterns, and Practicesch# p63
http://xprogramming.com/xpmag/expEmergentDesignhttp://xprogramming.com/xpmag/expEmergentDesignhttp://xprogramming.com/xpmag/expEmergentDesign


4/29


7rchitecture87rchitecture is about the important stuff 9hatever that is8

:7rchitecture is the decisions that you wish you could get right early ina project; 9hy do people feel the need to get some things right early inthe project< The answer) of course) is because they perceive thosethings as hard to change %o you might end up defining architecture as:things that people perceive as hard to change;

=ig Design >p ?ront @=D>?A) ie spinning system designs based onuntested hypotheses for many months) is harmful =D>? inhibitsadapting to change

Bittle5&nough Design >p ?ront @BD>?5&D>?A is good 9ith a bigproject spending a week or even a month thinking about the importantthings is nothing wrong

7gile was a response to =D>?) but not D>? ?ar from :designnothing); the C' strategy is :design always;

9hatever designs have been done up front) they should always beopen for change Bet the tests drive the system architecture

http*55wwwibmcom5developerworks5java5library5j-eaed+5

http*55martinfowlercom5ieee%oftware5whoeeds7rchitectpdfClean Codech++ p+EEhttp*55blogobjectmentorcom5articles533653/545the-scatology-of-agile-architecture

FF
http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdfhttp://www.ibm.com/developerworks/java/library/j-eaed1/http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdfhttp://blog.objectmentor.com/articles/2009/04/25/the-scatology-of-agile-architecturehttp://blog.objectmentor.com/articles/2009/04/25/the-scatology-of-agile-architecturehttp://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdfhttp://www.ibm.com/developerworks/java/library/j-eaed1/


5/29


'rinciples of 0odular Design

Cohesion higher is better

!ohesion is a measure of how strongly-related or focusedthe responsibilities of a single module are

Coupling lower is better

!oupling or dependency is the degree to which eachprogram module relies on each one of the other modules

http*55enwikipediaorg5wiki5!ohesionG@computerGscienceAhttp*55enwikipediaorg5wiki5!ouplingG@computerGscienceA

Clean Codech+3 p+/3http*55reborgtumblrcom5post5$.E$4+5clean-code-cheat-sheet
http://en.wikipedia.org/wiki/Cohesion_(computer_science)http://en.wikipedia.org/wiki/Coupling_(computer_science)http://reborg.tumblr.com/post/82362851/clean-code-cheat-sheethttp://reborg.tumblr.com/post/82362851/clean-code-cheat-sheethttp://en.wikipedia.org/wiki/Coupling_(computer_science)http://en.wikipedia.org/wiki/Cohesion_(computer_science)


6/29


'rinciples of Object-Oriented Design

http*55wwwinfoHcom5presentations5principles-agile-oo-design @.3 minA
http://www.infoq.com/presentations/principles-agile-oo-designhttp://www.infoq.com/presentations/principles-agile-oo-designhttp://www.infoq.com/presentations/principles-agile-oo-design


7/29


http*55wwwlostechiescom5blogs5derickbailey5archive5336535++5solid-development-principles-in-motivational-picturesaspxhttp*55wwwglobalnerdycom533653#5+45the-solid-principles-explained-with-motivational-posters5
http://www.lostechies.com/blogs/derickbailey/archive/2009/02/11/solid-development-principles-in-motivational-pictures.aspxhttp://www.globalnerdy.com/2009/07/15/the-solid-principles-explained-with-motivational-posters/http://www.globalnerdy.com/2009/07/15/the-solid-principles-explained-with-motivational-posters/http://www.lostechies.com/blogs/derickbailey/archive/2009/02/11/solid-development-principles-in-motivational-pictures.aspx


8/29


%OB"D 'rinciples

%,'* %ingle ,esponsibility 'rinciple

O!'* Open !losed 'rinciple

B%'* Biskov %ubstitution 'rinciple

"%'* "nterface %egregation 'rinciple D"'* Dependency "nversion 'rinciple

http*55butunclebobcom57rticle%>ncle=ob'rinciplesOfOodhttp*55wwwhanselminutescom5defaultaspx


9/29


10/29


%ingle ,esponsibility 'rinciple

A class so!ld ave onl" one reason to cange.

&ach responsibility should be separated to its own class)because each responsibility is an axis of change !hangeto one responsibility may break others in the same class

?ollowing the %,' leads to small) highly focused) cohesiveclasses) which each do only one thing &ach of them willbe easy understand and change &xample* "n a payroll application) it(s wrong to have an &mployee

class which @+A calculates pay) @A produces a report) and @.Asaves itself to database &ach of them should be separated intoits own class* &mployee'ay!alculator) &mployee'ayroll,eport)&mployee,epository

http*55wwwobjectmentorcom5resources5articles5srppdf

Agile Software Development: Principles, Patterns, and Practicesch$ p64Clean Codech+3 p+$
http://www.objectmentor.com/resources/articles/srp.pdfhttp://www.objectmentor.com/resources/articles/srp.pdf


11/29




12/29


Open !losed 'rinciple

Software entities (classes, mod!les, f!nctions, etc.)so!ld #e open for extension, #!t closed for modification.

0ake classes depend on abstract interfaces instead ofconcrete classes "nject new behaviour into existingclasses by providing a different implementation of theinterface

9hen the O!' is applied well) new behaviour can beadded by creating a new class) without needing to change

existing classes =reaking existing code will be avoided ,ealistically will not always be possible) but we can try to

approximate it by anticipating what will change

http*55wwwobjectmentorcom5resources5articles5ocppdfAgile Software Development: Principles, Patterns, and Practicesch6 p66
http://www.objectmentor.com/resources/articles/ocp.pdfhttp://www.objectmentor.com/resources/articles/ocp.pdfhttp://www.objectmentor.com/resources/articles/ocp.pdf


13/29


7nticipating ?uture !hanges

8%ince closure cannot be complete) it must be strategicThat is) the designer must choose the kinds of changesagainst which to close his design Je must guess at themost likely kinds of changes) and then construct

abstractions to protect him from those changes8 87lso) conforming to the O!' is expensive."t takes

development time and effortto create the appropriateabstractions Those abstractions also increase thecomplexityof the software design8

Agile Software Development: Principles, Patterns, and Practicesch6 p+34


14/29


7nticipating ?uture !hanges

Do notput hooks in for changes that migthappen"nstead) wait !ntil te canges appen$

%&ool me once, same on "o!. &ool me twice, same on me.%

"nitially write the code expecting it to not change 9hen achange occurs) implement the abstractions that protectfrom future changes of tat 'ind.

"t(s better to take the first hit as early as possible 9e wantto know what kind of changes are likely before going too

far in the development >se TDD and listen to the tests Develop in short cycles

Develop features before infrastructure Develop the mostimportant features first ,elease early and often

Agile Software Development: Principles, Patterns, and Practicesch6 p+34


15/29




16/29


Biskov %ubstitution 'rinciple

S!#t"pes m!st #e s!#stit!ta#le for teir #ase t"pes. &!nctions tat !se references to #ase classes m!st #ea#le to !se o#ects of derived classes wito!t 'nowing it.

The rule which must be followed when inheriting fromanother class5interface

7ll assumptions that functions make about the base class)must be valid for all derived classes "f there may existcode which breaks when it is passed a subclass) then the

B%' has been violated &xample* Kiven a class ,ectangle) should a class %Huare

inherit from it< 7fter all) sHuare *S+Arectanglencle=ob'rinciplesOfOod@all linked articlesA

http*55wwwinfoHcom5presentations5principles-agile-oo-design

http*55wwwhanselminutescom5defaultaspx

object-oriented designe

Documents