Objects and object oriented programming

Object oriented programming is often referred to as if it were something resembling the "black arts"; some mysterious mumbo jumbo stuff that is usable only at the highest level of programming expertise. In fact, object oriented programming is more natural to use than conventional, top down, structured programming.

What makes object oriented programming appear to be difficult is that it cannot be taught by conventional means because it is neither a method nor a procedure. It cannot be learned from a set of rules or from a syntactical dictionary of code because it is about having a conceptual framework which comes about through thinking in a particular way.

In the introduction to "Lingo Sorcery", I likened the understanding of object-oriented programming to that of learning to ride a bicycle or to drive a motor car, where the understanding just "comes" as a result of experimentation and practice.

An object oriented programming environment can be thought of as consisting of an empty shell which obeys instructions to fill the shell space with objects of the programmer's imagination.

The objects filling the shell space can be anything which the programmer dreams up and these objects are activated by messages. The message paths, that these messages take, make up an infra structure which join all the objects together into an interacting system which also includes communication links to the environment outside of the programming shell.

Programming in OOPS requires that you think of the shell as "reading your instructions" to create things you ask for. It is somewhat similar to using the holodeck in the Star Ship Enterprise where you tell the computer what you want it to create for you - except the things which are created in OOPS have no physical reality other than in your own head (and recorded as off and on states of switches in a micro chip).

Using Lingo as an example (other languages are similar in principle), you create an object by means of a single simple statement, made to the shell, such as:

set myObject to new(script "descriptionOfObject")

"DescriptionOfObject" is a field where you have typed in all the things you want the object to do when it receives particular messages. The myObject is a variable (usually a global variable) which is set to contain an address to a sector in computer memory where all the details of the object are stored.

Although the variable myObject is only an address, you can think of the variable myObject as the object itself, thus, any messages sent to myObject will be acted upon as if the message were being sent to an object whose name is the name of the variable. This "object" then does what you expect the named object to do as a result of sending it a message.

As an example, let us create an object named "joe".

set joe to new(script "Joe")

In the text description of Joe we might have a handler:

on whoAreYou me
  put "I am Joe"
end

With this simple handler placed into Joe's description text field, Joe will always answer "I am Joe" when a whoAreYou message is sent to Joe from either the shell or by another object:

whoAreYou Joe

The answer comes back:

"I am Joe"

With a little imagination you can create all sorts of object handlers to do all kinds of things in response to messages sent to them. You can even get objects to put themselves onto the screen so that other people, besides the programmer, knows they are in existence.

If that were all there were to objects, there wouldn't be too much to them. However, objects are allowed to possess personal memories and have characteristic properties. In other words, every object has within its digital space in the computer a portion of memory that it can use privately.

In this way objects can store details of personal features (such as a picture of itself which it can place onto the screen). It can remember details or records of events or lists of other objects. It can retain memories of recent experiences and even store abstract qualities of itself like 'emotions' and state of health.

The programming to arrange objects to have these things is very simple indeed and, once you get the basic idea, object oriented programming is just a matter of dreaming up objects and getting them to send messages to each other.

Adding greatly to the power of such inter connecting communication structures is a very simple property called an ancestor. This ancestor property you can think of as being a message portal: it is a property which contains the address of another object where message go if the object doesn't have a handler which recognizes them. The way this works is that if an object receives a message that it does not recognize (does not have a method handler to respond to it) the message is passed on to the object whose address is contained in it's ancestor property.

The magic of this ancestor property is that it allows objects to be set up into networks of message paths: where messages can be sent along predetermined pathways. Not only this, the message paths can be reconfigured at will because a message can be sent to an object telling it to change its ancestor. Getting whole groups of objects to change their ancestors will reconfigures networks (as you will see later).

The figure below illustrates diagrammatically what a programming shell in an object oriented programming environment "looks" like:

Diagram of objects created in an object oriented programming shell

Each object would have the following (diagrammatic) form:

Diagram of an abstract object

Once you have understood that OOPS isn't about programming per se, you can then concentrate your thinking upon your ideas and your imagination. You will then discover the real power of OOPS.

Although OOPS revolves around objects and messages, it is actually about something much more. It is about using different paradigms, or, looking at things in different ways. It is about intangible mechanisms and organization which emerge as a result of objects communicating and cooperating. It is about objects working together, to produce a total whole which is much more than the sum of its parts.

OOPS is implemented in Lingo (and many other computer languages) by objects which can have memories and storage containers. This allows you to design objects which can recognize, sort, combine and rearrange things. OOP objects can communicate and cooperate; they can integrate and share their expertise; they can be given tasks and responsibilities. Objects can even be made to be intelligent and make decisions in a human like way (as will be explained later).

The conventional use of Director, as a multimedia authoring tool, sees the screen images represented through the metaphor of a stage: where the stage is fed with a continuous stream of composite images contained within frames. Object-oriented programming allows a richer, more flexible approach. The 'on screen' presentations can be arranged through a 'team' of control objects which, although independent of each other, work in coordination to construct the features of scenarios in virtual space.

Different objects in this 'team' can be responsible for visual or audio components, sound, timing, animation and all kinds of specialist interaction devices. The author, of this object-oriented environment, conjures up suitable control objects and tells them what to do to construct the required scenarios. The author can use some of these specialized objects to set up interactive dialogue exchanges between themselves and the user.

This information flow forms a pattern which, although intangible, is as much a part of an OOPS system as the objects themselves. The paradigm shift needed to appreciate all this is to raise your awareness above the level of the individual objects to see the whole thing as a single self actuating system which is regulated and controlled from within by internal feedback messages.

Object- oriented programming can also get your multimedia product to do quite sophisticated tasks and operations because the objects can be equipped with various forms of built in intelligence. For example, conversational interactions between user and computer can be tracked, analyzed, parsed and monitored to facilitate dynamically responsive behavior according to how the user responds.

Objects can be set up to behave in constant and predictable ways, or, they can be made sensitive to the environment, or to the actions of other objects , and made to react accordingly. They can even be given a virtual brain and be empowered to make virtual emotional decisions.

However, as attractive as all this sounds, we cannot get away from the basic reality that asking somebody to create an object-oriented program is like giving them an empty space and asking them to fill that space with products from their own imagination.

Unless the imagination is triggered...

...that space will remain empty.

[Index]
[Next - A Conventional View of the Web]
[Back - Object oriented thinking]

Return to main website