The Dependency Inversion Principle brings us to the conclusion of studying the five solid design principles which hail from Bertrand Meyer, Barbara Liskov, Robert Martin, and Tom DeMarco, among others. If these five articles have your head spinning, fear not. We’re dealing with abstractions, and abstractions can start to play tricks on your mind after a while. Learning about these design patterns are a great way to practice your craft.…

The Interface Segregation Principle is the next stop on our tour of the 5 solid principles. Thankfully, it’s a pretty easy one to understand. All it means is that a client should not be forced to implement an interface that it will never use. This is the main idea of the Interface Segregation Principle. Just like the rest of the five solid design patterns, the Interface Segregation Principle exists to help decouple modules within software and make the code easier to understand, refactor, and maintain.…

We’re moving forward with our study of the SOLID design principles, and now we have made it to the L. The L stands for Liskov Substitution Principle or LSP and is named after the creator of the principle, Barbara Liskov. The formal definition is very verbose, so in this tutorial, we will cover the topic as if we are writing the first draft for the book, “The Liskov Substitution Principle For Dummies.” Let’s learn a bit more about this principle now.…

The Open Closed Principle is another concept in our study of the solid design approaches in the object oriented style. You may have heard the idea that code should be open for extension but closed for modification. Ok. Really what this means is that when writing code, we should aim for the ability to change behavior without having to actually change the code. Another way of saying this is to program in a way so that the code does not need to be changed each time the requirements of the project change.…

The Single Responsibility Principle focuses on the concept of keeping a function, method, or class, focused on a narrow behavior that it does well. When we think about a given API, we can say it is a good API if it does one thing and never changes. Now when we say API, we really are referring to any function, method, or class however all of this holds true for the more traditional thinking of what an application programming interface is.…