Classes correspond to improper nouns (which are indicated, in English, by names with a lower-case first letter). Classes correspond to sets of things with similar characteristics.

• The class of "cows", for example.

Instances of classes correspond to proper nouns (which are indicated, in English, by names with an upper-case first letter).

• "Betsy" is an instance of class cow. Betsy is-a cow.

An object is an instance of a class; it corresponds to a proper noun.

• The "Betsy" object is the instance of class cow that is named Betsy.

An object has:

	State		All the object's attributes and their current values.
	Behaviour		How the object acts and reacts as it processes messages and changes state.
	Identity		The object can be distinguished from other objects, by a specific identifier, or by its other attributes.

In Perl, a new instance of a class can be created like this:

• my $cow = Cow->New(Name => "Betsy", Color => "brown");


Also, the previous example assumes the existence of a constructor for the cow class, which looks something like this in Perl:

• sub Cow::New { my $C = shift; bless({@_}, $C); }

Classes may also have a destructor, which is automatically invoked when the computer removes an instance of the class from memory. Objects can be removed from memory either as explicitly instructed by the programmer, or via garbage collection (which happens when no other in-memory data references the object, so the object can never be accessed again).

It can be argued that every class is also the set of all objects that are of the class, and that every class is also an object which is an instance of its parent class. This need not concern us here.

Every object has a set of named values that describe how it differs from the other objects in its class. These values are known as the object's attributes, properties, or instance variables.

• Betsy's cow "color" may be brown or black, for example.

• Cows have an attribute named color that may have the value brown, black, &c.

Every instance of a class has the same attributes because the set of instance variables comes from the object's class.

• Each cow has-a color, Betsy's color is brown.
• Betsy's color is part-of Betsy.

The New constructor shown above automatically creates instance variables for the values passed as its parameters. In addition, instance variables may be set and accessed like this:

• $cow->{Owner} = "Mr. Farmer";
• print "$cow->{Name}: owner = $cow->{Owner}\n";

The output from the previous print would be » Betsy: owner = Mr. Farmer

Messages correspond to verbs. Messages are communications between objects. Messages specify actions for objects to take. The sender of the message is known as the agent. The sending of a message is known as an event.

• Betsy, "Moo"!

• Betsy, "are you hungry"?

Messages can have parameters.

• Betsy, Moo "Loudly".

Messages can return results.

• "Yes (says Betsy), I am Hungry."

The methods an object uses to handle the messages it understands are determined by the object's class. Methods specify an operation on an object. A method is the mechanism that descrbes how an object responds to a message.

When Betsy gets the "Moo" message she uses her cow nature to act in such a way as to moo. The how-to-moo instructions are available to Betsy by virtue of her being a cow (an instance of the cow class). The mooing instructions are part of her cowness.

A method is invoked by a object when it gets a message that is connected to the method. The connection between a message and the method that handles it is usually made by name. The following is valid Perl, for example:

Invoking a method involves an object getting the method's instructions from the object's class and then carrying out the instructions. Here is an example of such instructions written in Perl:

The previous examples, combined, would produce » Betsy moos, loudly.

The parameters of the message are passed to the method for use by its instructions. Inside the method $I is the current instance (object) itself. Methods can change object state (attribute values) and send further messages.

Methods that are invoked by their class name, as in Cow->New, as opposed to via an object, as in $cow->Moo, are known as class methods. Class methods can do anything ordinary methods can, except that they are not passed an object to act on ($I). A simple example of a class method is:   sub Mammal::IsWarm { return 1; }

Classes are structured into a taxonomic hierarchy based on a categorization scheme. Each class is said to inherit from the class that is its parent or super-class in the hierarchy, and is said to be a sub-class of its parent, or a derived class thereof.

• If Betsy is an instance of class cow, and the cow class inherits from the "mammal" class, then Betsy is also an instance of class mammal. In such a case, cow is-a kind-of mammal, cow is a specialization of mammal, and mammal is a generalization of cow (and, presumably, other kinds of mammals).

Inheritance provides the ability to define a new class by combining and augmenting the behaviour of existing classes; the "programming by extension" style.

Objects can respond to messages that don't have corresponding methods defined in their class by delegating the message up to its ancestors. That is, when you send a message to an object, the object looks first for a corresponding method in its class, then in its parent class, its grandparent class, and so on. The same search rules apply to finding an object's instance variables.

• You may be able to tell Betsy to shed by virtue of her being a cow (which is a mammal), because the mammal class has a Shed method, even though the cow class doesn't have its own explicit Shed method.

Here is an example in Perl:

The previous example produces » Betsy sheds.

A class can override an inherited method to modify the behaviour of its instances. For example, we can add the following method to the previous example:

The previous example produces » Betsy sheds brown fur.

