Partager via

Publisher Programming Made Easy: Why Program with Objects, Anyway?

  • Article

I’m writing a series of articles for beginners on how to program the Publisher object model. These articles focus on the practical side of programming, and only go into enough conceptual detail to explain what the code is doing.

So I thought readers of those articles might have some questions about what’s really going on, and why programming is structured the way it is. As it happens, I gave a short presentation to the other Publisher technical writers on this subject a few years ago. So I dusted off my presentation, and I plan on excerpting some of the relevant portions in my next two entries.

This stuff’ll be old hat to anyone who’s done basic object-oriented programming, but my hope is that it’ll answer some questions for people who haven’t and encourage them to get their feet wet.

So, here’s today’s topic: why do we program using objects, anyway?

The short answer is that, as programs get more complicated, objects provide several distinct advantages over the way programming has been done in the past. Object-oriented languages have three main characteristics that make them better to use than procedural programming languages: encapsulation, polymorphism, and inheritance.

Encapsulation

Objects package data and procedures into building blocks, based on real-world scenarios, with which to construct complex programs.

Objects can be defined and maintained independent of one another. A change to one object does not affect another.

Objects function as black boxes; their internal processes are invisible (and inaccessible) to other objects and code. They only respond to the messages defined for them.

 

 

 

 

 

 

 

 

PropertyA

 

 

 

 

ObjectA

PropertyB

<

Message

 

ObjectB

 

MethodA

Return Data

>

 

 

MethodB

 

 

 

 

 

 

 

 

 

 

 

You cannot access the properties or methods of an object directly. You have to access the properties and methods by sending the object a message.

A message is the name of an object, followed by the name of a method that the object knows how to perform, or a property the object has. For example:

Page.Delete

Note that we have no idea how the Page object performs the Delete method. We just know that when we send the following message, the Page object deletes itself. That’s the essence of encapsulation.

Signature is the format the message must take in order to be understood by the object. Parameters (also sometimes called arguments) are any additional information the object must know in order to perform the method. Parameters may be required or optional. The message signature defines what information they get back (if any). This is also called the return type.

A typical signature for an object method might look something like this:

Object.Method(Parameter1, Parameter2) As ReturnType

Transport.Travel (DepartureCity, ArrivalCity)

Technically, parameter refers to the data type, while argument refers to the actual data value passed in a specific instance. But that’s splitting hairs. Most programmers use the terms interchangeably (and incorrectly).

Programmers sometimes refer to the properties and methods of an object collectively as that object’s interface. That’s because those properties and methods are the only way you can interact with the object. The rest of its operations are hidden from us.

An object’s interface (or message interface) is the collection of message signatures that object implements (performs). These signatures are the only way for other objects and code to access the object. The inner workings of each object is a ‘black-box’ to other objects; they cannot access the data in an object directly.

Polymorphism

Polymorphism refers to the ability of different objects to respond to the same message in different ways.

Different objects can respond to the same message in different ways. This is because the procedure (i.e., the property or method) for that message has been defined within each object.

To expand on our earlier example, here’s several objects, each of which implements a Travel method:

Car.Travel(Chicago, Los Angeles)

Plane.Travel(Chicago, Los Angeles)

Boat.Travel(Chicago, Los Angeles)

Bike.Travel(Chicago, Los Angeles)

As you can see, each object would implement the Travel method in a very different way. But because the Travel method for each is contained in the object itself, it doesn’t matter. And you could add other objects later with their own Travel methods, and this does not effect the existing objects or procedures using those objects.

Inheritance

A class is the template that defines the methods and properties included in a particular type of object. An instance is an example of that object created (or instantiated) when the program is running. One way to think of it is this: the class is the blueprint, while the instance is the actual, specific house.

A class: Page object

Three instances: Page 1, Page 2, Page 3

Classes can be based on other classes. This is called inheritance. The object based on other objects (usually called derived classes, or subclasses) inherit all the properties and methods of the first class (usually called base class, or superclass). However, they can substitute methods of their own for the superclass methods. They can also contain additional properties or methods.

Classes can be nested to any depth, with subclasses inheriting all the methods and properties of the classes above it.

The term virtual class refers to a class that other classes will be based on, but which will never actually be instantiated in the program.

Note that Visual Basic 6.0 is not a completely object-oriented language, because it does not support inheritance. You cannot (really) base classes on other classes in VB or VBA 6.0. You can in VB.Net, however, which is one of the appeals of that language.

Also, be aware that inheritance has nothing to do with how objects are structured in an object model. In an object model, objects that contain other objects are called parent object, while objects contained in other objects are referred to as children of the containing object. This has nothing to do with inheritance. The child objects do not inherit properties or methods from the parent objects. For example, in the Publisher object model, the Page object inherits none of its members from the Document object, which is one of its parents.

Comments