1. Technology

Accessing an Object and its Data - Delphi OOP Part 4 / Chapter 9

Delphi OOP Part 4 / Chapter 9

By

Materials written by John Barrow. Modifications by Zarko Gajic

Back to Chapter 8

Introducing (in this Chapter)

  • Data access methods: Get… and Set…
  • Properties for data access: Mapped and direct, read and write specifications.
  • The concept of ‘Patterns’ in object orientation
  • The Immutable Pattern

Properties

A consequence of providing encapsulation is that we must write access methods to provide a public interface to the data fields. Delphi also allows us to use properties for this public interface.

We have already used properties extensively when working with Delphi’s VCL components and in this example we see how to create them (properties) for our own classes.

Ex 4.3 step 1 Defining properties

Class TClient in ClientU.pas has two private data items, FAccNo and FCName (lines 6–7 of example 4.2 step 1, and below). We’ll introduce properties for these, called AccNo and CName, through the type declaration in ClientU.pas (lines 15–16 below). We move the Set and Get methods from the public section (Example 4.2 step 1 lines 11–14) into the private section of the type declaration (lines 8–11 below). Then we add the property declarations to the public section (lines 15–16) but do not interfere with the underlying data items FAccNo or FCName.

The implementation section remains unaltered.

 4 TClient = class (TObject)
 5 private
 6   FAccNo: string;
 7   FCName: string;
 8   // access methods now private
 8   function GetAccNo: string;
 9   function GetCName: string;
 10   procedure SetAccNo(const AnAccNo: string) ;
 11   procedure SetCName(const ACName: string) ;
 12 public
 13   constructor Create (ACName, AnAccNo: string) ;
 14   destructor Destroy; override;
 
 15   property AccNo: string read GetAccNo write SetAccNo;
 16   property CName: string read GetCName write SetCName;
 17 end; 
A property has public visibility (eg line 15 above). Its declaration is introduced by the property keyword, followed by the property’s name and type.

By convention the property names are the same as the underlying data names but without the preceding ‘F’.

Next comes the read keyword followed by the read mapping between the property and the underlying data. Here we use the same GetAccNo function that we used before to supply the value of the FAccNo data field. (GetAccNo is now declared as private: line 8 above) Next comes the write keyword followed by the write mapping, and we use the same SetAccNo function that we used before to modify the value of the FAccNo data field. So we use the same Get… and Set… methods as before for the mapping methods with property based access, though these access methods are now often declared as private.

Note that we declare the Get and Set mapping methods and the underlying data fields before we declare the properties. If we don’t, the compiler does not know of the existence of these data and methods when it encounters the property declaration.

And there they are! We have declared two properties.

Ex 4.3 step 2 Using properties

We are already familiar with using properties from RAD components. Change the method calls in ObjectAccessU.pas (example 4.1, step 2) to property references as follows (lines 52–53 below):
 procedure TfrmAccessObject.btnShowClick(Sender: TObject) ;
 begin
   { .. if statement as before .. }
   lblName.Caption := 'Name: ' + NewClient.CName;
   lblAccNo.Caption := 'Acc No: ' + NewClient.AccNo;
 end; 
Run the program. The operation on the screen is just as before.

In this example we see how properties use access methods. Properties provide the same encapsulation advantages as access methods. For example, if in the future we need to change the representation of the underlying (private) data we can do so and then do the necessary type translation in the property’s mapping access methods. The external interface remains the same and the client using the property remains unaware that there has been any change. As we illustrate in example 4.4 below, we can also do access control, range checking, data validation, event initiation and so on in the access methods should we need to.

But if there is essentially no difference between using properties and using access methods, what’s the big deal? Why not just stick with access methods?

As we’ll see in the next step,under certain conditions properties allow us to simplify a program by doing away with the Get… and Set… mapping methods while retaining the benefits of encapsulation.

©2014 About.com. All rights reserved.