Review of terms - Python Tutorial

- [Instructor] There are some terms and concepts that I want to cover before we get started to ensure that we're all starting on the same page. Even if you're familiar with these, it will be worth understanding how I'm using some of these common terms in this particular course. When we're talking about software design, we often hear about design principles and design patterns. Design principles are general high level guidelines. They support better design for flexibility and maintainability. SOLID is often cited as a great starting point for understanding object oriented design principles. There is also DRY. Don't repeat yourself and YAGNI, you ain't going to need it. Don't add layers of architecture or functionality that only might be necessary in the future. There's lots of acronyms for these things as it makes it easy to remember them. And this certainly isn't a complete list of software design principles. If you're not familiar with these principles, it is worth spending some time studying them. As we move through the course, you'll be able to see how our pattern implementations often fulfill these design principles. In cooking terms, you could think of design principles as the ingredients and flavors that compliment one another, or that dessert should come at the end of the meal. Design patterns are things that are common among several recipes, like how to grease a pan or mixing the dry ingredients before adding the wet ingredients. Design patterns are not as prescriptive as a recipe. They're not meant to be followed exactly, but combined in new ways to get the desired architectural outcome. An interface is a description of the services that a class provides, like the menu at a restaurant. It is what's available when using a particular class. I'm using a lot of food analogies. I might need to stop for lunch. All classes have an interface, whether they are specified and separated out or not. Separating out an interface allows you to think about what that class should be doing and how it interacts with the application around it. You don't need to do it all the time, but it often helps apply the design principles that we just mentioned. In object oriented programming, the difference between the type of an object and the instance of the object is significant. It is the difference between the description or even the drawings of a real thing, and the thing itself. The plans to build a bed and the bed that I can actually sleep on. There's also the difference between a class and a type that's a little bit more technical. Classes are the full description of an object that can be created. A type is an interface that the class fulfills. Often class and type are interchangeable, but a single class can be many different types at the same time. Types can be composed into classes. As an example, a modern cell phone has a lot of functionality. It has the type of phone so that I know I can send and receive calls. It also has the type of music player and the type of entertainment device. The class that composes all these types is smartphone. This is a fundamental concept that we'll run across, as we talk about some specific design patterns and what it means to implement them. I'm going to be using the terms concrete and abstract. Some to talk about classes and objects. An abstract class is one that has some functionality, but that functionality is not complete without a class that inherits from it, implementing it. A concrete class is one that can actually be instantiated, constructed and used. Now we have some common language to help us talk about design patterns.