1
00:00:05,520 --> 00:00:07,960
In this video, we'll see what
inheritance is all about.

2
00:00:08,990 --> 00:00:13,000
In object orientation, inheritance
provides a method of creating new

3
00:00:13,030 --> 00:00:15,049
classes from existing classes.

4
00:00:15,809 --> 00:00:20,240
These new classes contain the data
and behaviors of the existing classes.

5
00:00:21,070 --> 00:00:26,340
So as you can see that allows us to
reuse or inherit data and behaviors

6
00:00:26,349 --> 00:00:30,450
that already exist, more importantly
where we're reusing behaviors that

7
00:00:30,450 --> 00:00:33,949
have been tested and have already
been used in existing applications.

8
00:00:34,809 --> 00:00:37,820
That's great, but it wouldn't be
very useful if I only inherited

9
00:00:37,830 --> 00:00:39,480
data and behaviors and that's it.

10
00:00:40,070 --> 00:00:44,010
But with inheritance, we can modify
the behaviors however we'd like to

11
00:00:44,010 --> 00:00:46,129
make our newly created classes unique.

12
00:00:46,679 --> 00:00:49,969
So the new class is based
on an existing class, but we

13
00:00:49,969 --> 00:00:52,890
can tweak it so that it does
exactly what we want it to do.

14
00:00:53,549 --> 00:00:56,440
And we can do this without
modifying the source code of the

15
00:00:56,440 --> 00:00:57,930
original class we're reusing.

16
00:00:58,420 --> 00:01:02,319
This is important since that class has
already been tested and it's probably

17
00:01:02,330 --> 00:01:04,330
being reused by other applications.

18
00:01:04,388 --> 00:01:06,479
So we really don't want
to modify it at all.

19
00:01:07,450 --> 00:01:09,369
Of course, inheritance
must make sense.

20
00:01:09,490 --> 00:01:12,929
We don't want to reuse a class
employee and create a new class

21
00:01:12,960 --> 00:01:16,430
planet that contains the data
and behaviors of an employee.

22
00:01:16,830 --> 00:01:19,880
Let's see some examples of
classes that are related somehow.

23
00:01:23,280 --> 00:01:26,530
In many applications, when you're
designing your solution, you can

24
00:01:26,530 --> 00:01:30,360
identify classes in your application
that are related to one another.

25
00:01:30,969 --> 00:01:33,710
Sometimes the relationship
is clear, and other times the

26
00:01:33,710 --> 00:01:35,330
relationship might be less clear.

27
00:01:35,920 --> 00:01:38,700
This slide provides some
examples of related classes.

28
00:01:39,400 --> 00:01:43,229
In a game application, we might
have player, enemy, level boss,

29
00:01:43,240 --> 00:01:45,240
hero and super player classes.

30
00:01:45,920 --> 00:01:48,350
These classes may have
attributes in common such as

31
00:01:48,359 --> 00:01:51,880
health, xp, their position in
the game world and so forth.

32
00:01:52,450 --> 00:01:56,350
In fact, maybe the classes are all
specializations of that player class.

33
00:01:57,880 --> 00:02:01,120
In a banking application, you might
have different types of accounts,

34
00:02:01,670 --> 00:02:05,750
some may have specialized business
rules for withdrawal, deposit, minimum

35
00:02:05,760 --> 00:02:07,920
balances, interest rates and so forth.

36
00:02:08,560 --> 00:02:11,870
But again, maybe all accounts
have a balance and provide the

37
00:02:11,870 --> 00:02:13,590
withdrawal and deposit behaviors.

38
00:02:14,050 --> 00:02:16,880
Usually, we can find commonality
among these classes, and

39
00:02:16,880 --> 00:02:17,960
we can leverage that.

40
00:02:19,340 --> 00:02:22,679
In a graphics or drawing application,
we may have many different types of

41
00:02:22,680 --> 00:02:27,110
shapes that we can draw such as lines,
ovals, circles, squares and so forth.

42
00:02:27,860 --> 00:02:31,570
Depending on our application,
maybe we can identify common

43
00:02:31,590 --> 00:02:33,309
attributes that all shapes have.

44
00:02:33,860 --> 00:02:36,299
Perhaps, their color, they must
be drawable, you should be able

45
00:02:36,300 --> 00:02:37,950
to rotate and transform them.

46
00:02:39,460 --> 00:02:42,460
And as you can see in the last
example, maybe we have an application

47
00:02:42,460 --> 00:02:44,350
for a university personnel system.

48
00:02:45,100 --> 00:02:48,780
You might have person employees,
students, faculty staff

49
00:02:48,780 --> 00:02:50,150
administrators and so forth.

50
00:02:50,400 --> 00:02:51,510
You get the idea.

51
00:02:51,620 --> 00:02:54,589
Related classes are all around
us when we develop software.

52
00:02:54,960 --> 00:02:58,109
Sometimes it makes sense to
extract out common elements of

53
00:02:58,109 --> 00:03:01,450
related classes and model them on
their own so we can reuse them.

