Back To Basic : SOLID, DRY and KISS
- One class should have one and only one responsibility.
- This concept will give you the flexibility to make changes in the future without worrying the impact to another class.
Open Closed Principle
- A class should be open for extension but closed for modification.
- The “closed” part mean the module/class should only adjusted to correct bugs.
- The “open” part mean fellow developer should be able to extend existing code in order to introduce new functionality.
- Fellow developer should be able to override the options by software in un-harmful way permitted by software.
Liskov Substitution Principle
- Liskovs Substitution Principle states that any method that takes class X as a parameter must be able to work with any subclasses of X.
- Subtypes must be substitutable for their base types.
- A subclass should override the parent class’ methods in a way that does not break functionality from a client’s point of view
Interface Segregation Principle
- A Client should never be forced to implement an interface that doesn’t user or clients shouldn’t be forced to depend on methods they do not use.
- ISP states that interfaces that have become “fat” (like god classes) should be split into several interfaces. A large interface makes it harder to extend smaller parts of the system.
Dependency Inversion Principle
- Entities must depend on abstraction not on concretion.
- It states that the high level module must not depend on the low level module, but they should depend on abstraction.
D.R.Y (Don’t Repeat Yourself) Principles
- Don’t write duplicate code.
- Use abstraction to abstract common things in one place.
- If you have block of code in more than two place consider making it separate method.
- If you think fellow developer will need the same method in the future (depend in the context of business flow which you implement), consider making it as component or utility class.
- If you use a hard-code value more than one time make them public final constant.
- Duplication not for code, but functionality.
K.I.S.S (Keep It Stupid Simple or Keep It Simple, Stupid)
- Meaningful and clear name (adjusted in functionality and business context).
- Break down your problem into many small problems.
Keep your method small.
- Each method should only solve one little problem, not many use case.
Don’t afraid refactor your code, over and over again (ps. If you still have time).
- Don’t afraid to throw away code.
Sometimes you will find the principle collide each other and you also must considering the impact of your code in the system performance, you can do a mistakes but don’t break things.