bgenius kennissessie_20120510

SOLID Software Design@jankeesvanandel

@jwalgemoed

@JPoint

SOLID Software Design 1

About us

Jarno Walgemoed–Architect @JPoint–Fa-Med–Blinker–DJI


Jan-Kees van Andel–Architect @JPoint–Rabobank–SNS Bank

–Apache MyFaces–Devoxx Steering

Develo

per

Develo

per

Developer

Developer

Agenda

– Goals– Code quality– SOLID– Other principles– Demo– Conclusion– Q&A


Agenda



Goals

NOT our goal


Goals

Mastery takes lots of practice– You can’t learn to surf by reading a book– Neither programming


Goals


“The 10.000 hour rule” – Malcolm Gladwell

Goals


• ShuHaRi– Shu: Traditional wisdom– Ha: Breaking with tradition– Ri: Transcendence

Goals

After this session– you will NOT suddenly write better code

But…– you hopefully have some hooks to get better


Agenda



Code quality

Is this code quality?


private static final String OID = "oId";private static final String TIME_INCIDENT = "timeOfIncident";private static final String EX_MSG = "exMsg";private static final String TECH_EX_MSG = "techExMsg";

...

mav.addObject(OID, oId == null ? "":oId);mav.addObject(TIME_INCIDENT, (new Date()).toString());mav.addObject(EX_MSG, e.getMessage() == null ? "":e.getMessage());mav.addObject(TECH_EX_MSG, e.toString());

Code quality



