Make fine grained interfaces that are client specific. Robert C. Martin Welcome back to the series on SOLID. By now, I’ll assume you’ve read my earlier post on the Liskov Substitution Principle. The guts of this principle is that your interfaces should be very specific to the purpose. You shouldn’t have a super interface or […]
Derived classes must be substitutable for their base classes. Robert C. Martin Welcome back to the series on SOLID. By now, I’ll assume you’ve read my earlier post on the Open/Closed Principle. This principle is quite an obvious principle. I’m going to use the time-and-time-again Duck example below. Think: If it looks like a duck, swims […]
You should be able to extend the behavior of a system without having to modify that system. Robert C. Martin Welcome back to the series on SOLID. By now, I’ll assume you’ve read my first post on the Single Responsibility Principle. That is, each class should only have one responsibility (or a class should have […]
A class should have only one reason to change. Robert C. Martin I’m going to start a five blog post journey about the five principles behind SOLID. I’ll describe these in my own words and give examples of what breaks the rule and how to fix it. Now, what I’m not going to prescribe, is […]
