Object-Oriented Design

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

Rigidity The system is hard to change because every change

forces many other changes to other parts of the system

Fragility !hanges cause the system to break in places that

have no conceptual relationship to the part that was changed

Immobility "t is hard to disentangle the system into

components 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

its intent well

structures that could be unified under a single abstraction

Opacity "t is hard to read and understand "t does not express
Copyright 2009 Esko Luontola 2

Agile Software Development: Principles, Patterns, and Practices ch# p$$

%imple Design

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

+ . / ,uns all the tests !ontains no duplication &xpresses the intent of the programmer 0inimi1es the number of classes and methods
2eeping the design clean and simple at all times is 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

Truly agile teams don(t allow the software to rot

Clean Code ch+Extreme Programming Explained (1st Ed.) ch+3 p4# Copyright 2009 Esko Luontola http*55xprogramming com5xpmag5exp&mergentDesign Agile Software Development: Principles, Patterns, and Practices ch# p63

F F

7rchitecture

87rchitecture is about the important stuff 9hatever that is 8 :7rchitecture is the decisions that you wish you could get right early in a project ; 9hy do people feel the need to get some things right early in the project< The answer) of course) is because they perceive those things 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) i e spinning system designs based on untested hypotheses for many months) is harmful =D>? inhibits adapting to change Bittle5&nough Design >p ?ront @BD>?5&D>?A is good 9ith a big project spending a week or even a month thinking about the important things is nothing wrong 7gile was a response to =D>?) but not D>? ?ar from :design nothing); the C' strategy is :design always ; 9hatever designs have been done up front) they should always be open for change Bet the tests drive the system architecture
4

http*55www ibm com5developerworks5java5library5j-eaed+5 Copyright 2009 Esko Luontola http*55martinfowler com5ieee%oftware5whoDeeds7rchitect pdf Clean Code ch++ p+EE http*55blog objectmentor com5articles5-33653/5-45the-scatology-of-agile-architecture

'rinciples of 0odular Design

Cohesion higher is better

!ohesion is a measure of how strongly-related or focused the responsibilities of a single module are !oupling or dependency is the degree to which each program module relies on each one of the other modules

Coupling lower is better

http*55en wikipedia org5wiki5!ohesionG@computerGscienceA http*55en wikipedia org5wiki5!ouplingG@computerGscienceA Copyright 2009 Esko Luontola Clean Code ch+3 p+/3 http*55reborg tumblr com5post5$-.E-$4+5clean-code-cheat-sheet

'rinciples of Object-Oriented Design

http*55www infoH com5presentations5principles-agile-oo-design @.3 minA

Copyright 2009 Esko Luontola

Copyright 2009 Esko Luontola 7 http*55www lostechies com5blogs5derickbailey5archive5-33653-5++5solid-development-principles-in-motivational-pictures aspx http*55www globalnerdy com5-33653#5+45the-solid-principles-explained-with-motivational-posters5

%OB"D 'rinciples

%,'* O!'* B%'* "%'* D"'*

%ingle ,esponsibility 'rinciple Open !losed 'rinciple Biskov %ubstitution 'rinciple "nterface %egregation 'rinciple Dependency "nversion 'rinciple

http*55butunclebob com57rticle% >ncle=ob 'rinciplesOfOod http*55www hanselminutes com5default aspx<show"DI+E. http*55blog objectmentor com5articles5-33653-5+-5getting-a-solid-start Copyright 2009 Esko Luontola http*55www lostechies com5content5pabloGebook aspx

8 http*55www lostechies com5blogs5chadGmyers5archive5-33$53.53#5pablo-s-topic-of-the-month-march-solid-principles aspx

Copyright 2009 Esko Luontola 9 http*55www lostechies com5blogs5derickbailey5archive5-33653-5++5solid-development-principles-in-motivational-pictures aspx http*55www globalnerdy com5-33653#5+45the-solid-principles-explained-with-motivational-posters5

%ingle ,esponsibility 'rinciple

