Overview
Object Oriented Programming (OOP) is more than just a programming concept. It is a way of thinking about applications. It is learning to think of applications not as procedures, but objects and real entities. That makes a lot of sense. We view the world around us not as intangible, but as real entities or objects. Objects that do things (methods), and have things (attributes). They are logically grouped by the way they appear and behave. Cars may differ in cabin space, color, engine size, acceleration, yet they’re all similar in form and function. If we think of our physical world in that way, why not code?

In programming, an object is a run time instance of code and data that comprise some sort of logical grouping, usually referred to as a business entity. Suppose you hated that ugly palm in your yard and wanted to replace it with a newer one, or maybe even an oak? You wouldn’t tear up you entire yard, trying to uproot that tree. That’s precisely one of the most prevailing advantages to OOP, namely to reusability. Imagine that you didn’t have to sift through lines of code to change some obscure variable. Imagine that you could add new functionality to your application by pulling out an object, changing it, and plugging it back in. Another great advantage is improved code readability, reliability, and adaptability. What if you wanted to create an entirely new type of code object, say, a supervisor, that had all the same functionality as an employee, but had more security rights, or maybe even a different pay scale? Other developers do not need to know how an object does what it does, just how to make it do it. You don’t have to know how a car works, just where the brake and gas are.

The mere fact that code may contain properties (attributes) and methods, does not, in itself, make it object oriented. To illustrate; a COM component may contain several functions that calculate totals and retain certain values. Such a component may be an object because it is an instance of a class, but it is not object oriented, since it does not follow many of the ideals of OOP.

In Visual Basic, as do many other languages, we use classes to define components. Once created, and populated with data, a class becomes an object with properties and methods, not just a prototype or code. So far, so good, Visual Basic can do classes with properties and methods.

While it is debatable whether OOP works in all situations, we’re only going to cover one case study where it does. Essentially, we’ll briefly explain four main object oriented design concepts: Inheritance, Polymorphism, Aggregation, and Encapsulation (containment). There are also other aspects, such as overloading, delegation, etc., which we won’t cover in too much depth.

Before we begin, we must define an interface. An interface is basically a signature of what the code component does. It’s a contract that you can’t break, but can amend. Once we agree what a car is, we can’t change it’s definition to define a motorcycle.

Inheritance
Inheritance allows one class to inherit the functionality of another without having to rewrite the code. In genetics, a child has some of the traits of a parent, while still functioning and appearing quite unique. Inheritance as a programming concept works the same way. An inherited class should contain all of the implementation of its parent class (superclass, base class, etc.) through its inherited interface.

There are various types of inheritance. Interface inheritance, inherits only the interface signature, while implementation inheritance inherits the actual code implemented in its parent. Visual Basic, and COM for that matter, do not support implementation inheritance. But they can simulate it using aggregation (actually delegation), which we’ll discuss later. Visual Basic does though, support interface inheritance. This is accomplished by adding interfaces, written in IDL, to an ActiveX DLL. Visual Basic does this for you when you use the implements keyword. COM does allow multiple interface inheritance, but each object instance can only communicate through one interface at a time (that’s a good thing). To illustrate, let’s look at the following pseudocode.

	Class 1 Interface 1
	Method1()

Class 2 Interface 2 inherits Interface 1
	Method2()
	Method1()

Method 1 of interface 2 is actually contained in the code for class1. Can Visual Basic do that? Yes… no… well, kind of. We can simulate it, and we’ll do that using a variety of other OOP techniques.

Polymorphism
Polymorphism is accomplished when different components or classes behave differently to the same interface. Think of it as more than one way to code an identical method. What one component does in its Update method may be different than what another may do, or need to do. We implement polymorphism in Visual Basic, by overriding methods. When several objects must support the same interface, we rewrite the method each time. Consider the following code.

Object 1

	Implements ITest
	Private Sub ITest_Update(strData as String)
		‘Update Test Database
	End Sub

Object 2

	Implements ITest
	Private Sub ITest_Update(strData as String)
		‘Send an Email
	End Sub

Notice that object 1 and object 2 both implement the ITest interface, yet both implementations of the update method differ. Object 1 requires the update method to write to the database, while object 2 requires it to send an email. Polymorphism is the simple mechanism used to solve both scenarios while using same interface.

Aggregation and Encapsulation
Aggregation is a sort of symbiotic relationship between objects. In Aggregation, a host object acts as a liaison between the outside world and an inner object. This can be accomplished in several ways. One is by having both objects implement the same interface. Since they contain the same interface, when a host object is called, it can in turn make a call to the inner component’s same method (delegation), in effect, forwarding the call. Another technique allows the method of the inner component to be directly exposed to the outside world (aggregation). An object takes the inner object’s interface, and presents it as it own. Many times the relationship, not the specific technique is referred to as aggregation. Consider the following example.

Object 1

	Private Object2 as Object2.ProgID

	...
	Private Sub Class_Initialize()
		Set Object 2 = New Object2.ProgID
	End Sub

	Private Sub Class_Terminate()
		Set Object 2 = Nothing
	End Sub

	Public Function GetValue(intID as Integer) as String
		GetValue = Object2.GetValue(intID)
		‘We can even add more functionality here
	End Sub

Object 2

	Public Function GetValue(intID as Integer) as String
		‘Get Value from Database
		‘Set GetValue = the returnable string
	End Sub

Object 1and object 2 both contain a method named GetValue. Notice though, that the implementation exists in Object 2. Object 1 aggregates the functionality of Object 2 by creating a private copy and calls its method internally, presenting it as its own. This allows Visual Basic developers to create more reusable components. We don’t have to name the methods the same, it’s the functionality we’re interested with here. Object 2 is only accessible through object 1. Notice that we can even add additional implementation to the GetValue method of Object 1.