Object Orientation Concepts

The distinguishing characteristic of object-oriented programming languages is the design of objects.

Suppose we wished to keep track of all the information about the green floppy disk where we are saving this document. We would need many variables . We could give them names like greenDiskFreespace, and greenDiskWriteProtected. But we quickly see that the code grows unwieldy when we wish to also create representations of a translucent red disk (where we store a backup of this chapter), a nontranslucent red disk (which holds a copy of "Ozymandias"), and a yellow disk (which was just formatted).

By contrast, we can create an object. An object is a collection of variables and functions that represent some thing. It can be a physical dingus in the outside world ”like a rocketship or floppy disk. It can be a well- understood abstraction ”like a savings account or a 3D transformation matrix. Or it can be a new abstraction that we invent for our own convenience ”like a trivia question or an internet socket. The fundamental requirement is that our thing has some standardized definition and makeup or that we can create one for it.

To then use the object, we instantiate it. Instantiation consists of creating an actual variable that represents a particular copy of the object we just created ”for example, the green instance of the general object type FloppyDisk.

Classes

The code that defines an object needs to be written only once. That abstract definition of the generic object is usually called the class. A class merely explains how the object is constructed , exactly what the object is, and what it does. It is also called a template for the object (or an object's factory ). Sometimes the word is prototype or even symbol.

In fact, since the abstract object is called the object, that word is also frequently used to refer to this formal declaration. This is especially true in languages like ActionScript, where the terms class, template and factory do not appear in the language. Class appears briefly in the documentation and symbol is used for the special case of MovieClip objects.

Instances

Once we have designed an object, we want to create a number of instances of the object. After we create a class template for a FloppyDisk object, we might spawn one, two, or even a thousand FloppyDisks. The thousand instances behave the same, but each has its own identity. Each one has a distinct name . The instances of the object FloppyDisk have all its properties and methods , but each has its own individual value. For example, values for its label and its contents would probably be unique. What one instance of FloppyDisk does (for instance, call the function eject() ) affects neither the general class nor any other instances of FloppyDisk.

Objects have the following components :

P ROPERTIES

An object that simulates a floppy disk has certain qualities, or properties. It may have a physical size , stored in length, width, and thickness , a string that contains its label, a boolean that indicates write protection, and some quantity of data content. By defining what variables every disk has, we can create several disks that have all the variables we just defined. We can either set up the properties to automatically have a default value or assign values to them later.

So far, objects offer little more than other data structures. Why would anyone want to orient their programming around them?

M ETHODS

Then we add the object functions called methods. Instead of having a loose function called format that can operate on floppy disks, we can have a function called format within the FloppyDisk object. So we can merely say myFloppyDisk.format() and the floppy disk object, which under stands its own inner workings, formats itself. An object function serves two important purposes. First, it allows us to transfer a self-contained object to anyone who may need it. The second purpose is encapsulation.

E NCAPSULATION

Encapsulation hides the inner workings of an object. Whether the FloppyDi sk is a software abstraction or a real disk formatting itself with motors and magnets is nobody's business but its own. Without knowledge of the object's insides, other software and programmers are unable to fiddle with the object and break things. Instead, they can manipulate the object only through an interface that the object's creator designates.

Most object-oriented languages (like Java or C++) force programmers to respect these interfaces. ActionScript does not. It is quite easy to cheat and ignore the distinction between public and private parts of the object. But self-discipline will reap important advantages. These advantages all derive from knowing what the object does ”but not how it does it.

It is easier to change an object, because we can change the internal functions and variables and leave the outside interface the same. Imagine if we had to go through various modules updating them all because we've figured out how to make the format command more efficient. Encapsulation also makes it easier to work with other people. A single person may need to know exactly how the object works, but a team does not. It doesn't matter to other programmers how it works; it just matters that it does (this is the way we might feel about an air conditioner).

I NHERITANCE

Further, we can set up relationships between objects. A FloppyDisk is one specific type (also known as a child) of the general object Disk (other children might include HardDisk and CDROM ). In this case, it is said that FloppyDisk inherits from Disk (also known as its parent). For instance, Disk may have a format() command. In that case FloppyDisk would also have a format() command, by default identical to the Disk.format() method. Further, FloppyDisk would have the same variables that Disk has. This is one of the main advantages of object orientation: its inheritance from Object, to Disk, to FloppyDisk (Table 2.1).

Table 2.1. Inheritance from Object, to Disk, to FloppyDisk

OBJECT	ToString()
Disk
FloppyDisk
FloppyDisk instance

E XTENSION

Note the extension of the format command in Table 2.1. If a child object did nothing more than duplicate its parent, inheritance would not be a powerful idea. Inherited traits are modified to meet the needs of the child class. An object-oriented software model of a FloppyDisk might format itself exactly as a generic Disk does. (Set data to be nothing, set free space to be maximum.) But the CDROM object would have a different format routine. (Fail.) No problem. It can overwrite the format routine it inherited.

An object can simply extend its inherited methods. For example our FloppyDisk object might add an extra instruction to the Disk.format() it inherits. (Take a really long time.) Rather than copy code, we say, "Take a really long time" and then format yourself however a regular Disk would be formatted. Extension allows changes to be made at the parent level and trickle down. We can reliably make sweeping changes in small amounts of time.