The SOLID Architecture
OBJECT ORIENTED PROGRAMMING
Object Oriented programming relies on objects to solve whatever problem the developer is currently facing. Objects are created, or instantiated, from files called classes. Classes are blueprints that describe what an object is ‘made of’ and how this object will ‘interact’ with the outside world. How well these classes are defined is often the most weighty factor in determining your code’s elegance and efficiency.
SOLID is an acronym to help developers create classes that are maintainable and extendable. Each letter stands for a design principle that should be followed when writing a class for an object oriented project.
S is for Single Responsibility Principle.
I like to imagine a programmer yelling at an overzealous class, exclaiming “You had ONE job!”
Each class should have only one job. If a class has to juggle multiple responsibilities, that means it has to be adjusted any time one of it’s many responsibilities are updated or changed. A class should only be maintained for a single purpose.
O is for Open Closed Principle.
I think marriage is a good analogy for this one. Your family is open to extension, i.e. with puppies and children, but closed for modification, i.e. changing out your spouse.
Each class should be ‘customizable’ with extensions, but unable to be changed. All of the initial characteristics of the base object should remain inherent to any future “modified” object that is designed.
L is for Listov’s Substitution Principle.
In a mall, you don’t want to have one store that utilizes the barter system, while another accepts IOU’s for their products. You want all of your malls and all of your stores inside the malls to use currency systems.
Same thing with Listov’s Substitution. (If ‘Listov’ throws you off with this one, just concentrate on the ‘Substitution’ part.) Following this principle just ensures that objects of your subclass have the same ‘behavior’ as objects of your super-class, which is actually an extension of the above principle. You should be able to substitute these objects for each other without totally throwing off your whole program.
I is for Interface Segregation Principle.
This principle is analogous to the difference in how you would describe your work day to your partner versus your boss. Disclosing the emotional ups and downs of your office job to the person who loves you unconditionally is very different than describing deliverables and meeting notes to the person that has the power to fire you; one does not need to share certain information to parties that are not concerned with such.
Similarly, if a developer is creating interfaces that are to interact with a student object, then the designer doesn’t need to include a medical school personal statement method in the non-graduate degree seeking student interface. Instead, create a whole separate interface for students seeking a medical degree after undergraduate studies. That way, objects are only utilizing information that is relevant to them, which also capitalizes on the principle of least privilege (bonus!).
D is for Dependency Inversion Principle.
Which relates to my first article (: When I start my car, I definitely do not care that I am actually turning the crank-shift to start moving the pistons so that the spark plugs fire. I just care that my car engine is running.
Same thing with classes. A Vehicle class should not depend on a TurnCrankShift, MovePistons, and FireSparkPlugs class, but on higher level abstractions such as an Ignition class that then can further specify how your vehicle starts. This abstracts the (possibly unique) implementation details and allows different motor vehicles to extend the Ignition class. Developers who utilize this principle are aware careful not to specialize their classes too much, in order to maintain code re-usability.
Thanks for reading my take on SOLID! Comment with questions/helpful remarks or edits.
