Understanding Objects in Computer Programming

Objects are a key element in computer programming. While objects are at center stage in Object Oriented Programming, they are widely used in procedural languages and serve as the building blocks of complete applications * Let’s understand objects!

What is an Object?

Simply put, an object is any “thing” you can actually see, physically.

For example, a person, a car, a pencil, a circle – are all physical objects.

Extending our perception of object to understand how objects are used in computer programming, an object can also offer a well-defined service: A Government office issuing passports, a translation service over the Internet, a shoeshine stand or a computer program to calculate the area of a triangle.

If you examine the image here, you will see three aspects of an object, or what an object “has”: properties, methods and events.

Properties are attributes describing the traits of an object. As you can see, some properties of a person are mutable, meaning, their value can be changed (a person’s height keeps changing as the person grow) while others are immutable – are given and cannot be changed, such as the date of birth. Properties provide us with information.

Methods are activities, or functions, that can be performed by the object. A person can walk, talk, open his eyes, and so on. Methods expose capabilities.

Events happen in a timely fashion to an object. When a person reaches the age of 28, we have an event. When a person opens his eyes, we may mark several events that happen one after the other, such as: eyelids started sliding up; eyelids finished sliding up; eyes started showing a tear. Note that the hallmark of an event is the instance in time it is observed.

Objects in computer programming

As you can imagine, our world is a mix of objects. As computer programs often reflect the real world, it is only natural that we will have a way to formally document real world objects in our programs.

An employee is a person. While his height may not be of interest to us in a given program that manages our employees, his date of employment may be a property of interest.

As an Excel user, you have already worked with objects offered by the application, out of the box.

In the following image you can see some of the properties, methods and events associated with the Worksheet object.

In VBA, we can get / set a given Worksheet’s properties like that:

ActiveSheet.Visible = False

strName = ActiveSheet.Name

… or activate its methods like this:

ActiveSheet.Protect

… or respond to an event raised by the Worksheet in the appropriate Worksheet event handler:

Private Sub Worksheet_Activate()

    MsgBox "Welcome to the secret Worksheet!"

End Sub

Can you think of other objects you’re working with in Excel?

How about the Workbook? Can you list some of the Workbook’s properties, methods and events?

How about a Worksheet cell? A chart? A User Form? A Text Box? …

Object Class and Object Instance

In the above example of Worksheet, I used ActiveSheet to represent a Worksheet object.

As you know, we may have multiple Worksheets in our Workbook (and more in other Workbooks). Each such Worksheet has its own set of properties, can be called to activate any method and raises events independently from other Worksheets.

In other words, each Worksheet is a self-contained object and we can have multiple such objects living together. Let’s define two Worksheet objects:

Set wksFirst = ThisWorkbook.Sheets(1)

Set wksSecond = ThisWorkbook.Sheets(2)

While we have defined two distinct Worksheet objects, they do share something in common. They are both created from the same blueprint (or template) defining the Worksheet object: what Properties, Methods and Events it shall expose.

We call the object’s blueprint a Class and each of its offspring an Object Instance.

wkbFirst is an instance of the Worksheet Class.

wkbSecond is another instance of the Worksheet Class.

Sometimes Objects’ Instances are referred to as just Objects, so we have the Class and its instantiated Objects.

Those Microsoft engineers that created the Worksheet object, had to define which properties it shall have and of what data type, which properties should be mutable and which should not, which events will be raised by the Worksheet object and what would be the methods available to call for. They also had to implement each method!

Once the Worksheet Class was ready – all Excel users could create instances of the Worksheet Class and use its available properties, methods and events.

In a way, you can think of the whole Excel application as a collection of Object Classes, and that’s it. As you open the application, instances of those Classes are created and give life to the application.

As an instance is created out of an Object Class, an encapsulation of the instance’s specific data (properties’ values) along with the Object Class’ services (methods, events) is realized. Encapsulation help separate all the objects’ instances at play in our program and make it easy for us to design and troubleshoot our program.

Can I create my own Object Class?

If Excel (and other applications) are just a collection of predefined Object Classes, one begs the question: can we also define our own Object Classes to use in our programs?

Well, if we can define our own Data Types, Enumerations and Collections – one would expect we will be able to define our own Object Classes.

However, before we learn how to do that in VBA, we would need to have a better understanding of Object Oriented Programming, or OOP. Click here to read the next part in this OOP series: Understanding OOP.