Overview of the SOLID principles - Python Tutorial

- [Instructor] I want to summarize the SOLID design principles before digging into the details of each principle. Here are the overall goals for SOLID. First to prevent problems by giving explicit guidance on design problems that we may not always anticipate. Second to distinguish style from substance. There are fundamental design approaches that will lead to better software. Here are the five design principles that form a handy acronym, single responsibility, open/closed, Liskov substitution, interface segregation, and dependency inversion. It's important to note these five aren't the only OO design principles. I'll touch on some others. The don't repeat yourself principle urges a coder to avoid copying and pasting duplicate code. I'll also reference the GRASP principles for guidance on allocating responsibilities to classes and modules. This is is a collection of brilliant ideas for locating the single responsibility that underlies the SOLID principles. Test driven development can also help create SOLID design. Creating isolated unit tests for a class tends to reinforce the SOLID design principles. These principles are not a simple recipe for class design. The principles overlap each other in a number of ways. They have different points of view. Some of these principles look closely at coding techniques where others look at higher level design considerations. SOLID is an aid, not a rigid formula. As part of demonstrating each principle, I'll show several alternative implementations of the same classes. The question of which is right or which is best may come up, but the question is moot. There'll always be alternative designs for a class. Some designs have higher performance. Others use less memory. None of the alternatives is trivially best but some are more SOLID than others. The SOLID principles will help a designer articulate why one design is superior to the alternatives. These principles will say nothing about a large number of software engineering issues. SOLID doesn't specifically address resource use, performance, security, deployment, support, licensing or a host of other design considerations. The SOLID principles are focused on the ripple effects from change and how well software fits the intended use. I'm not going to show the SOLID principles in mnemonic order. And while the order poetic, it's not really pragmatic. I'm going to start with the interface segregation principle. Classes should depend on the smallest interface. This seems to be the most helpful way to start designing a good class. This principle helps us to write unit test cases also. After segregating the interfaces, it helps to look at common code. The common code can become a super class and the special cases can become subclasses. The Liskov substitution principle suggests that subclasses must be able to replace their parent classes. When a design calls for polymorphic peer classes, this principle can be applied to each one of the peers. A class needs to be open to extension. There should be no reason to modify the code. I find the open/closed principle helps to define what features of a class need to be exposed. A good class can be extended and making code modifications by endlessly tweaking the class can be avoided. The dependency inversion principle is focused on packaging the code. Some languages have tools and frameworks help implement this and other principles help design the classes properly. But this principle makes sure that references avoid concrete class names. The principles related to the concept of late binding defer making connections among components until the application is running. And finally, the single responsibility principle. This is a kind of summary of the other four principles. After applying the other principles the resulting class often has only one reason to change. The single in the name can be confusing because it's not clear what level of should be used nor how the responsibilities are counted. But the GRASP principles will often help define single in a meaningful way. There are five core design principles. These principles will help articulate reasons why the initial design for my core was so bad and they provide concrete guidance on good ways to design classes and modules and Python packages.