Conclusion

In the last demo, you learned about the fifth SOLID principle, Dependency Inversion. You updated the calculator project from demo 1 to depend on an abstract logger rather than the concrete LogManager. You covered a lot of ground in this lesson.

SOLID principles are guidelines to help you plan for the future. You can implement them in different ways. They aren’t instructions like design patterns, which are focused on solving a specific technical challenge.

Here are the things you learned in this lesson:

• Liskov Substitution principle is a guideline that says when you implement new child types, they must not perform operations that the base class doesn’t expect. Child types can operate differently, but if the system and the base class expect specific operations like saving data, activating another module, or delivering output, the child types must adhere to those expectations.

• Interface Segregation principle is similar to the Single Responsibility principle, except that it is used to design interfaces (protocols). Methods defined in an interface should be related to one another. If you have methods that aren’t relevant to the rest of the interface, it’s best to separate them into their own interface.

• Dependency Inversion principle creates abstraction and decoupling between the different parts of the system. If one module requires a direct integration with another module to operate, then this integration should be done through interfaces and not via concrete types. This allows you to modify and control the different modules without affecting the rest of the system.

By using SOLID practices, you will create programs that are easier to read, easier to maintain and less likely to have bugs.