January 17, 2021
Hot Topics:

Understanding OO Essentials: Classes, Inheritance, Polymorphism and Interfaces

  • By Bill Hatfield
  • Send Email »
  • More Articles »


So far, classes and objects seem like little more than just a fancy way to bundle code together, like an advanced include module, for example. But there is one important ingredient to object oriented programming that completely sets it apart: inheritance.

Inheritance is the ability to start with an existing class and use it as a starting point for creating another class. So what? You can copy and paste code from a module and do the same thing, right? But suppose you've used a base module as the starting point for several others. Then you make a change to that base module. In order for that change to be reflected in all those other modules, you have to go and make the change there, too. This is actually a very common scenario and a major cause for inconsistencies and bugs in all kinds of applications.

Inheritance is different. When you inherit from a class, the new class (often called the child class) maintains a connection with the original class (often called the parent). This connection assures that any change in the parent is automatically also made in all its children as well.

And inheritance works for multiple generations as well. That is, you can inherit from a parent to create a child. Then you can inherit from the child to create a grandchild. Any changes made to either the parent or child is reflected in the grandchild.

As you might imagine, this means that you have the ability to create intricate and complex structures or inheritance hierarchies. Inheritance is a powerful feature. But its the kind of power that's easy to abuse and significantly more difficult to use well.

What's the best strategy for creating an inheritance hierarchy? The first rule is to think in terms of generalization. The higher the class is in the hierarchy, the more general and abstract it should be. The lower you get in the class hierarchy, the more concrete and specific the classes should be.

Here's an example. Suppose you decide to reengineer your EmpClass to take advantage of inheritance. Your highest-level class might be Employee. It would contain properties like Name and Phone. Inherited from Employee might be a class called SalariedEmployee. Properties of this class would include the Name and Phone that was inherited from Employee, but it would also include a property called Salary. At the same time you might have another class that inherits from Employee called HourlyEmployee. In addition to the items that were inherited from the Employee class, this class may contain properties like Hours and Rate.

Here's what it would look like in Visual Basic .NET.

Class Employee   Public Name As String   Public Phone As StringEnd ClassClass SalariedEmployee   Inherits Employee   Public Salary As LongEnd ClassClass HourlyEmployee   Inherits Employee   Public Hours As Integer   Public Rate As SingleEnd Class

Once you've created this hierarchy, you can use the child classes as if the parent properties were directly apart of them.

Dim Emp1 As SalariedEmployeeDim Emp2 As HourlyEmployeeEmp1 = New SalariedEmployeeEmp2 = New HourlyEmployeeEmp1.Name = "Fred Smith"Emp1.Phone = "555-1331"Emp1.Salary = 26000Emp2.Name = "Bob Jones"Emp2.Phone = "555-1331"Emp2.Hours = 40Emp2.Rate = 6.50

Page 2 of 4

This article was originally published on December 31, 2002

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date