54
00:03:01,970 --> 00:03:04,330
Let's look at the account
classes in more detail.

55
00:03:06,740 --> 00:03:08,990
Here we can see that our
application has several

56
00:03:08,990 --> 00:03:10,360
different types of accounts.

57
00:03:10,889 --> 00:03:13,800
We have a basic account that
has balance and a way to

58
00:03:13,800 --> 00:03:15,509
deposit and withdraw funds.

59
00:03:16,559 --> 00:03:20,060
We also have a savings account
object that also has a balance

60
00:03:20,470 --> 00:03:21,890
but an interest rate as well.

61
00:03:22,190 --> 00:03:25,070
And the deposit and withdraw behavior
might be a little different from

62
00:03:25,070 --> 00:03:28,440
those in the account class since they
have to consider the interest rate.

63
00:03:29,469 --> 00:03:33,119
A checking account also has a balance,
but maybe you have to keep a minimum

64
00:03:33,130 --> 00:03:35,339
balance, and there are per check fees.

65
00:03:35,619 --> 00:03:38,940
So the deposit and withdraw behavior
for the checking account will be

66
00:03:38,940 --> 00:03:42,260
different from both the savings
account and the regular account.

67
00:03:42,760 --> 00:03:46,699
Finally, maybe we have a trust account
that has a balance and a deposit

68
00:03:46,700 --> 00:03:48,330
functionality just like an account.

69
00:03:48,920 --> 00:03:52,639
But the withdrawal only allows three
withdrawals per year of a maximum

70
00:03:52,639 --> 00:03:54,530
of 10% of the account balance.

71
00:03:55,250 --> 00:03:57,810
You can see that these types
of accounts are very different,

72
00:03:58,090 --> 00:04:00,780
but they also have some common
attributes and behaviors.

73
00:04:01,600 --> 00:04:04,440
Let's see how we could model
these accounts without any

74
00:04:04,440 --> 00:04:06,090
inheritance or any reusability.

75
00:04:08,750 --> 00:04:11,820
What we could do here is we
could create four independent

76
00:04:11,820 --> 00:04:15,910
classes: account, savings account,
checking account and trust account

77
00:04:16,350 --> 00:04:19,349
and implement them all totally
independent from one another.

78
00:04:19,829 --> 00:04:22,670
Sure, this will work, but
will surely have code that's

79
00:04:22,670 --> 00:04:26,159
duplicated across these classes
since some of the behavior and

80
00:04:26,160 --> 00:04:27,539
some of the data will be common.

81
00:04:28,350 --> 00:04:30,520
Let's see how we can use
inheritance to allow us to

82
00:04:30,520 --> 00:04:32,120
reuse the account class.

83
00:04:34,810 --> 00:04:38,660
We'll look at proper c++ syntax
for inheritance in a few videos.

84
00:04:38,950 --> 00:04:41,330
For now, let's just look at
this from a conceptual view.

85
00:04:41,990 --> 00:04:44,929
We have an account class that
models a balance and provides

86
00:04:44,929 --> 00:04:47,429
a simple implementation
for withdraw and deposit.

87
00:04:48,440 --> 00:04:51,810
Now we can use inheritance to
create a new class savings account

88
00:04:52,140 --> 00:04:53,610
based on the account class.

89
00:04:53,820 --> 00:04:57,400
So the savings account will inherit
balance and the implementations

90
00:04:57,410 --> 00:05:00,849
of withdrawal and deposit
provided by the account class.

91
00:05:01,840 --> 00:05:05,059
And the idea is that now we simply
add the interest rate attribute

92
00:05:05,299 --> 00:05:08,740
to the new savings account class
and implement its own version

93
00:05:08,740 --> 00:05:10,130
of deposit and withdrawal.

94
00:05:11,100 --> 00:05:13,410
The same idea applies to
the last two examples.

95
00:05:13,900 --> 00:05:17,940
A checking account is created using
the account class as a base and then

96
00:05:17,940 --> 00:05:21,500
it adds what it needs and modifies the
behaviors to meet its requirements.

97
00:05:22,320 --> 00:05:25,219
Finally, the trust account adds
an interest rate and implements

98
00:05:25,220 --> 00:05:28,410
the logic in the withdrawal method
that supports the business logic.

99
00:05:29,520 --> 00:05:32,180
You can see that these
classes are now interrelated.

100
00:05:32,530 --> 00:05:36,169
In this case, the savings account,
checking account and trust account

101
00:05:36,230 --> 00:05:40,780
classes depend on the account class,
and we have an inheritance hierarchy.

102
00:05:41,529 --> 00:05:43,900
In this case, it's rooted
at the account class.

103
00:05:44,250 --> 00:05:47,450
We'll talk more about inheritance
hierarchies in an upcoming video.

104
00:05:48,140 --> 00:05:51,090
So now that we understand what
inheritance is, let's go over

105
00:05:51,090 --> 00:05:53,989
some of the terminology and
notation used in the next video.