how to build solid code
DESCRIPTION
Presentation that introduces that concepts of STUPID code and SOLID code. Also if this two acronyms have been covered multiple times in Software Engineering history that are still sometimes not well known. It is always worth the spread the word!TRANSCRIPT
![Page 1: How to build SOLID code](https://reader033.vdocuments.site/reader033/viewer/2022051107/53fe08ca8d7f72db2d8b4575/html5/thumbnails/1.jpg)
How to build SOLID codeSebastiano (eTr) Merlino
![Page 2: How to build SOLID code](https://reader033.vdocuments.site/reader033/viewer/2022051107/53fe08ca8d7f72db2d8b4575/html5/thumbnails/2.jpg)
ZenConf04/Jun/2014 - Catania
![Page 3: How to build SOLID code](https://reader033.vdocuments.site/reader033/viewer/2022051107/53fe08ca8d7f72db2d8b4575/html5/thumbnails/3.jpg)
Almost entirely copied from inspired by the presentation “From STUPID to SOLID” by William Durand.
#zenetr
![Page 4: How to build SOLID code](https://reader033.vdocuments.site/reader033/viewer/2022051107/53fe08ca8d7f72db2d8b4575/html5/thumbnails/4.jpg)
DISCLAIMER:I give you an opinion not rules.
Please, consider these just as principles, not laws!
#zenetr
![Page 5: How to build SOLID code](https://reader033.vdocuments.site/reader033/viewer/2022051107/53fe08ca8d7f72db2d8b4575/html5/thumbnails/5.jpg)
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
![Page 6: How to build SOLID code](https://reader033.vdocuments.site/reader033/viewer/2022051107/53fe08ca8d7f72db2d8b4575/html5/thumbnails/6.jpg)
Why should my code be clear?
Because we READ much more than we WRITE
#zenetr
![Page 7: How to build SOLID code](https://reader033.vdocuments.site/reader033/viewer/2022051107/53fe08ca8d7f72db2d8b4575/html5/thumbnails/7.jpg)
STUPID code, seriously?
#zenetr
![Page 8: How to build SOLID code](https://reader033.vdocuments.site/reader033/viewer/2022051107/53fe08ca8d7f72db2d8b4575/html5/thumbnails/8.jpg)
What makes code STUPID?● Singleton● Tight Coupling● Untestability● Premature Optimization● Indescriptive Naming (yeah! It’s not misspelled)● Duplication
#zenetr
![Page 9: How to build SOLID code](https://reader033.vdocuments.site/reader033/viewer/2022051107/53fe08ca8d7f72db2d8b4575/html5/thumbnails/9.jpg)
Singleton#zenetr
![Page 10: How to build SOLID code](https://reader033.vdocuments.site/reader033/viewer/2022051107/53fe08ca8d7f72db2d8b4575/html5/thumbnails/10.jpg)
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
![Page 11: How to build SOLID code](https://reader033.vdocuments.site/reader033/viewer/2022051107/53fe08ca8d7f72db2d8b4575/html5/thumbnails/11.jpg)
Tight Coupling#zenetr
![Page 12: How to build SOLID code](https://reader033.vdocuments.site/reader033/viewer/2022051107/53fe08ca8d7f72db2d8b4575/html5/thumbnails/12.jpg)
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
![Page 13: How to build SOLID code](https://reader033.vdocuments.site/reader033/viewer/2022051107/53fe08ca8d7f72db2d8b4575/html5/thumbnails/13.jpg)
Untestability#zenetr
![Page 14: How to build SOLID code](https://reader033.vdocuments.site/reader033/viewer/2022051107/53fe08ca8d7f72db2d8b4575/html5/thumbnails/14.jpg)
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
![Page 15: How to build SOLID code](https://reader033.vdocuments.site/reader033/viewer/2022051107/53fe08ca8d7f72db2d8b4575/html5/thumbnails/15.jpg)
Premature Optimization#zenetr
![Page 16: How to build SOLID code](https://reader033.vdocuments.site/reader033/viewer/2022051107/53fe08ca8d7f72db2d8b4575/html5/thumbnails/16.jpg)
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
![Page 17: How to build SOLID code](https://reader033.vdocuments.site/reader033/viewer/2022051107/53fe08ca8d7f72db2d8b4575/html5/thumbnails/17.jpg)
Indescriptive Naming#zenetr
![Page 18: How to build SOLID code](https://reader033.vdocuments.site/reader033/viewer/2022051107/53fe08ca8d7f72db2d8b4575/html5/thumbnails/18.jpg)
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
![Page 19: How to build SOLID code](https://reader033.vdocuments.site/reader033/viewer/2022051107/53fe08ca8d7f72db2d8b4575/html5/thumbnails/19.jpg)
Duplication#zenetr
![Page 20: How to build SOLID code](https://reader033.vdocuments.site/reader033/viewer/2022051107/53fe08ca8d7f72db2d8b4575/html5/thumbnails/20.jpg)
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
![Page 21: How to build SOLID code](https://reader033.vdocuments.site/reader033/viewer/2022051107/53fe08ca8d7f72db2d8b4575/html5/thumbnails/21.jpg)
#zenetr
![Page 22: How to build SOLID code](https://reader033.vdocuments.site/reader033/viewer/2022051107/53fe08ca8d7f72db2d8b4575/html5/thumbnails/22.jpg)
SOLIDTerm describing a collection of design principles for GOOD CODE
that was coined by ROBERT C. MARTIN aka UNCLE BOB
#zenetr
![Page 23: How to build SOLID code](https://reader033.vdocuments.site/reader033/viewer/2022051107/53fe08ca8d7f72db2d8b4575/html5/thumbnails/23.jpg)
What makes code SOLID?● Single Responsibility Principle● Open/Closed Principle● Liskov Substitution Principle● Interface Segregation Principle● Dependency Inversion Principle
#zenetr
![Page 24: How to build SOLID code](https://reader033.vdocuments.site/reader033/viewer/2022051107/53fe08ca8d7f72db2d8b4575/html5/thumbnails/24.jpg)
Single Responsibility Principle#zenetr
![Page 25: How to build SOLID code](https://reader033.vdocuments.site/reader033/viewer/2022051107/53fe08ca8d7f72db2d8b4575/html5/thumbnails/25.jpg)
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
![Page 26: How to build SOLID code](https://reader033.vdocuments.site/reader033/viewer/2022051107/53fe08ca8d7f72db2d8b4575/html5/thumbnails/26.jpg)
Open/Closed Principle#zenetr
![Page 27: How to build SOLID code](https://reader033.vdocuments.site/reader033/viewer/2022051107/53fe08ca8d7f72db2d8b4575/html5/thumbnails/27.jpg)
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
![Page 28: How to build SOLID code](https://reader033.vdocuments.site/reader033/viewer/2022051107/53fe08ca8d7f72db2d8b4575/html5/thumbnails/28.jpg)
Liskov Substitution Principle#zenetr
![Page 29: How to build SOLID code](https://reader033.vdocuments.site/reader033/viewer/2022051107/53fe08ca8d7f72db2d8b4575/html5/thumbnails/29.jpg)
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!
}
}
![Page 30: How to build SOLID code](https://reader033.vdocuments.site/reader033/viewer/2022051107/53fe08ca8d7f72db2d8b4575/html5/thumbnails/30.jpg)
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?
![Page 31: How to build SOLID code](https://reader033.vdocuments.site/reader033/viewer/2022051107/53fe08ca8d7f72db2d8b4575/html5/thumbnails/31.jpg)
Interface Segregation Principle#zenetr
![Page 32: How to build SOLID code](https://reader033.vdocuments.site/reader033/viewer/2022051107/53fe08ca8d7f72db2d8b4575/html5/thumbnails/32.jpg)
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
![Page 33: How to build SOLID code](https://reader033.vdocuments.site/reader033/viewer/2022051107/53fe08ca8d7f72db2d8b4575/html5/thumbnails/33.jpg)
Dependency Inversion Principle#zenetr
![Page 34: How to build SOLID code](https://reader033.vdocuments.site/reader033/viewer/2022051107/53fe08ca8d7f72db2d8b4575/html5/thumbnails/34.jpg)
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
![Page 35: How to build SOLID code](https://reader033.vdocuments.site/reader033/viewer/2022051107/53fe08ca8d7f72db2d8b4575/html5/thumbnails/35.jpg)
Rule of thumb:USE YOUR BRAIN!
#zenetr
![Page 36: How to build SOLID code](https://reader033.vdocuments.site/reader033/viewer/2022051107/53fe08ca8d7f72db2d8b4575/html5/thumbnails/36.jpg)
Thank you!https://github.com/etr
https://twitter.com/electrictwisterhttp://www.slideshare.net/electrictwister
#zenetr
![Page 37: How to build SOLID code](https://reader033.vdocuments.site/reader033/viewer/2022051107/53fe08ca8d7f72db2d8b4575/html5/thumbnails/37.jpg)
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
![Page 38: How to build SOLID code](https://reader033.vdocuments.site/reader033/viewer/2022051107/53fe08ca8d7f72db2d8b4575/html5/thumbnails/38.jpg)
License:Creative Commons Attribution-ShareAlike 3.0 Unported License
#zenetr