|
| What is object orientation?
|
| Before the mid 1980's, the majority of programming languages used commercially operated in a procedural manner. You could trace the code operation linearly line by line. The only jumps were as a result of conditional logic and subroutine calls.
|
| This was proving to be an error strewn method of writing large applications. You could happily modularise it by packaging sub-programs into functions or procedures, but there was a limit to how these helped you. Not least because subroutines do not hold onto their data across calls.
|
| Also, with the advance of graphical interfaces, and a principally mouse click driven user interface, programs were becoming event driven. They needed to respond to whatever of the many possible gui (graphical user interface) objects on the screen the user chose to click next.
|
| Object orientation radically changed the face of programming for many people. It took the concept of subroutines into a completely different zone. Now they retained their data, and were in fact, collections of routines under one umbrella. You called an object to do something, and left the object to sort out how it did it. You did not need to furnish the internal data since it was retained across calls. For example, a list object could have items added or removed from the list at will. And the object could be asked to sort the list into sequence.
|
| Objects also allowed events, such as mouse clicks, to be handled neatly - a button object could call a routine (method) of another object when clicked. This was now true moduralisation.
|
|
The basic parts of an object oriented program
|
| The basic building block of an Object Oreinted (OO) program is a Class. It defines data (now called fields) and functions and procedures (both now called methods). One class can have many fields and methods, just as we described with our list object.
|
| Additionally, OO introduced cleaner ways of allowing fields to be seen externally to the class - via Properties. Now a class can have methods and properties - we seldom let fields be seen externally - they are used internally to make the class work. A Property can be read only, write only or both. All very neat.
|
| But a class is only a set of field, property and method definitions. It is a data type. We must create an instance of a class before we can use it. We can make any number of instances of a single class. For example, we may make 3 different list class instances - one for CDs one for LPs and one for Cassettes. Each list object hides its storage of these lists. We merely access its internal lists by the provided methods and properties. A read only property, for example, may give the size of the list as it stands at the moment.
|
| Creating an instance of a class is called instantiation, and generates an object. Each instance of a class is a separate object.
|
|
An example of a class and an object
|
| Here we will define a very simple class that has one field, one property, and one method:
|
| type
// Define a simple class
TSimple = class(TObject)
simpleCount : Byte;
property count : Byte
read simpleCount;
procedure SetCount(count : Byte);
end;
|
|
| We have defined a class called TSimple as a new data type. It is a data type because we have to instantiate it to create a variable. We create an object by calling the Create method. Ah ha! There is no Create method that can be seen. This is because we have inherited it (see the Inherit tutorial for further) from the motherf of all classes : TObject. This is the class we have based our class on. In fact, TObject is assumed by default, so we could have typed :
|
|
|
| Our code has a field called simpleCount that is a Byte type. It can be read by the count property. When we do, we use the property name count, rather than the internal simpleCount name.
|
| Our method SetCount sets the simpleCount value. Before we go any further, we must define this method, or our code will not compile:
|
| // The TSimple class methods
procedure TSimple.SetCount(count : Byte);
begin
// Assign the passed count to the local variable
simpleCount := count;
end;
|
|
| We simply store the passed SetCount parameter into the local variable. This means that someone who has created a TSimple object can call SetCount to store a value internally. They can then use the count property to read it. This is how:
|
| var
simple : TSimple;
count : Byte;
begin
// Create an object from our simple class
simple := TSimple.Create;
// Set the count value in our object using the TSimple SetCount method
simple.SetCount(12);
// Ask for this value back - use the TSimple count property
count := simple.count;
end;
|
|
| The count value is now set to 12
|
|
| Take a careful look at this code. We create the simple object by calling the class Create method. A lot of people try to call the simple variable Create method. This is not possible - simpel is null until it is assigned an object. Calling TSimple.Create in effect returns an object reference that gets assigned to simple.
|
| We can then call the SetCount method to set the count, and use the count property to get this value. A very simple object, but it is designed to demonstrate rather than do anything useful.
|
|
Inheritance
|
| Now that we have a class defined, we can create objects from it. But supposing we want to have another class, maybe a list with some bells and whistles. We could change our class, or we could define another class based on this class. This is called inheritance - our new class inherits from the existing class. See the Inheritance tutorial for more on this.
|
|
Private, protected, public and published sections
|
| The class we defined did not bother about classifying the field, property or method. By default, they are all available externally. we can use on of the following classifications to protect or expose as appropriate. Click on a type for more information.
|
| href='RTL.asp?Name=Private'>Private Defines data as internal only to this class
href='RTL.asp?Name=Protected'>Protected Defines data as internal this class and subclasses
href='RTL.asp?Name=Public'>Public Defines data as internal and external
href='RTL.asp?Name=Published'>Published Defines data as internal and external *
|
|
| * Published data can be interrogated at run time, but is beyond the scope of this web site.
|
| You should use private except where you expect any inherited classes to want to use the data. We should change our simple class as follows:
|
| type
// Define a simple class
TSimple = class
private
simpleCount : Byte;
published
property count : Byte
read simpleCount;
procedure SetCount(count : Byte);
end;
|
|
|
Constructors and destructors
|
| Supposing when we created an object from our class, we wanted to make sure that it had a count right from the start. We can do this by providing a Constructor method. Such a method does at it says - constructs the object. Here is how our code looks with a constructor:
|
| type
// Define a simple class
TSimple = class
private
simpleCount : Byte;
published
property count : Byte
read simpleCount;
procedure SetCount(count : Byte);
constructor Create(count : Byte);
end;
|
|
| Note that this is in fact a procedure, but is called a constructor. And that it invokes a method called Create. You are not obliged to call it this, but are highly recommended. We must define this constructor:
|
| constructor Create(count : Byte);
begin
// Save the count value locally so that we have a starting value
simpleCount := count;
end;
|
|
| Now we must pass the count when we create the object.
|
|
Method overloading
|
| In the past, with procedural languages, you would code two differently named routines for the same kind of functionality when you wanted two ways of pasing the data to the routines. For example, a routine to fill a rectangle may take the rectangle parameters individually, as TPoints or a TRect.
|
| With method overloading, the same name can be used for this routine. Delphi decides which routine to call by the number and type of parameters.
|
|
Polymorphism
|
| Polymorphism is defined as the ability for related, but different objects to implement the same method in their own way.
|
| For example, in a graphics application, we may have circle, square and triangle objects, each of which could have a Draw method. This would look the same to the caller, but each object would draw in a different way of course.
|
| These objects could, but needn't be inherited from a common ancestor class. This is not the point - the same method has many forms - polymorphism.
|
|
Abstraction
|
| Another fancy word, but again, a fundamental part of OO, even if too few people use it. Abstraction is where a class defines methods as skeletons. It does not provide the code to run them. Instead, it insists that inherited classes do so. The idea is that the parent class clarifies to subclasses exactly what methods they need to provide for consistency. For example, a music device class may have abstract methods for loading the media - only when you create a CD version of the class can you know how to load the music. See Abstraction tutorial for more.
|
|
Interfaces
|
| Interfaces are even less used than abstraction. They are a specialised form of abstraction. An interface definition comprises only abstract methods. Any class implementing an interface must implement these abstract methods. A class can implement more than one interface. The idea is that interfaces define a set of standard operations or properties that certain types of class should have. See the Interfaces tutorial for more.
|
| | | | |
