Object-orientation has four key concepts, and inheritance is one of them. Inheritance brings the idea of relationships and connections, such as class and subclass or child-class, into programming languages. Follow along with this online video to learn the details of identifying inheritance situations.
- View Offline
Earlier we talked about inheritance being one of the four key concepts of object-orientation. We're going to get a little deeper into it now. Even if you never wrote your own classes that used inheritance, you will still use it. In most object-oriented languages, you're using inheritance all the time, there's no getting away from it. Now, the best simplest easiest way of identifying an inheritance situation is with two words, "Is A". Inheritance describes an "Is A" relationship, and this is not a technical term, this is plain language.
We're back to the idea of how would you talk about things in the real world? So, forget about classes and objects for a second and just look at a few sentences. So could you say something like a car is a vehicle? Well, yes! How about a bus is a vehicle? Well, yes. That makes sense too. But what about a car is a bus? Well, no, you wouldn't say that. You would say something like an employee is a person or a customer is a person.
Those make sense, but a customer is a shopping cart does not. Instead of just is a, you could say is a kind of or is a type of, but it's the same thing. So, a checking account is a kind of bank account, a savings account is a type of bank account. We naturally understand these ideas. We can talk like that. We know what makes sense and what doesn't. We know that we can have multiple levels of this, a Bentley Continental is a car which is a vehicle, a Pomeranian is a dog which is a mammal which is an animal.
An inheritance is taking this idea, this form of abstraction that we do naturally in font and language, and it's bringing it into programming. It's to allow us to identify that there might be some shared attributes and behaviors between our objects, and if we think about it, we can save some time and not reinvent the wheel. So here's where some people hit their first problem. They start sketching out a variety of classes, picking the nouns out of their written descriptions, and as we scan it, we can tell there's some relationship between say Bank and Bank Account, and we wonder well is that an inheritance relationship? And there is the question. Could you say a bank account is a bank? Well, no, you wouldn't say that, neither would I say a bank is a bank account.
So there might be a relationship here, but it's not inheritance. But you could say a checking account is a bank account or a savings account is a bank account, and it's a clue that we might be able to share some behavior in this area. But it's always that is a question. That should make sense when you talk about it in natural plain language. In UML, inheritance is shown with the open arrow that looks like a wedge, one class points to the object it is inheriting from, otherwise called its superclass or parent class.
And as soon as we say we're inheriting, we are considered the subclass or the child class, and we automatically have all the attributes and behaviors from the class we're inheriting from. So, in this case, BankAccount is the parent class or the superclass, CheckingAccount, SavingsAccount, InvestmentAccount, these are classes that would be considered subclasses or child classes. We bring in all the attributes and behaviors from the superclass, from the parent class, and then we can start adding some extra information.
Sometimes we may want to change one of the behaviors we inherit from the superclass, and many languages allow a subclass to replace the implementation of a method defined in that super or parent class, and this is called overriding, and it lets us have more flexibility. Most commonly, it's not just to replace but to do some behavior in addition to the inherited behavior. Now, a word of warning, it is common for new object-oriented developers to overemphasize inheritance and to come up with class diagrams with five levels for everything. Avoid this.
Don't go looking for inheritance and don't stare at classes trying to figure out what their superclasses must be, because inheritance announces itself. You start building your classes for say a digital storefront, and you start creating things like album and book and movie. You will notice if they start sharing a lot of common behaviors and attributes, say in this case, we realize that we're sharing title and price as attributes and purchase and download as behaviors. So you may then create a superclass trying to identify what's common between them all while they're all products, and we'll create that.
We'll strip out the similar behaviors, and put them in that superclass, in that parent class. So, we can identify and choose that commonality, and then we will inherit from that class, but it should be obvious. Now sometimes it will be identified from the bottom-up, sometimes from the top-down, you'll realize you have to create some more specialized classes. But let it occur naturally, and if you create one or two class diagrams without any inheritance, that's not a problem. But do realize that inheritance is often vitally important in understanding existing object-oriented programming environments, because the frameworks that you'll use in Java.NET, Objective-C, Ruby, and others often use inheritance substantially, because they're trying to provide generic and extensible frameworks rather than writing a specific application.
In Java, for example, there is a built in FileDialog class which we can use. Well, it inherits from a Dialog class which inherits from the Window class, which inherits from the more generic Container class which inherits from the Component class, which inherits from the most generic base Object class. In fact, everything in Java inherits from Object at the end of the day, same with a lot of other languages, Objective-C, C#, VB.NET.
Even if you don't say you're actually inheriting, you always are. You're inheriting from something usually called Object, a base Object class, and that's what I mean about the fact that you're always inheriting, even if you don't say so. However, even though you'll find this level of inheritance in some of the frameworks you'll use, it's very unlikely for a specific business or consumer application to need anything like this level of inheritance. In fact, you should look very carefully even if you're going beyond one or two levels of inheritance.
And up next, I'm going to show a few examples of how we might go ahead and implement that in a language.
Let Simon Allardice introduce you to the terms—words like abstraction, inheritance, polymorphism, subclass—and guide you through defining your requirements and identifying use cases for your program. The course also covers creating conceptual models of your program with design patterns, class and sequence diagrams, and unified modeling language (UML) tools, and then shows how to convert the diagrams into code.
- Why use object-oriented design (OOD)?
- Pinpointing use cases, actors, and scenarios
- Identifying class responsibilities and relationships
- Creating class diagrams
- Using abstract classes
- Working with inheritance
- Creating advanced UML diagrams
- Understanding object-oriented design principles