How to build SOLID code

How to build SOLID codeSebastiano (eTr) Merlino

ZenConf04/Jun/2014 - Catania

Almost entirely copied from inspired by the presentation “From STUPID to SOLID” by William Durand.

#zenetr

DISCLAIMER:I give you an opinion not rules.

Please, consider these just as principles, not laws!

#zenetr

Only 2 types of code do exist:Your code: Other people code:

It’s REASSURING and you understand it

It INTIMIDATES you and it’s ~99.999% of world’s code

#zenetr

Why should my code be clear?

Because we READ much more than we WRITE

#zenetr

STUPID code, seriously?

#zenetr

What makes code STUPID?● Singleton● Tight Coupling● Untestability● Premature Optimization● Indescriptive Naming (yeah! It’s not misspelled)● Duplication

#zenetr

Singleton#zenetr

Singleton● It represents a GLOBAL STATE in your code● Programs using global state are VERY difficult to test and debug● Programs relying on global state HIDE their dependencies

Links:- Why singletons are controversial?- Why is singleton an antipattern?- So Singletons are bad, then what?

#zenetr

Tight Coupling#zenetr

Tight Coupling● Generalization of the singleton ISSUE● If changing something in a module FORCES you to change also

another module● It makes code difficult to REUSE and also difficult to TEST● To avoid it, favor COMPOSITION over inheritance and try to use

DEPENDENCY INJECTION where possible.

Links:- Reducing Coupling (Martin Fowler)

#zenetr

Untestability#zenetr

Untestability● Testing should not be HARD● Whenever you don’t write UNIT TESTS because you DON’T HAVE

TIME, the real issue is that your code is BAD● Most of the time untestability is caused by TIGHT COUPLING

#zenetr

Premature Optimization#zenetr

Premature OptimizationPREMATURE OPTIMIZATION is the root of all evil - DONALD KNUTH● Do not OVER-COMPLICATE your system in order to optimize it● There is only COST and no BENEFIT● MEASURE the performances before you start to optimizeDON’T DO IT.For experts only: DON’T DO IT NOW!

Links:- Premature Optimization Anti-Pattern

#zenetr

Indescriptive Naming#zenetr

Indescriptive Naming● Name your classes, methods, attributes and variables properly● Don’t abbreviate, NEVER!● If you are not able to give your class a short name, maybe its

responsibilities are not WELL DEFINED● Programming languages are for HUMANS

#zenetr

Duplication#zenetr

Duplication● If you do it, you will find yourself changing your code in multiple

places.● Don’t Repeat Yourself (DRY)● Keep It Simple, Stupid! (KISS)● Be DRY not WET (We Enjoy Typing)

Links:- No, seriously. Don’t repeat yourself- DRY principle- KISS principle

#zenetr

#zenetr

SOLIDTerm describing a collection of design principles for GOOD CODE

that was coined by ROBERT C. MARTIN aka UNCLE BOB

#zenetr

What makes code SOLID?● Single Responsibility Principle● Open/Closed Principle● Liskov Substitution Principle● Interface Segregation Principle● Dependency Inversion Principle

#zenetr

Single Responsibility Principle#zenetr

Single Responsibility Principle● There should NEVER be more than ONE reason for a class to

change● Split big classes● Use LAYERS● Avoid GOD classes● Write STRAIGHTFORWARD comments

Links:- Single Responsibility Principle

#zenetr

Open/Closed Principle#zenetr

Open/Closed Principle● Software entities should be OPEN for extension but CLOSED for

manipulation● Make ALL member variables private● NO global variables, EVER● Avoid SETTERS (as much as possible)● Builder Pattern + Immutable Objects

Links:- Open/Closed Principle

#zenetr

Liskov Substitution Principle#zenetr

Liskov Substitution Principle#zenetr

public class Rectangle {

protected int width;

protected int height;

public int getArea() { return width * height; }

public void setWidth(int width) { this.width = width; }

public void setHeight(int height) { this.height = height; }}

public class Square extends Rectangle {

public void setWidth(int width) { this.width = width; this.height = width; }

public void setHeight(int height) { this.width = height; this.height = height; }

}

public class Main {

public static void main(String[] args) {

Rectangle rectangle = new Square();

rectangle.setWidth(10); rectangle.setHeight(20);

assert rectangle.getArea() == 200; // this will fail!

}

}

Liskov Substitution Principle#zenetr

● Objects in a program should be replaceable with instances of their subtypes WITHOUT ALTERING THE CORRECTNESS of the program

Links:● Liskov Substitution Principle● Circle-ellipse problem● Should sets inherit from bags?

Interface Segregation Principle#zenetr

Interface Segregation Principle#zenetr

● MANY client-specific interfaces are BETTER THAN ONE general-purpose interface.

● You should not have to implement methods you don’t use● Enforcing ISP gives you LOW COUPLING and HIGH COHESION● KEEP COMPONENTS FOCUSED and MINIMIZE DEPENDENCIES BETWEEN

THEM

Links:● Interface Segregation Principle● Coupling and Cohesion: Principles of Orthogonal OOP

Dependency Inversion Principle#zenetr

Dependency Inversion Principle#zenetr

● High level modules SHOULD NOT DEPEND upon low level modules. Both SHOULD DEPEND upon abstractions

● Abstractions should not depend upon details. Details should depend upon abstractions

● Use the same level of abstraction at a given level● It REDUCES DEPENDENCY on implementation specifics and makes

code MORE REUSABLE

Links:● Dependency Inversion Principle● Programming to the interface

Rule of thumb:USE YOUR BRAIN!

#zenetr

Thank you!https://github.com/etr

https://twitter.com/electrictwisterhttp://www.slideshare.net/electrictwister

#zenetr

Credits:http://williamdurand.fr/2013/07/30/from-stupid-to-solid-

code/http://lostechies.com/derickbailey/2009/02/11/solid-

development-principles-in-motivational-pictures/

#zenetr

License:Creative Commons Attribution-ShareAlike 3.0 Unported License

#zenetr