Embed Size (px)
Citation preview
Design Principles in a NutshellDmytro Panin & Anton Udovychenko
12.2015
Agenda
▪ What is a good design?
▪ Complexity and simplicity
▪ KISS
▪ YAGNI
▪ Cohesiveness and coupling
▪ SOLID
▪ Q&A
Good design
▪ Design is good when a cost of changing of a design is minimum
Good design
▪ Design is good when a cost of changing of a design is minimum
▪ Easy to change
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
How to make a good design?
How to make a good design?
▪ Let go of the ego
How to make a good design?
▪ Let go of the ego
▪ Be unemotional
How to make a good design?
▪ Let go of the ego
▪ Be unemotional
▪ Do code reviews
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
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
Complexity
▪ Inherited from a domain
▪ Accidental complexity
KISS - Keep it simple and stupid
What is simple?
What is simple?
▪ Simple makes you concentrated
What is simple?
▪ Simple makes you concentrated
▪ Simple resolves only actual issues we know about
What is simple?
▪ Simple makes you concentrated
▪ Simple resolves only actual issues we know about
▪ Simple fails less
What is simple?
▪ Simple makes you concentrated
▪ Simple resolves only actual issues we know about
▪ Simple fails less
▪ Simple is easier to understand
Simple is not necessarily familiar.
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.
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.
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.
Cost of implementing
Smart Smarter Much smarter
Now correlation Later Result
X > Y Postpone
X == Y Postpone
X < Y ?
Do not confuse postponement and procrastination
Coupling
▪ Coupling is what you depend on...
Coupling
▪ Coupling is what you depend on...
▪ Inheritance is the worst form of coupling
Coupling
▪ Coupling is what you depend on...
▪ Inheritance is the worst form of coupling
▪ "knock out before mock out“
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
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
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
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
SOLID
▪ Single responsibility principle
▪ Open-Closed Principle
▪ Liskov substitution principle
▪ Interface segregation principle
▪ Dependency inversion principle
Single responsibility principle
Single responsibility principle
▪ A class should have only a single responsibility
Single responsibility principle
▪ A class should have only a single responsibility
▪ Cohesive class has single responsibility
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
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
Commenting
Commenting
▪ Comments are usually used to cover bad code
Commenting
▪ Comments are usually used to cover bad code
▪ When code is not self-evident refactor it
Commenting
▪ Comments are usually used to cover bad code
▪ When code is not self-evident refactor it
▪ Don't comment what, instead comment why
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
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
Open-Closed Principle
Open-Closed Principle
▪ Two options - to make an enhancement1. Change existing code
2. Add a small new module of code
Open-Closed Principle
▪ Two options - to make an enhancement1. Change existing code
2. Add a small new module of code
▪ Nobody likes existing code
Open-Closed Principle
▪ Two options - to make an enhancement1. 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
Open-Closed Principle
▪ Two options - to make an enhancement1. 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
Liskov substitution principle
Liskov substitution principle
▪ Inheritance is overused
Liskov substitution principle
▪ Inheritance is overused▪ If an object of B should be used anywhere an object of A is used then use inheritance
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
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
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
Interface segregation principle
▪ Many client-specific interfaces are better than one general-purpose interface
Alarm
Clock PCPhone TV Rooster…
Clock vs
Dependency inversion principle
▪ High-level modules should not depend on low-level modules. Both should depend on abstractions
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
Dependency injection pattern▪ Dependency inversion ≠ dependency injection
▪ Dependency injection pattern is an implementation of Dependency inversion principle
Questions?
Thank you
Inspired by: Core Design Principles for Software Developers by Venkat Subramaniam
