Difference between property and function or procedures - delphi

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.

Answer 3

No. These two codes are NOT equal.
We use property when we implement the TPerson class as a component, customizable in Delphi's Object Inspector. Take a look at the TButton class, for example. All the things you can alter in the Object Inspector (Caption, Width, Name, etc.) are marked in the source code with the property keyword.
If you create a class that will be used in your program but not as a component, you don't use the property keyword.