@Controllerpublic class StartController {

@Autowired public StartController(SessionData sessionData, TransactionService txService, InitializerFactory initFactory, AuthorizationHandler authHandler, UIBinder uiBinder, StartValidator startValidator, WebApplicationContext ctx, RegistrationService regService) { //...

Code quality



Code quality



/** * This controller contains default Action and Render mappings, * used as fallback for handling invalid URL's. This prevents DOS * attacks, because a "no-handler-found“ Exception results in a * corrupt application state in WAS and can only be restored by * restarting the application. These handlers solve this problem. */@Controller@RequestMapping("VIEW")public class DefaultController {

Code quality



/** * This controller contains default Action and Render mappings, * used as fallback for handling invalid URL's. This prevents DOS * attacks, because a "no-handler-found“ Exception results in a * corrupt application state in WAS and can only be restored by * restarting the application. These handlers solve this problem. */@Controller@RequestMapping("VIEW")public class WebSphereASDefaultHandlerController {

Code quality

Tonight, code quality means OO Design

– OOD is not free or easy, not even with Java/C#

– A lot of structured programming out there!


Code quality

Tonight, code quality means SOLID principles

– Not about Object Oriented Modeling• (Person, User, Plane is-a Vehicle, etc)• Highlighting Nouns

– But about Dependency Management


Code quality

Tonight, code quality means Dependency Mgt– Because• We DON’T want rigid code• We DON’T want changes to cause ripple effects• We DON’T want fragile code• We DO want easily unit testable code• We DO want reusable code• We DO want readable code


Code quality

Why dependency Management?– Because we don’t want code rot


Code quality

Why dependency Management?– Refactor sprint


Code quality

Why dependency Management?– Continuous refactoring


Agenda



SOLID

SOLID– First stated by Robert C. Martin in 1995– “The Ten Commandments of OO Programming”


SOLID

SOLID:– Later documented in “Agile Software

Development: Principles, Patterns and Practices”


SOLID

Short for:– SRP: Single Responsibility Principle

–OCP: Open-Closed Principle

– LSP: Liskov Substitution Principle

– ISP: Interface Segregation Principle

–DIP: Dependency Inversion Principle


Single Responsibility Principle

“A class should have only one reason to change”– Theory– Simple example– Real world example– Considerations– Conclusion



Theory– A Class Should Only Have One Reason To Change– Also referred to with the term Cohesion

(DeMarco, Page-Jones)– Separation of Concerns– Classes should have ONE well-defined

responsibility



Simple example– Database application interface specification


public interface Database { public void connect(String url);

public void disconnect();

public ResultSet executeQuery(String query);}


Simple example– What if the protocol changes?– What if the connection management changes?– What if we want to implement pooling or caching?

– We’ll need to change the database implementation in both cases



Simple example– How about this?


public interface DatabaseConnection {

public ResultSet executeQuery(String query);}

public interface DatabaseConnectionManager {

public DatabaseConnection connect(String url);

public void disconnect(DatabaseConnection conn);}


Simple example– DatabaseConnection implementations handle

querying– DatabaseConnectionManager implementations

handle connections– We’ve managed to split two responsibilities



Considerations– Should we split every class we create? No.– Will we end up with one-method classes? No.



Considerations– If the application doesn’t require changing either

of the coupled responsibilities at different times DON’T USE SRP

– Don’t apply SRP if there are no symptoms– Treat it as a guideline– Be consistent in what you call a “Responsibility”• Split on functionality, domain, architecture, layers and

do this in a consistent way



Conclusion– Simplest SOLID principle, hardest to get right– Be critical deciding whether or not an SRP

violation needs to be fixed– Stay pragmatic!– State management simplified by separating object

lifecycles



Question: Real world usages of SRP?– Examples in Java API– Examples in GoF Design Patterns– Big abusers


Open-Closed Principle

“Software entities should be open for extension, but closed for modification”– Theory– Simple example– Real world example– Considerations– Conclusion



Theory– Helps preventing rigidity and cascading changes– Open for extension• Behaviour of a module can be extended

– Closed for modification• Extending does not result in a source change for a

module



Simple Example– We are using this Rectangle object


public class Rectangle {

private int width; private int height;

public int getWidth() { return width; }

public int getHeight() { return height; }}


Simple Example– With this function we calculate area totals


public class AreaCalculator {

public int calculateTotalArea(Rectangle [] rectangles) { int totalArea = 0; for(Rectangle rectangle : rectangles){ totalArea += rectangle.getWidth() * rectangle.getHeight(); } return totalArea; }}


Simple Example– Now we want to add a circle to the equation


public class Circle { private int radius;

public int getRadius() { return radius; }}


Simple Example– What happens to the calculation?


public double calculateTotalArea(Object [] objects) { double totalArea = 0; for(Object object : objects){ if(object instanceof Rectangle){ Rectangle rectangle = (Rectangle)object; totalArea += rectangle.getWidth() * rectangle.getHeight(); } if(object instanceof Circle){ Circle circle = (Circle)object; totalArea += circle.getRadius() * circle.getRadius() * Math.PI; } } return totalArea;}


Simple Example– This is poor design (of course)– The calculate method is not closed for

modification and not open for extension– Adding a Circle requires the developer to change

the calculation code!



Simple Example– Introducing Shape and extending it


public abstract class Shape { public abstract double getArea();}

public class Circle extends Shape { public double getArea() { return radius * radius * Math.pi; } …}


Simple Example– Simplifies AreaCalculator substantially– Allows future extension


public class AreaCalculator {

public double calculateTotalArea(Shape[] shapes) { double totalArea = 0; for (Shape shape : shapes) { totalArea += shape.getArea(); } return totalArea; }}


Simple Example– The calculation is now Open for extension and

closed for modification– Adding another shape to the equation no longer

requires a change to the calculate implementation



Considerations



Considerations– Abstraction is key– So… should we just abstract everything? No.

– Abstract elements that require frequent change– Overuse of abstractions can create clutter– Avoid premature abstraction



Conclusion– At the heart of Object Oriented design– Design using logical, useful abstractions– Add abstractions only when required– Expect having no changes in your code– Stimulate change (test, iterate)– Properly refactor code that’s affected by these changes



Question: Real world usages of OCP?– Examples in Java API– Examples in GoF Design Patterns– Big abusers


Liskov Substitution Principle

“If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T”– Come again?



“Subtypes must be substitutable for their base types”– Theory– Simple example– Real world example– Considerations– Conclusion



Theory– Polymorphism problem

– A extends B• This means A IS-A B• …but is this always true for A and B?



Simple Example– Square extends Rectangle• Square IS-A Rectangle, right?

– Difference between Square and Rectangle• Rectangle can have different height and width settings• Square has equal values for both



Simple Example– So, this is correct then?


class Rectangle { private int width; private int height;

public Rectangle(int width, int height) { this.width = width; this.height = height; } // Setters left out for brevity}

class Square extends Rectangle { // Initialize as a square public Square(int size) { super(size, size); }}


Simple Example– Suppose we test the Square like this

– Our square suddenly is a 42 by 50 Rectangle!


Square square = new Square(42);assertEquals(42, square.getWidth()); // Oksquare.setHeight(50);// Width should be the same as height, and we changed it!assertEquals(50, square.getWidth()); // Whoops!


Simple Example– Fixing is easy, but is this really the way to go?


class Square extends Rectangle {

public void setWidth(int width) { super.setWidth(width); super.setHeight(width); }

public void setHeight(int height) { super.setHeight(height); super.setWidth(height); }}


Simple Example– Maybe better to do this


class Square extends Shape { // Immutable private final int size;

public Square(int size) { this.size = size; }

@Override public int getHeight() { return size; }

@Override public int getWidth() { return size; }}


Considerations– The IS-A relationship not always applies in code• A square is a rectangle in the real world• A square is not a rectangle in code – contract breaks

when square doesn’t override rectangle behaviour

– Immutability can make a difference• public Rectangle(int width, int height);• public Square(int size);• If both are immutable, Rectangle really IS-A Square!



Conclusion– Rule of thumb

• Instead of: A IS-A B, use: A is substitutable by B

– Inherit from a more abstract supertype if needed• Rectangle and Square could both inherit from Shape• Shape should enforce no rules for width and height

– Should you prevent LSP violations at all cost? No.• What if you only have a method that draws Rectangles• Will the LSP violation be a problem then?



Question: Real world usages of LSP?– Examples in Java API– Examples in GoF Design Patterns– Big abusers


Interface Segregation Principle

“Clients should not be forced to depend on methods that they do not use”– Theory– Simple example– Real world example– Considerations– Conclusion



Simple Example– Interface definition for a worker doing work

– Implementation for a generic employee


public interface Worker { public void work(); public void eat();}

public class Employee implements Worker { public void work() { // do work stuff } public void eat() { // eat lunch, keep up strength ;) }}


Simple Example– Robots are also part of the business

– But they don’t eat lunch– Still, eat() has to be implemented


public class Robot implements Worker { public void work() { // Work (without union breaks } public void eat() { // Wait, what? }}


Simple Example– Split up the interfaces into sensible pieces


public interface NutritionConsumer { public void eat();}

public interface Worker { public void work();}


Simple Example– Implement the interfaces as needed


public class Employee implements Worker, NutritionConsumer { public void work() { } public void eat() { }}

public class Robot implements Worker { public void work() {}}


Simple Example– Class dealing with Worker objects

– Can deal with both robots and employees– Doesn’t need to be concerned with the nutritional

needs of the Employee type workers


public class WorkloadManager { public void putWorkerToWork(Worker worker) { worker.work(); }}


Considerations– Avoid coupling between interfaces and clients– Clients should only depend on methods they use– Separation reduces the risk of changes cascading

to implementing classes that do not have a need for those methods



Conclusion– Separate interfaces when it makes sense– Don’t overdo it!• Prevent classes having to implement many interfaces• Prevent one-method interfaces

– Common sense is key (again)• Split up interfaces as soon as clients show the need to

do so



Question: Real world usages of ISP?– Examples in Java API– Examples in GoF Design Patterns– Big abusers


Dependency Inversion Principle

“High-level modules should not depend on low-level modules directly, but through abstraction”“Abstractions should not depend on details, details should depend on abstractions”– Theory– Simple example– Real world example– Considerations– Conclusion



Simple Example– Application that monitors system status


public class SystemStatus {

private HeatGauge gauge;

public void checkTemperature() throws OverheatingException { if(gauge.actualTemperature() > 55) { throw new OverheatingException(); } }}


Simple Example– HeatGauge implementation


public class HeatGauge { public int actualTemperature() { // Do some measuring and return the results }}


Simple Example– Systemstatus directly depends on HeatGauge– Changes to HeatGauge can affect SystemStatus



private HeatGauge gauge = new HeatGauge();



Simple Example– Abstract away the dependency


public interface HeatGauge { public int actualTemperature();}

public class HeatGaugeImpl implements HeatGauge { public int actualTemperature() { // Do some measuring }}


Simple Example– Use the new abstraction

– Better, but not perfect



// Less dependent by using the interface private HeatGauge gauge = new GaugeImpl();



Simple Example– Improving the example

– Abstracts away the implementation used to gauge the temperature


public class SystemStatus { private HeatGauge heatGauge; public SystemStatus(HeatGauge heatGauge){ this.heatGauge = heatGauge; }

public void checkTemperature() throws OverheatingException { if(heatGauge.actualTemperature() > 55) { throw new OverheatingException(); } }}


Considerations– Clients should ‘own’ the interfaces used to access

low-level modules– Not the same as Dependency Injection (DI)• Dependency Inversion

– Using abstractions to achieve loose coupling– Ownership should be at client level

• Dependency Injection – Design pattern to implement loose coupling



Conclusion– Maybe the most relevant of all SOLID principles– Allows robust code to be written using

abstractions– Dependency Inversion• Relevant when designing functionality

– Dependency Injection• Relevant when implementing functionality

– Do all classes need an interface? No.



Question: Real world usages of DIP?– Examples in Java API– Examples in GoF Design Patterns– Big abusers


Agenda



Other principles

Not SOLID, but just as important!– REP: Release reuse Equivalency Principle– CCD: Common Closure Principle– CRP: Common Reuse Principle– ADP: Acyclic Dependencies Principle– SDP: Stable Dependencies Principle– SAP: Stable Abstractions Principle– From the same book as SOLID


Other principles

Not SOLID, but just as important!– REP: Release reuse Equivalency Principle– CCD: Common Closure Principle– CRP: Common Reuse Principle

– About package cohesion


Other principles

Not SOLID, but just as important!– ADP: Acyclic Dependencies Principle– SDP: Stable Dependencies Principle– SAP: Stable Abstractions Principle

– About package coupling


Agenda



Conclusion

Demo– Small web application to demo the ideas


Agenda



Conclusion

Master the SOLID principles– Use it in your communications– Use it to challenge your design/yourself– Applicable to modules, libraries, components...

– But don’t be dogmatic about it– Don’t write SOLID, just because you can– Try to see the disadvantages too!– Don’t just believe the hype!


Conclusion

SOLID principles are no hard rules– Definitely no hard rules!– Also no goals, just a means to an end

– There are more principles– Principle of least Knowledge– Premature optimization is the root of all evil– Composition over Inheritance– K.I.S.S. / Y.A.G.N.I.


Conclusion

Don’t be dogmatic– Even Uncle Bob said this– http://blog.objectmentor.com/articles/2009/02/0

6/on-open-letter-to-joel-spolsky-and-jeff-atwood

– In response to– http://www.joelonsoftware.com/items/2009/01/3

1.html


Q&A

Any questions left?


bgenius kennissessie_20120510

Technology

code rotsolid software

jpoint solid software

goal solid software

tostringsolid software

sprintsolid software

code qualityis

solid software design15

solid software design16