Objects, Properties, Methods and Events

In this chapter, we will be looking at objects. Some of you may have heard terms like "object oriented programming", "object models", and similar. In order for us to understand what these terms mean, we first need to look at the word found at the core of each of them: object.

In our study of objects, we will find that an object is a software representation of a real-world item, or object. Software objects feature properties (that describe the object), methods (that allow the object to do things for you), and events (code that is executed automatically when a certain situation – an event – occurs).

Once we have looked at what an object is, we'll then be able to look at how objects are useful to us in developing ASP applications. Developing web applications requires us to deal with both the client-side and server-side programming, and therefore we'll take a look at how objects can be used on both sides of the wire.

Before we get started, here is what we will cover in this chapter:

q What is an object?

q An introduction to properties, methods, and events

q How can we change the characteristics of an object?

q How do we know when the object tells us something?

q What is an object model?

q How do we use the object model in Active Server Pages?

We'll begin by taking a look at what an object is.

What is an Object?
In the real world, we already know what objects are. They're the things we look at, pick up, and use every day – things like our chairs, our telephones, and our computers. All these are solid, tangible entities.

However, if we want to describe a telephone to somebody in abstract terms, we can do this by talking about it in terms of its essential characteristics – what properties it has, what it can do, and how we can interact with it. All telephones have these characteristics, and we can use them to establish exactly how one telephone differs from the next.

So, for our telephone's physical properties, we could say that it has a microphone, a speaker, and a dialing pad. We could also say that it lets us do things, such as call someone and talk to them. Our telephone will also tell us when certain events are happening: for example, if a friend is trying to call you, your telephone will ring to let you know. This ringing will prompt you to take some action, like picking up the handset and talking to your friend. As an abstract object, our telephone has:

q Certain properties that define and describe it

q A set of things or methods that it lets us do

q The ability to prompt action when events occur

We can use these three attributes to describe physical objects and abstract concepts. In a few minutes we will describe how these real-world ideas are replicated in software objects, but for now lets go a little deeper into our real-world telephone. By learning about what objects are, we can then look at how to use them in a way known as object-based programming. In the object-based way of programming, the application is broken down into a set of objects. In doing this, you can build the application in a two stage process. Firstly, you create the objects you will need in your application and then you set up the relationships and interactions between objects. Later in this chapter, we will see how the objects of Active Server Pages relate and interact with each other and allow us to build our applications.

Our Telephone in Detail

Here is our telephone. To look at this as an object, let's put down some information about it. We will be classifying the information into three categories:

q Things that describe the telephone

q Things that we can do with the phone

q Things that the telephone tells us and that we can react to

Let's look at each of these aspects in turn:

Describe the telephone
The telephone is gray
The telephone is made of plastic
The handset weighs 6.5 ounces
The telephone has 12 keys
The telephone number is (714) 555-1523
The telephone is connected to the exchange

What can we do with it?

We can place an outgoing call
We can answer an incoming call
We can hang up the current call
We can enter our calling card number
We can disconnect it from the exchange

What can it tell us that we can react to?

Someone is trying to call us
The person we are calling is busy
Another person is calling while we are talking

How It Works
The three categories that we have created in the left-hand column can be applied to any object. In fact, the best way to describe an object is to break down its characteristics into these three categories, and put information about your object into these categories. Any information that you have about a particular object can be included in one of these categories.

If you have another telephone that features all these characteristics, except that its color is blue, then we can describe your telephone by changing that one part of the description above. Moreover, this technique works for any type of object, both real world and software.

Object Terms
So far, we have used verbose English terms to describe our three categories. In the world of objects, we need terms that concisely describe each of these three categories. These terms are properties, methods and events. In addition to these terms, we need to look at the term instance as it relates to objects. In this section, we'll look more carefully at what each of these means in abstract terms.

