How to build SOLID code
-
Upload
sebastiano-merlino -
Category
Software
-
view
341 -
download
10
description
Transcript of 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