Page 1
Page 2
Page 3
Page 4
Page 5
A few days ago I had the opportunity
to attend the Microsoft release of Visual Studio .NET in
Chicago. Steve Ballmer and Bill Gates both spoke about the
new advantages that Visual Studio .NET will bring to its
developers. At the heart of the improvements incorporated
into Visual Basic .NET is the implementation of object-orientated
programming (OOP). The new release of Visual Studio insures
that in the future, nearly all programmers, including developers
targeting the PocketPC, will be writing their programs in
an object-orientated fashion. Whether you choose to stick
with current languages like C++ and Java, or move to the
new offerings from Microsoft such as J#, VB.NET, or C#,
you will be programming with an object orientated language.
So what’s so great about OOP?
If you do not have much experience programming
in an OO language, some of its major benefits are:
Inheritance
Inheritance means that if I wanted to add some additional
functionality to my Telephone class, such as creating
a CordlessTelephone class, I would not have to recode
the entire Telephone class. The Telephone
class already knows how to dial, ring, and send my voice
over the phone line. The CordlessTelephone class
can inherit all the functionality of the Telephone class,
while adding the ability to transmit signals from the phone
base to the cordless phone receiver.
Encapsulation
When I pick up the phone and dial number, I don’t
need to know HOW the phone is connecting me to the
person I am calling. When the phone rings, I don’t
need to understand HOW the phone knew to ring. To
use a phone, all I need to know is how to interact with
it, and that’s all. This is encapsulation. All the
functionality of a phone is encapsulated within the phone
itself. I know that when I dial “0”, the phone
will take care of all the steps needed to connect my receiver
with the operator without me doing anything else. Encapsulation
also hides, or protects, the functionality of a class from
the rest of the program. For example changing the channel
on my television will not affect the functionality of my
phone because the logic of the phone is hidden and protected
from the functionality of the TV.
Polymorphism
Polymorphism allows you to write code that can predict
the future! Don’t believe me? Let us say that I am
writing a program that will monitor and control all the
electronic devices in my house. My DVD player will need
methods like Stop, Play, and Pause,
while my Television will need methods such as Mute,
SetChannel, and VolumeUp. But all my devices
share some similar functionality, such as PowerOn
and PowerOff. I could create a “base” class
called Device that all other devices would inherit
from. Because all my electronic devices will inherit from
my Device class, I could write some code to turn
off all my devices such as:
Public Function TurnOff(colDevice as Collection)
For each objDevice in colDevice
objDevice.TurnOff()
Next objDevice
End Function
Because of polymorphism, it doesn’t
matter if objDevice is a Television object,
a DVDPlayer object, or even a Toaster object.
So how can polymorphism predict the future? Well, when I
get my “Rehydrator” (as seen in Back to the Future
II) in thirteen years (2015), I will be able to create a
Rehydrator class that inherits from my Device
class, and my TurnOff function will be able to work
with my new Rehydrator class with no extra coding!
Any future class that inherits from my base class will work
with all functions that use the base class.
Code Reuse
This is easy. Just like a module, but better. Once
I have coded a “Telephone” class, any program
I (or others) write can instantly take advantage of the
Telephone object.
Readability
OOP makes reading code easier, plain and simple.
myPhone.Dial(“5557575”)
You can look at this 1 line of code and know what it is
doing, without knowing anything else about the program.
Code Replacement
Because of the way OOP works, you can upgrade your
program’s components without worrying as much about
the effect it will have on the rest of your program. I can
go buy a new telephone tomorrow, replace my current telephone,
and not worry if I will be able to use it, or if it will
screw up my toaster. I know how to interact with a basic
phone, new or old, and my new telephone won’t interact
with my toaster. No problems.
It’s an OO world, but not for
eVB
So now that we have talked a little
about why OOP is a GOOD thing, we come to the real challenge.
How can we program in an OO fashion, using a language that
is not based on objects and at the same time has no collection
objects to work with? Well thankfully, Odyssey Software
has developed a set of utilities called OSI
Utilities that provides eVB developers with a Collection
object (as well as fixing the CreateObject memory leak).
We will be implementing the OSI Utilities Collection in
many places in our code. To get more information or download
the control go click
here. In eVB you can’t utilize a Class file,
so I had to decide how I could structure my code to get
around this problem. It was not a perfect solution, but
I decided to use the Form as my class file. You might
think that a module would be the ideal choice, and actually
it would be, except for the fact that eVB treats private
variables and functions in a module as public, and you can’t
access a function inside a variable with the syntax ModuleName.FunctionName().
You can check out these
two
links for more info about how Microsoft altered modules
in eVB. The Form object, on the other hand, allows you do
access its methods and variables in the syntax of FormName.FunctionName()
as well as correctly encapsulating private variables and
functions. From now on, I will be referring to my Form/Class
objects as Classes for simplicity.
Next Page