Key Concepts

In its most basic, fundamental sense, OOP is about creating simulations: To an OOP programmer, all computer programmes are 'simulations' (not just structured collections of procedures operating on some data). To create a simulation, you need to create a world of interacting objects.

Objects and classes

Central to the 'Object orientated' programming methodology is the 'object'. Most things in Director can be conceived of as objects (casts, cast members, scripts, script instances, the stage etc.). Objects have the ability to store data (in 'properties') and respond to messages (using their 'method' - which is like a 'handler'). Objects are 'real', tangible things (in the 'world' of a computer simulation). They are also 'instances' of abstract concepts. (for example, in Director there is the concept of 'sprite' - something which is drawn on screen, has properties such as location and blend. Sprite(1) is a real, tangible instance of the 'sprite concept). In OOP terminology, the 'concept' is called a 'class' - and all objects must belong to a class. Objects also have 'names' so that we can refer to them.

For example, I have a cat (an object) which is an instance of the "Domestic Short Hair Cat" species (a concept) and it is called "Charlotte" (its name). In programming Lingo, the object's name is usually called a 'reference' and the variable that is given the object's reference is called the 'instance variable'. This 'reference' is also sometimes called a 'pointer' since it acts as a 'pointer' to the object.

So in Director, if you have some lingo like this

Charlotte = script("DSH-Cat").new()

The script "DSH-Cat" is (roughly) analogous to a class (since it defines our concept for what a 'domestic short hair cat' is), and the variable 'Charlotte' contains a reference to the object created using the script and new Lingo.

In Director, references are very important for two reasons: (1) you need them in order to send messages to objects; and (2) if there are no references to an object stored anywhere, then Director will assume the object is no longer needed and will destroy it (in a process called 'garbage collection').

In Director, you are working with objects all the time (sprites, cast members, lists, images etc.). Parent Scripts and behaviours are especially useful because they allow you to define your own 'concept' of an object. Whereas the 'sprite' concept is built into Director, with parent scripts and behaviours (which are essentially the same thing, by the way) you can create any concept (or 'class') you want. For example, you could define the concept of "ball" or "popup menu" or "context-free bottom-up language parser". The objects created from scripts are sometimes called "child objects" or "instances" (or just 'objects').

Abstraction

The process of working out what classes (concepts) you need to create a simulation (programme) is called "abstraction". This process involves breaking down large complex system into smaller easier to build objects that represent simpler abstract ideas and tasks.

Communication & Encapsulation

A key facet of OOP is how objects communicate with each other. Because data belongs to an object, the data should only be changed by the object that "owns" it. This is achieved by sending messages to the owner object. The methods or handlers that an object uses to respond to messages are often called the object's interface. This interface encapsulates an object's data and methods of manipulating that data, and allows us to separate an object's behaviour from its implementation. This separation, treating objects like 'black-boxes' whose internal workings are kept hidden, is essential for creating re-usable objects that can be used in stable and easily maintained systems. An internal methods (methods which should not be called from outside the object) are referred to as the object's "private methods". The methods which are available as part of the object's interface are called "public methods". Lingo, unlike some other programming languages, doesn't allow you to enforce this distinction between public and private methods - all methods are effectively 'public'. It is up to you, the developer, to ensure objects only ever call the methods that have been nominated as 'public' and forming part of the object's interface. Similarly, in lingo it quite easy to change the data stored in an object's properties without going through the object's interface. To be true to the idea of encapsulation (and to encourage better OO system design), it is important to resist changing the object's properties directly and, instead, only ever send messages to the object's interface and let the object that owns the data make the necessary changes.