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
What is an object?
An introduction to properties, methods, and events
How can we change the characteristics of an object?
How do we know when the object tells us something?
What is an object model?
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:
Certain properties that define and describe it
A set of things or methods that it lets us do
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
Things that describe the telephone
Things that we can do with the phone
Things that the telephone tells us and that we can
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.
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
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.
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.
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
Now that we have a way of describing the telephone object,
let's take a look at what we can do with it.
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:
Place an outgoing call
Answer an incoming call
Hang up the current call
Enter or send our calling card
Disconnect the phone from the
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
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:
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
Suppose that we want to place a call. Simply calling
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,
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:
Set the OutgoingTelephoneNumber property value to
the desired phone number
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:
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:
Outgoing telephone number
Calling card number, PIN
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
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.
True (if call completed
False (if call failed)
No Return Value
True (if telephone was hung up
False (if not)
True (if card was accepted)
False (if card was not accepted)
No Return Value
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:
Incoming CallerID information
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
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.
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 dont 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.