Instances and Classes
When we are talking about a unique object, we can use the term instance to say that we are talking about a particular telephone object – your telephone for example – that has a specific set of properties and values. When we want to talk about another telephone, we use a different instance of the telephone object. In this way, both you and I can have instances of the telephone object. For example, my telephone (my instance of a telephone object) is gray and comes with special answer-phone facilities, your telephone (your instance of a telephone object) may be red, blue, green etc. These instances represent completely different physical objects. However, since they are both instances of the same object description or template, they share the same types of characteristics such as methods, properties (although the values can be different), and events. When a specific instance of an object is created from the template for the object, the object is said to have been instantiated. What actually happens is that a copy is made of all of the properties and events from the object description, but the methods (frequently a big chunk of code) remain in the original place and this section of code is used by all of the different instantiations of that one object.

So we've mentioned object descriptions or templates, but it's time to give them their proper name in ASP; classes. We mentioned that each object can have different instances. For instance, my telephone is small and white and has 12 buttons. Your telephone will probably be different to that, but they're both recognizable as telephones and they both provide the same function. They both conform to a set of rules for what a telephone does – they connect to the local telephone line, they both have a numeric keypad and somewhere to speak into. A class in ASP is like a set of design rules that an object must conform to. It would be no good if my telephone didn't have a handset, or a numeric keypad, even if it did plug into the telephone socket on the wall. In a class there should be a minimum set of functions that your object must be able to perform.

Properties
When talking about those characteristics that describe an object, we are talking about the properties of the object. Each property of the object describes a particular aspect of the object. The property is actually described as a name/value pair. This means that for every named property, there is a single unique value that describes that property for this instance of the object. If we go back to our telephone example, we can create a table that lists each of the property names and the value of each property.

Property Name
Property Value

Color
Grey

Material
Plastic

Weight
6.5 ounces

NumberOfKeys
12

TelephoneNumber
(714) 555-1523

Connected
Yes

We now have a set of properties that describe this instance. The properties of an object are used to represent a set of values associated with the object. A new instance of the object may have different property values, but it has the same property names.

Even with different property values, these two telephones are instances of the same object template. Since we know that all telephone objects have a 'Color' property, we can determine the color of each of the phones by examining its 'Color' property value. We can use properties in two ways. We can read from them or we can also write to them. So if we wanted, we could have changed the cover of our telephone to a different color, if we required.

Now that we have a way of describing the telephone object, let's take a look at what we can do with it.

Methods
Another characteristic of objects is that they can perform functions for us. For example the PlaceCall method would perform several functions for you. It will connect you to the local exchange, the exchange will route your call, and then when it reaches the destination, it will make the destination phone ring. These built-in actions occur whenever you pick up the handset and dial a number. This is a capability that has been built in to the machine.

However not all objects have functions like this. A chair object allows you to sit in it, so you could say that it is functioning to support your body. Objects that perform tasks that are more 'functional' are said to have methods. The tasks that an object can perform are called methods.

A method is defined as an action that an object can take. The code in a method is executed when the method is called. This calling is done by a command you write in the script of your ASP page. Once we have created an instance of an object, we can tell it to perform a certain task calling one of its methods.

Let's illustrate this using the telephone example. Our telephone object can carry out five methods. Each of these methods will cause the telephone object to perform an action. Here is a list of functions that the methods of the telephone object can perform:

Method Name
Description

PlaceCall
Place an outgoing call

Answer
Answer an incoming call

HangUp
Hang up the current call

SendCardNumber
Enter or send our calling card number

Disconnect
Disconnect the phone from the exchange

These methods are used when we want our telephone object to perform a certain function; all we need to do is tell it to execute the corresponding method.

Methods are actually blocks of code that are written by the designer of the object (Microsoft, for example). The reason methods exist is because lots of programmers want to do the same job, so it is worth it for the gurus at Microsoft to write the code to do that job, test it, optimize it, and get it in great shape, then bundle it up in the object. We, as programmers, can then use that code pre-made. Instead of re-inventing the wheel we spend our time on the unique parts of our project.

Parameters of Methods
You may have noticed that some of the methods can be executed directly, while others look like they will need additional information. To contrast these two ideas, consider the following examples:

