Writing S.O.L.I.D. Code

Writing S.O.L.I.D. Code

Object Oriented Principles

Writing code that is modular and scalable is not always easy. Often times, desired functionality occupies the focus of engineers that just want to code something that works. If it's functional, why change it? In the long run, refactoring working code to prepare for future changes will prove to be essential for both you as an engineer and the software itself. It will save time by avoiding inevitable hours spent rewriting code and debugging, and will uphold software performance moving forward. The refactoring I'm referring to involves adhering to the principles of SOLID object oriented programming and design. Follow these principles to write software that is extensible, and easy to maintain.

S ingle Responsibility Principle - A class should have only a single responsibility. Only one potential change in the software's specification should be able to affect the specification of the class. The class should totally encapsulate the piece of functionality it provides.

O pen/Closed Principle - Software entities should be open for extension, but closed for modification. Behavior should be capable of extension without changing the actual code. Extension may refer to, but is not limited to, entities being scalable and testable.

L iskov Substitution Principle - Objects in a program should be replaceable with instances of their subtypes without altering the correctness of the program. You should be able to replace any class 'Foo' with a 'Foo' subtype ('Fooish').

I nterface Segregation Principle - Many client-specific interfaces are better than one general-purpose interface. A client should not be forced to depend on a method it does not use, rather, it should only know about methods that pertain to it. Dynamically typed languages obey this by nature.

D ependency Inversion - A dependency should be passed to an entity that would use it rather than allowing that entity to build or find the dependency. Depend on abstractions, not concretions.

While following the principles of SOLID programming and design may initially seem inconvenient or gratuitous, adhering to them will make your life as an engineer a whole lot easier in the long run. Try to ask yourself a few questions as you design or refactor your code: Does it have one responsibility? Does everything in it change at the same rate? Does it depend on things that change LESS often than it does? Asking these questions and contemplating SOLID principles should give you insight into whether you are writing code that is extensible and easy to maintain.

--Alex DeLaPena