Tuesday, September 17, 2019

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.


No comments:

Post a Comment