q Suppose that our telephone receives an incoming call (in the next section, we'll see how we can tell that this is happening). All we need to do to answer the call is to use the 'Answer' method of our telephone object.

q Suppose that we want to place a call. Simply calling the PlaceCall method isn't enough in this case: we need to supply more information (for example, the telephone number!) in order to complete the action.

Let's look more closely at the second of these examples. The telephone object has a TelephoneNumber property, and this is used to identify our telephone's own telephone number (i.e. the number that other people use to call us). So, the TelephoneNumber property of our phone isn't going to help us to make outgoing telephone calls.

So, how do we tell the phone which number we want to call? It's possible, I guess, for the telephone object to have another property, called OutgoingTelephoneNumber, that would identify the desired number; but that would be too cumbersome, because every time we wanted to make a call we would have to:

q Set the OutgoingTelephoneNumber property value to the desired phone number

q Execute the 'Call' method of the telephone object to place the call

As you know, telephones just don't work that way. It would be much more elegant (and intuitive) to have some way of passing the outgoing phone number to the 'Call' method, so that we can place an outgoing call in a single step. This is done by passing a parameter to the 'Call' method. With this in place, we can place an outgoing call by simply executing the 'Call' method and telling it which number we want to call, like this:

q Execute the 'Call' method of the telephone object, passing the outgoing telephone number as a parameter. Parameters here are just the same as the arguments(parameters) we passed to functions and subroutines in the last chapter.

If we look again at the methods of the telephone object, we can identify those methods that require parameters, and what the values of those parameters mean to the object:

Method Name
Parameters

PlaceCall
Outgoing telephone number

Answer
No Parameters

HangUp
No Parameters

SendCardNumber
Calling card number, PIN

Disconnect
No Parameters

You can see that a method can have none, one, or more than one parameter. The SendCardNumber method actually requires two parameters. You are required to pass in both the calling card number and the personal identification number (PIN) in order for the method to execute properly. Information passed as parameters of the method for execution by the method, will only be executed if all parameters have been supplied.

Return Values
In addition to passing parameters to a method, the method can also return information to us. The value returned by a method is (rather conveniently) called a return value. If a method has a return value, then it will pass information back to us. This information could have a number of purposes. For example, the return value might be an indication of whether or not the method completed successfully. Alternatively, the method could also pass back the results of some processing that it did for us. It can even return another object as a result.

As the user of an object, we can decide whether we want to do anything with the return value. If the information is pertinent to what we are doing, then we can capture the return value and do something with it later. If we do not care what the return value is, we can just ignore it and continue with our work.

Just as the methods of the telephone object can have parameters, we can identify those methods that pass return values (and these can be passed as parameters to other methods), and what those values mean.

Method Name
Return Value

PlaceCall
True (if call completed successfully)
False (if call failed)

Answer
No Return Value

HangUp
True (if telephone was hung up successfully)
False (if not)

SendCardNumber
True (if card was accepted)
False (if card was not accepted)

Disconnect
No Return Value

Events
We have now looked at two of the three characteristics of an object. The properties and methods of an object are ways that the user of the object can communicate with the object. Now, what if the object needs to communicate with the program that created it?

As an example, consider what happens when our telephone receives an incoming call. The fact is that it needs some way of telling us to answer the call. How will the telephone communicate this information to us?

Again, it's possible for the telephone object to have a property (called IncomingCall, perhaps) that was set to 'True' whenever an incoming call was present. However, there are two disadvantages to this. First, it would require the user of the telephone object to check this property on a regular basis. Second, the user would require a great deal of knowledge of the inner workings of the object, which isn't ideal.

What is needed is a way for the object to tell the user that something has happened. The mechanism for this is called an event. An object generates an event whenever something of interest happens. In our telephone example, when the telephone receives an incoming call it tells us so in the form of an event – we'll call it the IncomingCall event. (On most telephones, this particular event takes the form of the telephone ringing.)

The telephone object would generate an IncomingCall event every time an incoming call is received. In a physical phone, the ringing sound is the phone notifying you of the IncomingCall event. When the user receives this event, it can execute the 'Answer' method (pick up the handset), and begin the call. This frees the user from having to check regularly for incoming calls: the event is designed to notify the user just at the appropriate moment.

Just like methods, events can have parameters. These parameters can hold specific information about the event. For example, if our telephone supports CallerID – a feature that reveals the identity of the incoming caller – then the IncomingCall event could include a parameter that contains the telephone number of the incoming caller.

Here is a list of the events that our telephone object will generate, along with their associated parameters:

Event Name
Parameters

IncomingCall
Incoming CallerID information

LineBusy
No Parameters

There are a couple of useful pieces of terminology that are often used in this context. When an object generates an event, the object can be said to fire the event. When the object has fired the event, we say that the user must handle the event.

Synchronous vs Asynchronous
One of the advantages of working with objects and events is that it awakens us to the concept of asynchronous programming. First off, let's look at the definitions of synchronous and asynchronous.

These terms refer to how two separate actions are related to each other. If the first action must be completed before the second one begins, then these two actions are said to be synchronous. If the second action can begin at any time, no matter what the status of the first action, then these two actions are said to be asynchronous.

We've already discussed what it would be like if we our objects didn't support events. For example, to detect an incoming call, you would need to constantly check the value of some property to see whether an incoming call was waiting. While you're performing these frequent, regular checks, you would be unable to perform other tasks dependent on the outcome of that task. This is an example of synchronous activity. For example in the real world you might be waiting for a telephone call from a friend to let you know what time you should meet them. You can't go out until you've arranged a specific time. It's the same in programming. Your program could be waiting on a WaitForAnIncomingCall method in a While ... Wend loop, and it could be stuck there until the call was detected, refusing to return control to the main body of your program.

With events, we can have asynchronous activity. By having an event handler that is called when the object fires the 'IncomingCall' event, we can perform other tasks (for example, making an outgoing phone call) without having to devote any effort to monitoring the incoming call status. Our event handler code will be dormant until such a time as it detects the 'IncomingCall' event, and then sets about dealing with the incoming call.

This is not to say that all synchronous is bad and all asynchronous is good. You will see many instances in the real world where it makes sense to use a synchronous activity to perform a certain type of processing. Likewise, we will also see instances where an asynchronous activity is not an optimal way of dealing with an event.

Encapsulation
One great thing about objects is that you don't have to understand what's going on underneath the shell, to know how to operate them. With our telephone we don't need to know how our voice is projected from the phone, down the wires to the nearest exchange, and how from there it gets to our intended destination. This is all hidden from us. It's the same in ASP – you don't need to know how the object was programmed, for example, in C++ or VB (objects can be created in many languages), to be able to interact with it. The concept of a user of an object not being concerned with the inner workings of the object, is known as encapsulation. For example, when you use a telephone to answer an incoming call, all you need to do is pick up the handset. You don’t need to know how the transistors are connected to each other inside the telephone. This is the equivalent of executing the Answer method. You do not need to know what's going on underneath – that's all encapsulated within the Answer method. This is an example of encapsulation.

One advantage of encapsulating the workings of an object within a method is that the implementation of the method can be changed without having to adjust the client. For example, suppose the phone company decides to change the way that an incoming call is answered. Without encapsulation, all of the users of the telephone object would have to be adjusted to support this new way of answering the phone. Instead, by encapsulating these new steps within the Answer method, the actions of the client never need to be changed: with either system, all the client needs to do is execute the 'Answer' method. Not only does encapsulation make the telephone user's life easier; it allows the developer of the telephone object to change the implementation at any time.

Moving On to Programming
Now that we have a basic understanding of what an object is, we can move on to looking at how programming concepts have changed from traditional methods by using objects. When working with objects in software development, we will create objects that have properties, events and methods. We can use these three attributes to describe physical objects and abstract concepts. Either way, the programmatic object will allow us to interact with it through its properties, events and methods.

back | Contents | Forward