I’ve used SOLID, KISS and bunch of other design principles in my career. They are all great, and serve a diverse world. But i’ve found people to stick to one of these principles a bit too tightly, almost to the point of suffocation. I am a very passionate object oriented paradigm user and always on the look out to explore new ways to implement it with a pragmatic approach. There in lies the problem, pragmatism. SOLID is great but expensive to have. KISS is just way to broad and up for interpretation. So how do we go about this? Lets do both! First we have to understand what object oriented is all about. The basis of object oriented design is to model real world objects in our code. How they interact and function – all of it. Taking that as a basis, we can say that real world problems, simplicity, incremental changes also apply to the design.
SOLID is expensive because it states from the very beginning to separate out each and everything where possible. I love SOLID, I think its the only way to avoid coupling of code. Coupling – the biggest evil there is in the programming world. But at the same time, this bloats the code very quickly. You may very well do this, but you’d be spending a significant amount of time just naming things. After all, naming things is just simply THE most difficult task in the programming world. So how about mixing it with KISS?
KISS stands for keep it simple, stupid. Its not a design paradigm but you can see why its up for interpretation. What is simple? A person proficient in SOLID will define SOLID as simple. A person who likes procedural programming will define that as simple.
Everything boils down to the design. How much code it contains is directly proportional to the complexity of the class. Here is what I propose. Lets take an example of a person who has just started a company. He is the only person in the company acting as director, but at the same time he handles Accounts, IT, Human resource and Product departments. Your application will require actions to be performed on all of these departments.
class App
{
public function handleAccounts(HumanResource $accounts)
{
...
}
}
Now you can go ahead and implement all of this in SOLID and create 5 classes that represent the above which the person will use or you can use the all amazing interfaces to make your life easier and do this:
class Person implements Accounts, IT, HumanResource, Product
{
public function ...
}
By doing the above, you’ve defined all the roles your application expects using interfaces. This means, you can choose to evolve your application slowly as it would happen in the real world. You won’t reserve a room for Accounts, HR, IT, Product if you’re the only one doing it. But the roles exist never the less so your code should follow those rules. At this stage you can pass in the Person object into the application method above because of the interfaces you’ve implemented. It may just even throw an exception since you don’t have a HumanResource need but the role exists. When you’re ready, extract the HumanResource functionality into another class.
class HR implements HumanResource
{
...
}
Name it better! Than move all your Person HR logic into this class, and just inject this method instead of Person in your application. Done SOLID and KISS! There is more to SOLID than this, but this is a good baseline to follow. If you have auto-wired DI, this is a piece of cake. All you have to do is change the injected object instance based on the interface type hint reference.
Use interfaces to there full potential, they are amazing creatures living amongst us!