How many design principles are there?

- [Narrator] Unlike design patterns, for which we have standard catalogs that document our patterns, there are no standard catalogs for design principles. When talking to other developers about design principles, you'll often find the principles they know about are influenced by really the domain that they work in. So architects will favor one set of principles, enterprise developers say another set, web developers another, and so on. That said, there are a set of principles that we really consider the bread and butter of principles. And they are, encapsulate what varies. This principle tells us that if we have part of our design that is changing, say with every new requirement, well then we should encapsulate that part away from the rest of the design. Favor composition over inheritance. This principle warrants against the overuse of inheritance and suggests composition as a powerful alternative for extending behavior in our designs. Program to interfaces not implementations. This principle encourages us to keep our designs high-level and referring where possible to abstractions or interfaces and not concrete implementations. And the loose coupling principle, which tell us to strive for loosely coupled designs between objects that interact. We're going to examine all these bread and butter principles in detail in this course. Now there's another set of principles known as the SOLID principles, which were introduced by the software engineer Robert Martin. SOLID is an acronym that's made up of the first letter of each of these principles. And those are S for the single responsibility principle, which says that a class should have only one reason to change. The Open principle, a counterintuitive principle which says that classes should be open for extension but closed for modification. L, the Liskov substitution principle which strives to have subtypes that are substitutable for their base types. The Interface segregation principle. This principle encourages us to keep our interfaces small and cohesive, and we'll talk about what cohesive means. And finally, D the Dependency inversion principle which says that high-level modules should not depend on low-level modules. Actually, both of them should depend on abstractions. And we're going to cover all these principles as well in this course. Now you won't find all these principles the very last word on design principles, but these principles are a very good start to building your design principle repertoire. You're going to encounter a few others out there, but over time we've really settled on a dozen or so of these principles that developers really consider important.