Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

How to build SOLID code


Published on

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!

Published in: Software, Technology

How to build SOLID code

  1. 1. How to build SOLID code Sebastiano (eTr) Merlino
  2. 2. ZenConf 04/Jun/2014 - Catania
  3. 3. Almost entirely copied from inspired by the presentation “From STUPID to SOLID” by William Durand. #zenetr
  4. 4. DISCLAIMER: I give you an opinion not rules. Please, consider these just as principles, not laws! #zenetr
  5. 5. 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
  6. 6. Why should my code be clear? Because we READ much more than we WRITE #zenetr
  7. 7. STUPID code, seriously? #zenetr
  8. 8. What makes code STUPID? ● Singleton ● Tight Coupling ● Untestability ● Premature Optimization ● Indescriptive Naming (yeah! It’s not misspelled) ● Duplication #zenetr
  9. 9. Singleton #zenetr
  10. 10. 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
  11. 11. Tight Coupling #zenetr
  12. 12. 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
  13. 13. Untestability #zenetr
  14. 14. 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
  15. 15. Premature Optimization #zenetr
  16. 16. Premature Optimization PREMATURE 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 optimize DON’T DO IT. For experts only: DON’T DO IT NOW! Links: - Premature Optimization Anti-Pattern #zenetr
  17. 17. Indescriptive Naming #zenetr
  18. 18. 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
  19. 19. Duplication #zenetr
  20. 20. 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
  21. 21. #zenetr
  22. 22. SOLID Term describing a collection of design principles for GOOD CODE that was coined by ROBERT C. MARTIN aka UNCLE BOB #zenetr
  23. 23. What makes code SOLID? ● Single Responsibility Principle ● Open/Closed Principle ● Liskov Substitution Principle ● Interface Segregation Principle ● Dependency Inversion Principle #zenetr
  24. 24. Single Responsibility Principle #zenetr
  25. 25. 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
  26. 26. Open/Closed Principle #zenetr
  27. 27. 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
  28. 28. Liskov Substitution Principle #zenetr
  29. 29. 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! } }
  30. 30. 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?
  31. 31. Interface Segregation Principle #zenetr
  32. 32. 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
  33. 33. Dependency Inversion Principle #zenetr
  34. 34. 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
  35. 35. Rule of thumb: USE YOUR BRAIN! #zenetr
  36. 36. Thank you! #zenetr
  37. 37. Credits: code/ development-principles-in-motivational-pictures/ #zenetr
  38. 38. License: Creative Commons Attribution-ShareAlike 3.0 Unported License #zenetr