Understanding the SOLID principles

Last week we listened to a podcast where Bob Martin was interviewed about software craftsmanship and techniques to make coding better. He also developed 5 principles he recommends to enhance object oriented programming, which are the following:

• Single Responsibility Principle: This is that the class we are working with, needs to be useful for one thing and one thing only. In a previous text, we learned that we could use compositions to avoid making several things on one class. The theory is easier to grasp than the practice. In practice, you must rely on experience and common sense. Not following this practice may end up in a developer really frustrated trying to understand what the class is doing.
• Open/Closed Principle: Any class should be open for extension but closed for modification. For that we probably need the skills Bob mentions on the past article, so we gain experience with making code difficult to break, and at the same time, be accessible, easy to understand and introduce new functions and features. The principle means that when adding new behavior you should leave base classes alone and instead create new, inheriting classes
• Liskov Substitution Principle: This principle is in charge of  keeping the happy working relationship between classes and functions alive and well, when one class inherits from other. Experience tells us that changing the behavior of a class in many cases leads to problems elsewhere in a code base. It is another example of how you should strive to minimize dependencies of all kinds in the interest of writing robust and maintainable software.
• Interface Segregation Principle: Avoid writing huge interfaces that give classes a lot responsibilities they don’t need or want. The developer needs to have the ability to instead create a collection of smaller, discrete interfaces, partitioning interface members according to what they concern.
• Dependency Inversion Principle: This principle means is that instead of writing code that refers to actual classes, the developer should instead write code that refers to interfaces or perhaps abstract classes.