A class s o!ld ave onl" one reason to c ange.

&ach responsibility should be separated to its own class) because each responsibility is an axis of change !hange to one responsibility may break others in the same class ?ollowing the %,' leads to small) highly focused) cohesive classes) which each do only one thing &ach of them will be 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 @.A saves itself to database &ach of them should be separated into its own class* &mployee'ay!alculator) &mployee'ayroll,eport) &mployee,epository
10

http*55www objectmentor com5resources5articles5srp pdf Copyright 2009 Esko Luontola Agile Software Development: Principles, Patterns, and Practices ch$ p64 Clean Code ch+3 p+-$

Copyright 2009 Esko Luontola 11 http*55www lostechies com5blogs5derickbailey5archive5-33653-5++5solid-development-principles-in-motivational-pictures aspx http*55www globalnerdy com5-33653#5+45the-solid-principles-explained-with-motivational-posters5

Open !losed 'rinciple

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

0ake classes depend on abstract interfaces instead of concrete classes "nject new behaviour into existing classes by providing a different implementation of the interface 9hen the O!' is applied well) new behaviour can be added 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
Copyright 2009 Esko Luontola 12

http*55www objectmentor com5resources5articles5ocp pdf Agile Software Development: Principles, Patterns, and Practices ch6 p66

7nticipating ?uture !hanges

8%ince closure cannot be complete) it must be strategic That is) the designer must choose the kinds of changes against which to close his design Je must guess at the most likely kinds of changes) and then construct abstractions to protect him from those changes 8 87lso) conforming to the O!' is expensive. "t takes development time and effort to create the appropriate abstractions Those abstractions also increase the complexity of the software design 8

Copyright 2009 Esko Luontola

13

Agile Software Development: Principles, Patterns, and Practices ch6 p+34

7nticipating ?uture !hanges

Do not put hooks in for changes that mig t happen "nstead) wait !ntil t e c anges appen$
%&ool me once, s ame on "o!. &ool me twice, s ame on me.%

"nitially write the code expecting it to not change 9hen a change occurs) implement the abstractions that protect from future changes of t at 'ind. "t(s better to take the first hit as early as possible 9e want to 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 most important features first ,elease early and often
Copyright 2009 Esko Luontola 14

Agile Software Development: Principles, Patterns, and Practices ch6 p+34

Copyright 2009 Esko Luontola 15 http*55www lostechies com5blogs5derickbailey5archive5-33653-5++5solid-development-principles-in-motivational-pictures aspx http*55www globalnerdy com5-33653#5+45the-solid-principles-explained-with-motivational-posters5

Biskov %ubstitution 'rinciple

S!#t"pes m!st #e s!#stit!ta#le for t eir #ase t"pes. ( &!nctions t at !se references to #ase classes m!st #e a#le to !se o#)ects of derived classes wit o!t 'nowing it.

The rule which must be followed when inheriting from another class5interface 7ll assumptions that functions make about the base class) must be valid for all derived classes "f there may exist code 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+A rectangle<
Copyright 2009 Esko Luontola 16

http*55www objectmentor com5resources5articles5lsp pdf Agile Software Development: Principles, Patterns, and Practices ch+3 p+++

public class ,ectangle L private int widthM private int heightM public int get9idth@A L return widthM N public void set9idth@int widthA L this width I widthM N public int getJeight@A L return heightM N public void setJeight@int heightA L this height I heightM N N
Copyright 2009 Esko Luontola 17

public class %Huare extends ,ectangle L public void set9idth@int widthA L super set9idth@widthAM super setJeight@widthAM N public void setJeight@int heightA L super set9idth@heightAM super setJeight@heightAM N

Copyright 2009 Esko Luontola

18

The 'roblem
public void g@,ectangle rA L r set9idth@4AM r setJeight@/AM assert r area@A II -3M N

