Difference between property and function or procedures

Question

Can we say :

type
  TPerson = class
   private
     pName : string;
   public
     property Name : string read pName write pName;
end;

Is equal with :

 type
  TPerson = class
   private
     pName : string;
   public
     procedure SetName(val: string);
     function GetName:String;
end;

//{... implementing SetName And GetName...}

??

Please explain to me where we need to use "property" and where not. Tnx

Answer 1

It's all about the design of the class. Technically, 'everything' you can do with properties, you can do without them, but the code will not be as elegant. Good design also makes the classes easier to use, and reduces the risk of making mistakes.

First, your comparing

TPerson = class
  private
    FName: string;
  public
    property Name: string read FName write FName;
  end;

to

TPerson = class
  private
    FName: string;
  public
    procedure SetName(const Name: string);
    function GetName: string;
  end;

isn't quite fair. Indeed, in the first case, you have no chance of doing something when the value is set (or read). So a more appropriate comparison would be to compare the latter code to

TPerson = class
  private
    FName: string;
    procedure SetName(const Name: string);
    function GetName: string;
  public
    property Name: string read GetName write SetName;
  end;

For instance, if you write a control, you often need to invalidate (basically, repaint) the control when you alter a property, say, the 'Sweater colour' of the TPerson. For instance,

TPerson = class
  private
    FSweaterColor: string;
    procedure SetSweaterColor(const Value: TColor);
  public
    property SweaterColor: TColor read FSweaterColor write SetSweaterColor;
  end;

  ...

  implementation

  procedure TPerson.SetSweaterColor(const Value: TColor);
  begin
    if FSweaterColor <> Value then
    begin
      FSweaterColor := Value;
      Invalidate; // causes a repaint of the control
    end;
  end;

Anyhow, what's the point of properties? Well, the point, basically, is to make a nice interface of the class: It should be easy to use for someone not interested in the details of its implementation. By using properties, you can achieve this goal. Indeed, to read the current colour of the sweater, you just read Anna.SweaterColor, and to set it, you just Anna.SweaterColor := clRed. You don't know if this simply sets a variable or causes a procedure to run, and you don't care. As far as you are concerned, a TPerson object simply has a readable and setable property called SweaterColor.

You can also create properties that are read-only (no write) or write-only (no read). But no matter how you implement the read and write (if at all) of a property, the property will look the same from the class user's point of view. He need not remember to use SetSweaterColor or GetSweaterColor (in fact, they are private and not accessible to him), but only the SweaterColor property.

This also hints at another benefit of using properties. Public and published properties are visible to the users of the class, while the private members are not (like the field FSweaterColor and the SetSweaterColor procedure). This is good. Because now you know that the only way for the class user to change the sweater colour of a person is to use the SweaterColor property, which guaranteed will repaint the control. If the FSweaterColor variable were public, the user of the class might set this and wonder, "why doesn't anything happen when I change the sweater color?" Of course, you don't need properties to get this benefit: a private FSweaterColor field and public GetSweaterColor and SetSweaterColor would do just as well, but then you'd need to write a GetSweaterColor function even though no processing is required to get the color. Also, the user of the class need to learn to use two identifiers instead of one.

More concretely, if you use the Delphi IDE to program, you will see that the published property (-y+ies) will show up in the Object Inspector, where you are allowed to read/change them (if applicable). How would that be possible if it weren't for properties?

All this being said, sometimes you don't use properties even though you could. For instance, if you have a read-only 'property', you might go for a single public GetSomething function instead of a read-only property. After all, that would save you some coding. Similarly, if you have a write-only property, you could go with a single public SetSomething procedure, which will also save you code. Finally, if you have a read/write property that requires no processing either way (neither to get nor to set), you could simply use a public variable!

So, after all, you need to decide on a good design of your class on a class-by-class basis. I guess the short version of my overly long answer is similar to David's comment:

Use whichever you prefer, whichever is more convenient.

Answer 2

Properties is a nice piece of syntactic sugar. They are equivalent to a pair of getEnabled and setEnabled Methods, but most programmers (and programming languages) prefer properties instead. For example there are less entries in the code-completion window.

Furthermore they separate "variable like" stuff (so the data, the object is supposed to work with) from the methods that work with the data.

Properties are not limited to components, they are very useful otherwise. You can define a public interface with a property and implement some validation logic afterwards. (Not possible with a public field) But you nee only two lines of code for a simple property, compared to 8 lines for the methods.

More important for the object inspector is the published keyword, only published properties are displayed in the OI.