Here is a UML diagram showing how every mammal has an exclaim method that must be implemented in each descendent, cows have a new method called stampeed, and goats override their inherited move method to take into account that some goats refuse to move quickly.

As a design principle inheritance should not be used to reuse implementation (code). It should only be employed to reuse and extend functionality.

In some programming languages a method must be explicitly declared to be virtual in order for it to be overridable. In Perl all methods are virtual, but we use the term virtual to describe methods that are designed to be overridden.

A class which is explicitly designed to be the super-class for a set of dependent classes, but which does not itself provide sufficient functionality for independent use, is known as an abstract base class (ABC). A method in a ABC which must be overridden in each descendent class (and will fault if not) is known as an abstract method.

In some programming languages a class can have more that one super-class, which is known as multiple inheritance. In Perl, for example, one might have:   @PetDog::ISA = (Pet, Dog);   in which case attributes or methods that are not found in the PetDog class will be searched for first in the Pet class, and then in the Dog class.

The term "object-based", as opposed to object-oriented, is sometimes used to describe programming languages that have so-called objects but which don't support inheritance. Such languages tend to be less than optimal candidates for software development.

Encapsulation refers to the fact that we can only talk to Betsy via her published interface, that is, by her cow API. We shouldn't just go in and change her color, we should send her a message to (say) ChangeColor.

• This means that Betsy can know that the color-state-change message implies that she must send herself the Shed message.

• The chameleon class would implement the method differently.

Encapsulation is an information hiding technique; it supports implementation of black-box classes for use as components in frameworks. An interface is an outside view of an entity which emphasizes its abstraction while hiding the the structure and details of its implementation. An entity can have many different interfaces. The implementation of an entity can be altered without changing the interface.

An accessor is a method associated with an attribute. The purpose of an accessor is to provide a means of getting the value of the attribute, and setting the value of the attribute. Direct access to attributes is then forbidden. The advantage of having accessors is that they act as gateways, and thus can exercise control over access to the attribute. For example, by disallowing setting of the attribute, or by monitoring when the value is set, or perhaps ensuring that some consistency criterion is met when changing the value, or not allowing reads of the attribute when it may be inconsistent. Accessors also allow attributes to be derived, and not directly mapped into data values.

Most programming languages provide for some control over the visibility of attributes and methods, which can be used to move the responsibility for complying with encapsulation from the developer to the programming language. Perl does not provide this control, but we often use the terms in method comments to indicate the intended use for the method. Here are some common visibility specifications.

	Public		Any object can see the attribute/method.
	Private		Only the object itself can see the attribute/method.
	Protected		Only the object itself and objects in the same or descendent classes can see the attribute/method.
	Friend of foo		Only the object itself and objects in class foo can see the attribute/method.

Polymorphism literally means "multiple form". If we have instances of the cow and goat classes with the following methods in their interface, then we can send either the "Exclaim" message, even though different implementations may be invoked. And, we can send the message without even knowing whether we have a cow or a goat.

A collection of classes that work together as a subsystem to provide a collective functionality to other classes can be considered to be a service. When requesting functionality, the client object is the one acting in the role of requesting the service, and the server object is the one in the role of supplying the service.

Often a service will be provided by a special singleton object that acts as a dispatcher for the set of messages that provide the access to the service. Such a server object is the controller of a collection of objects that provide the service. The collection of objects are collaborators.

In a typical business data-processing application there is a set of business objects which are instances of classes that are designed to provide long-term storage for business data (and the related functionality).

Most of these applications use a relational database management system to store business objects between their uses. This hybrid storage systems is known as an OORDBMS.

A typical OORDBMS stores all instances of a class in a single database table, with one row per instance, and one column for each persistent instance variable.

Since RDBMS systems are designed to operate on schema that are in third normal form (no repeating fields), the mechanism for implementing a one-to-many relationship between objects must not store the identities of the many objects in the one (which can be done with in-memory objects). Instead, each of the many must store the identity of the one in their persistent data. Then, when the many must be operated on, the database query engine can be asked to select all the many that have identified the correct one in their persistent data.

The less familiar one is with these terms and concepts, the more carefully one should apply the terms. If you find yourself using one of the phrases shown below, make sure you're clear on what you mean.

The OO-experienced will observe, for example, that since one can't have an object method one must mean "object's class's method" if one says "object method". However, if one says "object method" thinking that they can change the method just for the object, without changing it for the whole class, they are likely to be disappointed. Emptor culpa.

There is no magic in OO. It just reflects our experience that you get a big improvement in the quality of your applications if you have language support for the following notions:

1. Encapsulation of services (Abstract Data Types improved)

2. Taxonomic reuse (i.e. inheritance)

3. Polymorphism

How can we illustrate this with a problem? Let's use directory advertising.