OOPS Concept

Inheritance

Think of inheritance as something more specific inheriting from something abstract.

So for example, if we were to model a car with inheritance then we might have

1. Car
2. ^
3. |
4. Honda
5. ^
6. |
7. Civic
8. ^
9. |
10. 1992 Model Civic
Where arrows point up means inherit from, so the Honda class inherits from Car class
picking up everything that we think of every car having but the Honda version of a
Car. As we inherit we see the more abstract classes on the top and the more specific
classes inheriting on the bottom. Let’s look at this a little more closely. Every car has
a Vehicle Identification Number or VIN so we would give the VIN attribute to the Car
class just so:

1. +---------------+
2. | Car |
3. |---------------|
4. | VIN |
5. |---------------|
6. | TurnEngineOn |
7. | TurnEngineOff |
8. +---------------+
9. ^
10. |
11. +----------------------------+
12. | |
13. Honda Ford
14. ^
15. |
16. Civic
17. ^
18. |
19. 1992 Model VX Civic
Here I have added a Ford class that also inherits from Car. We can think of the
inheritance as “is a” as in a Ford is a Car. To describe an attribute we think of it as
“has a” as in a Car has a VIN. So here we see how every kind of car gets the VIN
 attribute through inheritance because they all inherit from Car then they all have a
VIN.

Now the VIN is a unique identification for each car, and its value is given when a class
is instantiated. So an example of an instantiated car would be Uncle Dave’s 1992
Honda Civic. This is not a new class its an instance of 1992 Model Civic and when we
make this instance we set the value of the VIN attribute.

There is another thing about inheritance that we need to consider here. Cars have
attributes but there are things that we can do to a car. Think of this differently than
what we can do with a car. Some thing we can do to a car is turn its engine on. Notice
that turning the engine on changes the state of the car. Another thing we can do to
the Car is turn its engine off. Because we can turn a car on and off we can turn every
is a kind of car on and off. This is how inheritance works.

Polymorphism

Using our Car model we need to consider what are the differences between the is a
kind of car. One of the things about cars is that they consume gasoline at different
rates. So for example, we turn the engine on it start consuming gasoline while its
running and we drive it around. Then when we turn the car off it stops consuming
gasoline. Something we can do to the car is check the fuel level which calculates how
much fuel is left in the car based on everything we’ve done to the car. Let’s add
function FuelLevel which returns how much fuel is left in the car.

1. +---------------+
2. | Car |
3. |---------------|
4. | VIN |
5. |---------------|
6. | TurnEngineOn |
7. | TurnEngineOff |
8. | FuelLevel |
9. | Run |
10. +---------------+
11. ^
12. |
13. +----------------------------+
14. | |
15. Honda Ford
16. ^
17. |
18. Civic
19. ^
20. |
21. +---------------------+
22. | 1992 Model VX Civic |
23. |---------------------|
24. | FuelLevel |
25. | Run |
26. +---------------------+
So we can ask every Car how much fuel by calling the FuelLevel method. The
FuelLevel method in the Car class just does average fuel consumption for all cars. But
we want to know specifically what it would be for the 1992 Honda Civic. You will
notice that we also defined FuelLevel in the 1992 Civic because it uses fuel differently.
This modifying behavior by overriding a function is called a Polymorphism. I’ve
added another polymorphism called Run which takes into account exactly how the
car runs. At this point you may be wondering well, why bother with all of this? The
answer to your question is:

Encapsulation

Let’s suppose we are writing a program, maybe its a game or some kind of
simulation of driving cars around. We want our simulation to support all kinds of
different models of cars and all different years. Antique cars, new cars, race cars, etc.
How can we write our simulation efficiently? Are we going to have a function that
drives a 1960 Ford Falcon and another function that drives a 2012 Porsche Boxster
and yet another function that drives a Model T Ford etc. OR could we have one
function that drives them all? What would that function look like say C#?

1. decimal Drive(Car car, int minutesToRun) {

2. var startingFuelLevel = car.FuelLevel();
3. car.TurnEngineOn();
4. car.Run(mintuesToRun);
5. car.TurnEngineOff();
6. return car.FuelLevel() - startingFuelLevel;
7. }
8.  
9. int main() {
10. var gallonsCivic = Drive(new
HondaCivicModelVX1992());
11. var gallonsFord = Drive(new FordFalcon1960()):
12. var gallonsPorsche = Drive(new
PorscheBoxster2012());
13. var gallonsModelT = Drive(new ModelT());
14. }
An interesting thing is happening here. We are passing all kinds of different cars to
our Drive function, which by the way is something that we “do with” a car. No matter
what exact car we pass to our Drive function it looks like Car. This is happening
because all the specific kinds of cars inherit from Car and so our function does not
have to know a difference between the different kinds it’s one piece of code can
drive them all.

This ability to hide the inner workings of each kind of car from a piece of code
happens through information hiding or sometimes known as Encapsulation. Now my
example here is kind simple and stupid but you imagine what might happen if Drive
was a very complicated process and do you want to have rewrite it for every kind of
car or do you want to be able add new cars through inheritance?

How is Object Oriented Design Useful?

Having said all of this, it is unusual to use a single set of classes to model something
in the environment. This is important to understand. To be a useful paradigm
objected oriented software only models a particular use case or related use cases of
an object. Never create a Swiss Army Knife object!

For example consider an Invoice. Can I make an abstract Invoice class that will satisfy
every use case of an Invoice. Probably not!

It is true that I want to reuse code in various use cases of an Invoice. That just may
mean designing objects that supply that reusable code. So instead of an Invoice
having a "Close" method, I make a class called "InvoiceCloser" that knows how to
close an invoice and use that class.

Good oriented design is about hiding information. We wantcode to be as sole and

readable as possible. Code that knows the least about other code is cleaner,ore
dependable, easier to support, and functionally scalable I.e, I don't feel like a rewrite
when asked to add major new functionality.