In Object oriented programming, the SOLID principles play an important role in designing the solutions and structuring the code.
For a quick recap, below is what SOLID briefly stand for:
But solid also happens to be a state of matter. To make matters fun, here are 2 more acronyms that can be used in software development, to complete the three commonly found earthly states of matter :)
LIQUID
For a quick recap, below is what SOLID briefly stand for:
- S - Single-responsiblity principle: A class should have one job, and only one job.
- O - Open-closed principle: Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification
- L - Liskov substitution principle: Every subclass / derived class should be substitutable for their ancestor classes
- I - Interface segregation principle: No client should be forced to depend on methods it does not use.
- D - Dependency Inversion Principle:1) High-level modules should not depend on low-level modules. Both should depend on abstractions (e.g. interfaces). 2) Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions
But solid also happens to be a state of matter. To make matters fun, here are 2 more acronyms that can be used in software development, to complete the three commonly found earthly states of matter :)
LIQUID
- L - Learnability: The program/module/class/method should support enhanced learnability of anyone using / extending it
- I - Input validation: All inputs must be validated to avoid any security and other bugs
- Q - Quality control: Code should be structured so that ways to keep checks on regression and maintain strict quality can be easily ensured. i.e., tech debt should be kept within viable limits
- U - Understandability: Code is modified and debugged more number of times than freshly written, and it must thus be easily understandable for the next person. Conventions needs to be followed consistently
- I - Integration: Code in isolation is limited in the impact it can have, and so must be so structured to promote easier integration within other projects / modules etc.
- D - Defect averse: defects have a way of creeping in, so code should be properly tested and structured in a way to minimise code smell and defects.
GAS
- G - Great readability: Code is read a lot more than it is written, and to save time, should be readable.
- A - Avoid Anti-Patterns: While using design patterns and other strategies is good, one must know when to avoid the common anti patterns
- S - Security promoting: Unsafe security practices should be avoided at the offset. As Mad eye moody says, Constant Vigilance is the way to avoid security nightmares.