September 21, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

Understanding OO Essentials: Classes, Inheritance, Polymorphism and Interfaces

  • December 31, 2002
  • By Bill Hatfield
  • Send Email »
  • More Articles »

When you first begin to wade into the deep end of an object oriented language you find yourself inundated with esoteric concepts and strange terminology. You may half-understand conversations and read books and articles that all seem to assume a basic set of knowledge that you don't fully grasp. It can be a frustrating experience! After all you are no green-horn. You've done your share of development. So why is all this so confusing?

The fact is that it doesn't have to be. Because object-oriented development originated in the academic world, it comes with a whole new vocabulary and a whole lot of complicated descriptions for pretty simple ideas.

In this article, my goal is to give you the knowledge that all those books and magazines assume you already know. You won't learn all there is to know about object-oriented development. But you will get enough of the concepts and terminology down to give you a solid foundation to build on.

Objects, properties and methods

It would be difficult to be a programmer today, no matter what programming language you use, and avoid working with objects in one way or another. Objects are simply containers for variables and functions that logically go together. In object-oriented parlance, variables and functions inside an object are called properties and methods. In most languages, you use dot-notation to refer to an object's properties and methods. For example, if you have an object named Customer and you wanted to assign a value to its Name property, you would use syntax that looks something like this:

Customer.Name = "Fred Smith"

Or if you wanted to call a Customer method called PrintInvoice(), it might look something like this:

Customer.PrintInvoice()

When used like this, objects are simply a way of organizing data and code into logical collections. But there's more to object-oriented programming than that!

Classes and instantiation

The terms class and object are sometimes used interchangeably. This makes understanding the difference between the two that much more difficult. They are distinct, but related.

Think of a class as a detailed description of an object. A class is not an object, but it contains all the information needed to create an object. It's like the relationship between a blueprint and a house. Here's an example of a class definition in Visual Basic .NET. (Although the syntax will be slightly different in different languages, the structure is usually roughly the same.)

Class EmpClass   Public Name As String   Public Phone As String   Public Hours As Integer   Public Rate As Single   Public Function CalcPay()      Return Hours * Rate   End FunctionEnd Class

A class definition is simply a group of variable and function declarations grouped together and given a name.

Although the blueprint contains all the details necessary to create a house, you can't live in a blueprint. Before you can have someplace to live, a process must take place: building. In order for you to make use of a class, a process must take place: instantiation.

Instantiation (literally meaning "to make an instance of") is how objects are created from a class. Once an object is created, you can assign values to its properties and call its methods. Every language has its own syntax for instantiating objects from classes. However most of them use the keyword New in one way or another. Here's an example of instantiation syntax in Visual Basic .NET.

Dim EmpObj As EmpClassEmpObj = New EmpClass

First a variable is declared. The class name here, CustClass, is used just like a data type would be in any variable declaration. But this does not instantiate the object. It simply declares a variable that will point to the object, once it is created.

The next line is where the instantiation takes place. The New keyword is followed by the name of the class to instantiate. Again, although the syntax in the language of your preference will likely be a little different, the two-step process of creating a reference variable and then instantiating the object and assigning it to the reference variable will likely be the same. (Although some languages provide a shortcut syntax to do both in one line.)

Once the object is allocated in memory, CustObj becomes a reference to that object and can be used as you would any object.

EmpObj.Hours = 40EmpObj.Rate = 6.50Total = EmpObj.CalPay()

At this point you might be thinking, "Wait a minute — I've written code before that uses objects, but I didn't have to write any instantiation code. How is that possible?" See the sidebar titled "Automatically Instantiated Objects, Static Classes and Other Black Magic".

But what's the point of this extra level of complexity? Why must you describe a class and instantiate the class as an object before you can use it? Why not just describe the object and be finished with it? Well, there's one very good reason: Many objects can be instantiated from a single class. When you do this, each object will contain the same set of properties and methods. However, each object is independent and its properties can have different values.

Here's an example where two employee objects are created from the same employee class and each are assigned different values.

Dim Emp1Obj As EmpClassDim Emp2Obj As EmpClassEmp1Obj = New EmpClassEmp2Obj = New EmpClassEmp1Obj.Name = "Fred Smith"Emp2Obj.Name = "Bob Jones"

Automatically Instantiated Objects, Static Classes and Other Black Magic

I stated pretty clearly that you can't use a class until you've instantiated it, any more than you can live in a blueprint. And that's the general rule. Now for the exceptions

Many languages and development environments automatically instantiate objects for you behind the scenes. Typically these are objects that often need to be accessed but ones which you'll never need more than one instance. So technically this isn't an exception to the rule. But it does look like one when you are working in such environments because you are not responsible for the instantiation and may not even be able to see the code where it's actually done.

There is another case that really is an exception to the rule, however. Some classes are designed to be used directly. These are called static classes. Often static classes are collections of utility functions associated with a particular task, like file manipulation. Making such classes static just saves you a couple of step when you go to use them.





Page 1 of 4



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel