Design principles in a nutshell
Download as PPTX, PDF0 likes150 views
The document discusses essential design principles for software development, emphasizing the importance of simplicity, maintaining low coupling and high cohesion, and adhering to the SOLID principles. Key concepts include the KISS principle, the YAGNI philosophy, and the significance of code reviews. It highlights that good design minimizes the cost of changes, avoids unnecessary complexity, and focuses on creating cohesive, single-responsibility classes.
Design principles in a nutshell
- 1. Design Principles in a Nutshell Dmytro Panin & Anton Udovychenko 12.2015
- 2. Agenda ▪ What is a good design? ▪ Complexity and simplicity ▪ KISS ▪ YAGNI ▪ Cohesiveness and coupling ▪ SOLID ▪ Q&A
- 3. Good design ▪ Design is good when a cost of changing of a design is minimum
- 4. Good design ▪ Design is good when a cost of changing of a design is minimum ▪ Easy to change
- 5. Good design ▪ Design is good when a cost of changing of a design is minimum ▪ Easy to change Almost impossible to get it right the first time
- 6. How to make a good design?
- 7. How to make a good design? ▪ Let go of the ego
- 8. How to make a good design? ▪ Let go of the ego ▪ Be unemotional
- 9. How to make a good design? ▪ Let go of the ego ▪ Be unemotional ▪ Do code reviews
- 10. How to make a good design? ▪ Let go of the ego ▪ Be unemotional ▪ Do code reviews ▪ A good design is the one that hides inherited complexity and eliminates the accidental complexity
- 11. How to make a good design? ▪ Let go of the ego ▪ Be unemotional ▪ Do code reviews ▪ A good design is the one that hides inherited complexity and eliminates the accidental complexity Software is never written, it is always rewritten. As the software that is relevant always must be changed
- 12. Complexity ▪ Inherited from a domain ▪ Accidental complexity
- 13. KISS - Keep it simple and stupid
- 14. What is simple?
- 15. What is simple? ▪ Simple makes you concentrated
- 16. What is simple? ▪ Simple makes you concentrated ▪ Simple resolves only actual issues we know about
- 17. What is simple? ▪ Simple makes you concentrated ▪ Simple resolves only actual issues we know about ▪ Simple fails less
- 18. What is simple? ▪ Simple makes you concentrated ▪ Simple resolves only actual issues we know about ▪ Simple fails less ▪ Simple is easier to understand
- 19. Simple is not necessarily familiar.
- 20. Think YAGNI Do we need it? Day 1 We have to ask ourselves whether we need it today or not. If it's possible to postpone something constantly for a few iterations maybe you don't need it at all.
- 21. Think YAGNI Do we need it? Day 1 Do we actually need it? Day 5 We have to ask ourselves whether we need it today or not. If it's possible to postpone something constantly for a few iterations maybe you don't need it at all.
- 22. Think YAGNI Do we need it? Day 1 Do we actually need it? Day 5 We do not need it Day 9 We have to ask ourselves whether we need it today or not. If it's possible to postpone something constantly for a few iterations maybe you don't need it at all.
- 23. Cost of implementing Smart Smarter Much smarter Now correlation Later Result X > Y Postpone X == Y Postpone X < Y ?
- 24. Do not confuse postponement and procrastination
- 25. Coupling ▪ Coupling is what you depend on...
- 26. Coupling ▪ Coupling is what you depend on... ▪ Inheritance is the worst form of coupling
- 27. Coupling ▪ Coupling is what you depend on... ▪ Inheritance is the worst form of coupling ▪ "knock out before mock out“
- 28. Coupling ▪ Coupling is what you depend on.... ▪ Inheritance is the worst form of coupling ▪ "knock out before mock out“ ▪ Depending on a class is a tight coupling
- 29. Coupling ▪ Coupling is what you depend on.... ▪ Inheritance is the worst form of coupling ▪ "knock out before mock out“ ▪ Depending on a class is a tight coupling ▪ Depending on an interface is a loose coupling
- 30. Coupling ▪ Coupling is what you depend on.... ▪ Inheritance is the worst form of coupling ▪ "knock out before mock out“ A good design has high cohesion and low coupling ▪ Depending on a class is a tight coupling ▪ Depending on an interface is a loose coupling
- 31. DRY ( Do not Repeat Yourself ) ▪ Every piece of knowledge in a system should have a single unambiguous authoritative representation ▪ It reduces the cost of development
- 32. SOLID ▪ Single responsibility principle ▪ Open-Closed Principle ▪ Liskov substitution principle ▪ Interface segregation principle ▪ Dependency inversion principle
- 34. Single responsibility principle ▪ A class should have only a single responsibility
- 35. Single responsibility principle ▪ A class should have only a single responsibility ▪ Cohesive class has single responsibility
- 36. Single responsibility principle ▪ A class should have only a single responsibility ▪ Cohesive class has single responsibility ▪ When you say "this class does this AND that" you have violated SRP
- 37. Single responsibility principle ▪ A class should have only a single responsibility ▪ Cohesive class has single responsibility ▪ When you say "this class does this AND that" you have violated SRP ▪ Long methods are bad
- 38. Commenting
- 39. Commenting ▪ Comments are usually used to cover bad code
- 40. Commenting ▪ Comments are usually used to cover bad code ▪ When code is not self-evident refactor it
- 41. Commenting ▪ Comments are usually used to cover bad code ▪ When code is not self-evident refactor it ▪ Don't comment what, instead comment why
- 42. Commenting ▪ Comments are usually used to cover bad code ▪ When code is not self-evident refactor it ▪ Don't comment what, instead comment why ▪ A good code is like a joke
- 43. Commenting ▪ Comments are usually used to cover bad code ▪ When code is not self-evident refactor it ▪ Don't comment what, instead comment why ▪ A good code is like a joke ▪ Compose method pattern
- 45. Open-Closed Principle ▪ Two options - to make an enhancement 1. Change existing code 2. Add a small new module of code
- 46. Open-Closed Principle ▪ Two options - to make an enhancement 1. Change existing code 2. Add a small new module of code ▪ Nobody likes existing code
- 47. Open-Closed Principle ▪ Two options - to make an enhancement 1. Change existing code 2. Add a small new module of code ▪ Nobody likes existing code ▪ Software module should be open for extension but closed from modification
- 48. Open-Closed Principle ▪ Two options - to make an enhancement 1. Change existing code 2. Add a small new module of code ▪ Nobody likes existing code ▪ Software module should be open for extension but closed from modification ▪ Rely on abstraction and polymorphism
- 51. Liskov substitution principle ▪ Inheritance is overused
- 52. Liskov substitution principle ▪ Inheritance is overused ▪ If an object of B should be used anywhere an object of A is used then use inheritance
- 53. Liskov substitution principle ▪ Inheritance is overused ▪ If an object of B should be used anywhere an object of A is used then use inheritance ▪ If an object of B should use an object of A, then use composition / delegation
- 54. Liskov substitution principle ▪ Inheritance is overused ▪ If an object of B should be used anywhere an object of A is used then use inheritance ▪ If an object of B should use an object of A, then use composition / delegation ▪ Inheritance demands more from a developer than composition or delegation does
- 55. Liskov substitution principle ▪ Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program ▪ The user of a base class should be able to use an instance of a derived class without knowing the difference
- 57. Interface segregation principle ▪ Many client-specific interfaces are better than one general-purpose interface Alarm Clock PCPhone TV Rooster… Clock vs
- 58. Dependency inversion principle ▪ High-level modules should not depend on low-level modules. Both should depend on abstractions
- 59. Dependency inversion principle ▪ High-level modules should not depend on low-level modules. Both should depend on abstractions ▪ Abstractions should not depend upon details. Details should depend upon abstractions
- 61. Dependency injection pattern ▪ Dependency inversion ≠ dependency injection ▪ Dependency injection pattern is an implementation of Dependency inversion principle
- 62. Questions? Thank you Inspired by: Core Design Principles for Software Developers by Venkat Subramaniam
Editor's Notes
- #33: *Single responsibility principle* Cohesive class has single responsibility When you say "this class does this AND that" you have violated SRP Long methods are bad *Open-Closed Principle* Two options - to make an enhancement 1. change existing code 2. add a small new module of code nobody like existing code Software module should be open for extension but closed from modification Rely on abstraction and polymorhism *Liskov substitution principle* Inheretence is overused If an object of B should be used anywhere an object of A is used then use inheritance If an object of B should use an object of A, then use composition / delegation Inheritance demands more from a developer than composition or delegation does. “objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.” The user of a base class should be able to use an instance of a derived class without knowing the difference. *Interface segregation principle* many client-specific interfaces are better than one general-purpose interface Clock example Alarm ^ | __________________________________________________________ | | | ....... | TV Clock SPhone Wife *Dependency injection principle* A class should not depende on another class, they both have to depend on an abstraction (interface)
- #34: i.e. only one potential change in the software's specification should be able to affect the specification of the class
- #35: i.e. only one potential change in the software's specification should be able to affect the specification of the class
- #36: i.e. only one potential change in the software's specification should be able to affect the specification of the class
- #37: i.e. only one potential change in the software's specification should be able to affect the specification of the class
- #38: i.e. only one potential change in the software's specification should be able to affect the specification of the class