Maximizing.ASP.dot.NET.Real.World.ObjectOriented.Development [Electronic resources] نسخه متنی

Analogy to a Car

People have compared objects to cars as long as object-oriented programming has been around. Hopefully we can push that analogy further by connecting the benefits of using a car with the concept of object-oriented programming.

Think of the blueprints for a car as your class. When your automaker needs to create a car, it instantiates that class (the blueprints) into an object (an actual car). The code might look like this in C#:

Car MyCar = new Car();

Before the manufacturer is done with the car, they'll set some of its properties. It has properties for Color, Vin (vehicle identification number), and so on.

MyCar.Color = Red;
MyCar.Vin = "1234567890";

So now that you have this car, wouldn't it be fun to drive it? Before we get into it, we want to pull up the antenna so we can listen to the radio. The car object already exists, so we're going to call its RaiseAntenna() method like this:

MyCar.RaiseAntenna();

We need to unlock the car, but that's a little trickier. For that we need a key. The car has an Unlock() method, but that method takes a key parameter. Our car object has those fancy key-code pads on it, so all we need to know is that the code is "1234." We'll unlock the car by passing in that code with the Unlock() method.

MyCar.Unlock("1234");

You can see that manipulating our car object (making it do something with methods) is pretty easy. We could go on like this with examples that call other methods to accelerate, brake, and so on, but you've probably seen examples like these before.

What's the benefit of this car object? To start with, the data associated with the car, such as its color, is easily changed. As a user of the object, you don't need to know how to paint a car; you only need to assign a value to its Color property. You don't need to know about the inner workings of the car's locking mechanism; you only need to know that there's an Unlock() method and that it requires a key.

Going back to our spot of code that manipulates Customer objects, we don't need to know anything about the underlying code or the data store where our customer information is kept. All that matters is that we have this object that we know is supposed to manipulate data in a database.

How would you do this in script? In the best-case scenario, you would use an include that has some functions you can call to act on this data (which isn't really best-case at all because the interpreter has to interpret all that code every time, even if you don't use it). In the worst case, you're writing the same kind of code every time you need it in every page on the site. This is not a good use of your time, and making a simple global change like this becomes a nightmare.