Checking your code for S.O.L.I.D.

Every programmer knows or should know the S.O.L.I.D principles. But i must admit i have to revisit them every year or so to freshen up what they were all about. Some general rule of thumb to check your code would be handy.

S stands for Single Responsibility Principle. This means a peace of code should only be doing one thing. An easy indication we are not S.O.L.I.D. to this aspect is if our class gets to large or our interface has to many methods. Time to clean up and refactor specific responsibilities into separate code.

Rule of thumb: is this class doing to much work?

O stands for the Open Closed principle. This means open for extension but closed for change. Opinions may differ but to me this means keeping the actual work behind private members with a single protected entry point to be called from a public member function. Even better is to create an abstract class and a separate implementation. Many public methods in a class should give a strong indication you are on the wrong path here.

Rule of thumb: can i abuse this class to do something it was not meant for?

L stands for a difficult name i just cant remember, Liskov substitution principle.In general this means that all functionality implemented in a base class must be implementable and make sense in any derived class. I believe this is somewhat related to the Single Response Principle. A class with to many responsibilities becomes problematic when inherited from. This can be helped by creating an additional layer in your inheritance and moving methods up a level.

Rule of thumb: Do all methods in my base class make sense for my derived class?

I stands for Interface Segregation principle. This simply states that interfaces should be kept to a bare minimum. Again to me this very much comes down to the Single Response Principle. If i were to ignore this principle i could easily build a huge class implementing a large set of small interfaces and still comply with the interface segregation principle. Better to forget about interfaces and simply look at all public methods available in your class. Keeping its number down to just a few should keep you in the clear.

Rule of thumb: Do i have to many public methods in my class?

D stands for Dependency Inversion Principle. Here we want to make sure a class does not depends on a specific implementation of some other class. We provide our implementations with interfaces and use these in stead when constructing depending instances. To me this is probably the most important of all S.O.L.I.D. principals but also not possible without the ones mentioned above. Without closely observing the other principles me might wind up with a a complex difficult to maintain dependency hierarchy.

Rule of thumb: Are all my constructor parameters interfaces?

All rules of thumb in a nutshell:

Make sure your class is small and has just a limited number of public methods and all methods make sense for derived classes. Make sure it has an interface with the same signature as your public methods and use only this interface in the rest of your code. Make sure it only uses interfaces in its construction and apply proper means for instantiation ( e.g. dependency injection ).

Tip: Writing Unit Tests helps you in writing S.O.L.I.D. code . Small classes with less responsibilities are easier to test since you wont need to write many tests to cover all code and using interfaces allows you to mock dependencies and thereby give your component a more predictable setup . Before creating new implementations of a given base class you can inspect your existing tests to see if all methods make sense. And you will have your tests to rely on when refactoring your code to become even more S.O.L.I.D..