8The #e avio!r of a Square object is not consistent with g(s expectation of the behaviour of a Rectangle object =ehaviorally) a Square is not a Rectangle) and it is #e avio!r that software is really all about 8 8The B%' makes it clear that in OOD) the "%-7 relationship pertains to #e avio!r that can be reasonably assumed and that clients depend on 8
Copyright 2009 Esko Luontola 19

Agile Software Development: Principles, Patterns, and Practices ch+3 p++E

Copyright 2009 Esko Luontola 20 http*55www lostechies com5blogs5derickbailey5archive5-33653-5++5solid-development-principles-in-motivational-pictures aspx http*55www globalnerdy com5-33653#5+45the-solid-principles-explained-with-motivational-posters5

"nterface %egregation 'rinciple

Clients s o!ld not #e forced to depend !pon interfaces t at t e" do not !se.

!lasses should not have 8fat8 non-cohesive interfaces The interfaces should be broken into groups of methods) so that each group serves a different set of clients 9hen one set of clients forces new reHuirements and changes to the interface) we do not want unrelated clients to be affected by those changes ?ollowing the "%' isolates different groups of clients from one another

http*55www objectmentor com5resources5articles5isp pdf Agile Software Development: Principles, Patterns, and Practices ch+- p+.4

Copyright 2009 Esko Luontola

21

Copyright 2009 Esko Luontola

22

Agile Software Development: Principles, Patterns, and Practices ch+- p+.E

%eparation through delegation

Copyright 2009 Esko Luontola

23

Agile Software Development: Principles, Patterns, and Practices ch+- p+.$

%eparation through multiple inheritance

Copyright 2009 Esko Luontola

24

Agile Software Development: Principles, Patterns, and Practices ch+- p+.6

Copyright 2009 Esko Luontola 25 http*55www lostechies com5blogs5derickbailey5archive5-33653-5++5solid-development-principles-in-motivational-pictures aspx http*55www globalnerdy com5-33653#5+45the-solid-principles-explained-with-motivational-posters5

Dependency "nversion 'rinciple

A. ,ig +level mod!les s o!ld not depend on low+level mod!les. -ot s o!ld depend on a#stractions. -. A#stractions s o!ld not depend on details. Details s o!ld depend on a#stractions.

9hen high-level modules depend on the lower level modules) c anges to t e lower level mod!les can force t e ig er level mod!les to c ange. "t is the high-level) policy-setting modules that ought to be influencing the low-level) detailed modules) not the other way roundO "t is the high-level) policy-setting modules that we want to be able to reuse 9e are already Huite good at reusing low-level modules as libraries 9hen high-level modules depend on lowlevel modules) it #ecomes ver" diffic!lt to re!se t ose ig +level mod!les in different contexts.
Copyright 2009 Esko Luontola

http*55www objectmentor com5resources5articles5dip pdf Agile Software Development: Principles, Patterns, and Practices ch++ p+-#

26

Copyright 2009 Esko Luontola

27

Agile Software Development: Principles, Patterns, and Practices ch++ p+.3

Copyright 2009 Esko Luontola

28

Agile Software Development: Principles, Patterns, and Practices ch++ p+.+

!ourse 0aterial

Clean Code chapter +3* !lasses Clean Code chapter ++* %ystems Clean Code chapter +-* &mergence http*55www ibm com5developerworks5java5library5j-eaed+5 http*55martinfowler com5ieee%oftware5whoDeeds7rchitect pdf http*55blog objectmentor com5articles5-33653/5-45the-scatology-of-agile-architecture http*55en wikipedia org5wiki5!ohesionG@computerGscienceA http*55en wikipedia org5wiki5!ouplingG@computerGscienceA http*55reborg tumblr com5post5$-.E-$4+5clean-code-cheat-sheet http*55butunclebob com57rticle% >ncle=ob 'rinciplesOfOod @all linked articlesA http*55www infoH com5presentations5principles-agile-oo-design http*55www hanselminutes com5default aspx<show"DI+E. http*55blog objectmentor com5articles5-33653-5+-5getting-a-solid-start
Copyright 2009 Esko Luontola 29