Copyright © by Curt Hill

Introduction The SOLID acronym has been called the first five principles of OO Design Introduced by Robert Martin Acronym by Michael Feathers Before we consider this lets consider bad design Copyright © by Curt Hill

Three Traits of Bad Design
Rigidity It is hard to change because every change affects too many other parts of the system Fragility When you make a change, unexpected parts of the system break. Immobility It is hard to reuse in another application because it cannot be disentangled from the current application Copyright © by Curt Hill

Single Responsibility
A class should have only a single responsibility It should do just one thing One alternative to responsibility that is suggest is a reason to change If you can think of more than one motive for changing a class, then that class has more than one responsibility If a class has multiple responsibilities we say that they are coupled Copyright © by Curt Hill

Example We have a Rectangle class that is used by two other classes A computational geometry class A GUI drawing class The Rectangle class now has two distinct responsibilities Provide a model for of geometry Provide the ability to draw on a surface If the GUI drawing class changes we may need to also change geometry class Copyright © by Curt Hill

Open Closed You should be able to extend a classes behavior without modifying it Modules should be designed to never change If the code works leave it alone When requirements change the behavior is extended Add new code but not by changing code that works Copyright © by Curt Hill

Extensions Extensions take mostly two forms We add a new method that may utilize some of the existing and working code We derive a new class from the existing class and add extensions there Violations of this principle tend to cascade changes into other modules, which often break The code becomes fragile Copyright © by Curt Hill

Liskov Substitution Derived classes must be substitutable for their base classes Any module that uses a class, should be able to use any descendent class without knowing it Attributed to Barbara Liskov, a recent Turing award winner Copyright © by Curt Hill

Violations When the Liskov substitution principle is is violated then the module must know about all the descendants Even those not created when the module was designed What we typically see in this case is lots of Ifs that determine the type of the object This is a bad thing Copyright © by Curt Hill

Digression on Interfaces
An interface in a general sense is that collection of public methods that a class presents An Abstract Base Class is an interface In Java there is an Interface construct which is a contract An implementing class promises to provide certain methods In C++ we do not need the Interface We have multiple inheritance Copyright © by Curt Hill

Interface Segregation
Make fine grained interfaces that are client specific We would like our interfaces to be cohesive Non-cohesive interfaces typically have groups of interfaces Different clients will use different groups of interfaces Copyright © by Curt Hill

Doors Suppose we want a door class It may be locked or unlocked It may be open or closed Now we derive from that a timed door that sounds an alarm if the door is open too long The timed door registers with a a timer object When the time elapses the timer object does a call of a method to alert the timed door object Copyright © by Curt Hill

Door Again We create a timer client We then derive door from that We then derive timed door from door Now door has a timer client that it does not need Its subclass does, but not it This is an example of interface pollution Door has been polluted with what it does not need Copyright © by Curt Hill

Continuing Timer client was one interface while door was another They are completely different Thus they should be separated, ie. Interface Segregation Stated again, the Interface Segregation Principle says that clients should not be forced to depend on interfaces that they do not use Copyright © by Curt Hill

Dependency Inversion High level modules should not depend upon low level modules Both should depend on abstractions Abstractions should not depend on details Details should depend on abstractions Said another way Concrete classes may depend on abstract classes or on concrete classes Abstract classes should not depend on concrete classes Copyright © by Curt Hill

Layers In many software systems we have layers Such as operating systems Each layer provides an interface to the upper layer Each layer uses the lower layer to accomplish the tasks This is a well known technique Copyright © by Curt Hill

Inversion? The layering appears to make more abstract things dependent on more concrete items In the Dependency Inversion Principle we are not considering the same thing Rather we are talking about interface dependencies Copyright © by Curt Hill

Finally These five principles form a foundation for object design Like several “rules of thumb” they may be violated But only with very good cause Convenience is not such a cause These are principles we will also apply in refactoring Finally for now Copyright © by Curt Hill

Copyright © by Curt Hill

Similar presentations

Presentation on theme: "Copyright © by Curt Hill"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Copyright © by Curt Hill

Similar presentations

Presentation on theme: "Copyright © by Curt Hill"— Presentation transcript:

Similar presentations

About project

Feedback