1. Technology

Programmer Defined Classes and Objects - Delphi OOP Part 3 / Chapter 6

Delphi OOP Part 3 / Chapter 6


Materials written by John Barrow. Modifications by Zarko Gajic

Back to Chapter 5

Introducing (in this Chapter):

  • Keeping user interface and application objects separate: separation of concerns,
  • Mimicking RAD user interface objects in programmer defined application classes,
  • Steps in using a programmer defined object:
    • define the class,
    • allocate a name (reference),
    • instantiate the object,
    • assign it to the name.


One way to make a computer program more robust and more amenable to change is to build it in layers. One might have a user interface layer that takes care of the interaction between the user and the program, an application layer that implements the operations required by the application, and a persistence layer that takes care of permanent storage of the data. This approach is sometimes called "The Three Layer" model and is one implementation of a principle called the "Separation of Concerns principle.

Delphi’s GUI generator addresses the user interface layer very effectively. But what about the application layer? To begin we look at defining and instantiating our own classes to provide application logic. While it is possible to add application logic to the RAD generated user interface objects, it is good programming practice instead to separate the user interface from the application and it is from this perspective that we will develop our own classes.

Creating a Simple Non-Visual Class

When we create a new form in Delphi, we reuse a number of existing classes, such as a TForm, TButton and TLabel, and combine them to create a single, new, visual user interface class. Our early programs consist of single form objects and the entire program operation occurs within these self-contained objects. However, an object oriented program is a system of cooperating objects, and we soon move on to programs with several form objects. Each of these has a separate user interface object that communicates and cooperates with other user interface objects in the program.

But a realistic program does not consist only of user interface objects. It also contains application objects and these are the focus for this chapter. Application objects are programmer generated since the RAD support for generating user interface objects is not possible in the same way for application objects.

To establish a context for programming an application object, we’ll use the example of a conveyor belt that moves items in a warehouse from storage to a despatch area. To keep track of the number of items, an ‘Add Item’ button is clicked as each item goes past on the conveyor belt. A supervisor displays the total number of items by clicking and holding down a Display button. When the button is released, the display is cleared. At the end of each shift, the total is reset to zero.

The user interface appears in figure 1 and the Object Tree View, which is available in Delphi 7 and shows the components on the form, appears in figure 2. (Delphi 2006+ has the Model View, which is a bit more sophisticated.) We’ll develop the program in stages to help clarify some of the important characteristics of OO programming. First we’ll create a non-OO program, where we use a simple variable to keep track of the number of items. Then we’ll make the item count part of the form, which leads to a combined user interface / application object. Finally, we’ll create an application object separate from the user interface object.

Example 3.1 A NON-OO Program

Start a new application. On the basis of the Object TreeView (figure 2) add components to the form either from the Component / Tool palette or, in Delphi 7, by using the menu sequence View | Component List. To make our programs more readable we’ll use a three letter prefix. Thus a form will be called frm..., a button btn..., a label lbl... and so on.

Ex 3.1 step 1 Using a "global" Variable

Our first version uses an integer declared in the implementation section of the unit to keep track of the number of items (lines 26–27 below). As part of the form type declaration we have a private data field called Count that has been commented out through curly brackets (line 20). We’ll use this as an alternative in the next step.

©2014 About.com. All rights reserved.