Dear Readers, This post marks the beginning & is an introduction of our series on SOLID principles.

There are already countless articles/youtube videos on the SOLID principles & this begs the question that – Is another series on SOLID principles still needed?              Most of the pre-existing videos & articles(if not all) treat the SOLID principles by discussing the implementation details of these principles. They focus on answering the question – “How are the SOLID principles implemented?” and often omit or avoid answering the question – “Why do these SOLID principles even exist and what pain points can they address beyond pure code?”. A gullible reader may now think that the answer of the second question is obvious & is in terms of code maintainability, scalability, reusability and testability. But if that is the case, then how come there still exists production code which defies all those principles and is still solid 😉. For example, this View class in the Android Source code which is ~31,990 lines long & has multiple responsibilities (I stopped counting after 5), or, if the previous class is too much then how about this BleManager class, within a well known library for bluetooth communication which is ~2195 lines long & is responsible for, –  

• Managing the bonding process.
• Connection handling.
• Requesting data reads.
• Requesting data writes.
• Managing the queuing the of read/write requests.

Single Responsibility Principle, anyone?                                                                                                                                                                                                                                And, these are just some of the many examples. This also hints that we may need to discuss these principles beyond just the implementation details to uncover if there is more than what meets the eye or is it all just a farce.

Also, one may often tend to avoid or skip answering the question – “Why do these principles even exist”, due to the obscure nature of the formal definitions of these principles. Just as a personal opinion, most formal definitions are like icebergs in the sense that that they do not expose the underlying concept that a principle is designed to explain. In other words, they leave a lot of room for interpretation.

This series will adopt a slightly different approach to the SOLID principles by avoiding discussing these principles following their formal definitions or implementation details. Instead, it will take a bottom-up approach – we will first try to identify the problem that a principle is designed to address and only then discuss the definition. Once after we have identified the underlying problem, discussed the definition, only then will we demonstrate the principle itself using an example.

So without anymore wait, let’s attempt to analyse the most simplistic seeming SOLID principle – Single Responsibility Principle.