Object-oriented design: Identifying an inheritance situation | lynda.com tutorial


Uploaded by lynda on 22.05.2012

Transcript:
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.