SOLID principles for Object Oriented Programming, with LIQUID and GAS

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:

• 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.