Свойства объектов (Delphi)

[FliPP]

Для меня не совсем понятно, каким образом осуществляется связь между полем объекта и свойством этого поля. В примере в учебнике, при описании класса, названия поля и его свойства различаются только начальной буквой f (FName - поле, а Name - Свойство) Возможно в этом все и дело?!?! Других "указателей" принадлежности свойства полю я там не нашел. кстати вот этот пример:

type

TName = string[15]; 
TAddress = string[35];

TPerson = class
private
FName: TName; 
FAddress: TAddress; 
Constructor Create(Name:Tname);
Procedure Show;
Function GetName: TName;
Function GetAddress: TAddress;
Procedure SetAddress(NewAddress:TAddress);
public
Property Name: Tname
read GetName; 

Property Address: TAddress 
read GetAddress
write SetAddress;

end;

[Jeni]

Сообщение от FliPP

В примере в учебнике, при описании класса, названия поля и его свойства различаются только начальной буквой f (FName - поле, а Name - Свойство) Возможно в этом все и дело?!?!

Дело совершенно не в этом! Как называется поле и связанное с ним свойство - личное дело программиста. Они связаны друг с другом так же, как название переменной с её реальным значением, т.е. никак! Просто "правила хорошего тона" рекомендуют такие названия, чтобы при просмотре исходных текстов по имени поля можно было сразу понять название свойства и наоборот. Свойства просто "маскируют" работу с полями объектов и приводят всё к единообразному виду, т.е. программист, используя свойства работает "как бы" с обычными переменными, а на самом деле компилятор вместо этого подставляет "правильные" вызовы.

Что касается конкретного примера, если P: TPerson
X := P.Address; преобразуется в X := P.GetAddress;
P.Addres := X преобразуется в P.SetAddress(X) - в действительности вызывается процедура (т.е. метод) куда в качестве параметра передается X, а уже в процедуре SetAddress значение X как-то записывается в переменную FAddress (или любую другую).
Если бы не было свойств, то все эти вызовы методов пришлось бы писать программисту, а со свойствами выглядит так, будто идет присвоение обычных переменных. Вот и всё.

Тут, конечно, можно спросить, а нафига вообще вызывать какие-то методы вместо того, чтобы прямо читать/писать из/в FAddress? А дело в том, что иногда (и даже часто) требуется:
1. Выполнить определенную проверку вводимых данных. Например, вдруг фамилия должна записываться только большими буквами? Если писать "напрямую", то в FAddress данные запишутся в том виде, в каком будут в переменной X, а вот если "скрытно" вызывается SetAddress, то данные сначала преобразуются как требуется, а уже затем запишутся на хранение в FAddress.
2. Возможно потребуется выполнить другие действия, например, "оповестить" другие объекты об изменении/добавлении данных в этом объекте. Или записать в лог-файл кто/когда/откуда внес эту запись.
3. Ещё пару тысяч возможных причин...

[FliPP]

Ясно. но я все равно не до конца понял, каким образом компилятор определяет, к какому полю принадлежит это свойство?! Почему ,например свойство Name относится к полю fName, а не к fAddress??? ведь там же не написано конкретно: свойство *** - свойство поля f***!!!! или важен порядок описания полей и их свойств????

[Jeni]

Порядок описания полей и методов не важен (хотя требуется, чтобы поля были описаны перед методами). Если бы свойство было записано так:
Property Address: TAddress read FAddress write FAddress;
то компилятор бы действительно "определил" что с чем связано.

Но в примере написано по-другому:
Property Address: TAddress read GetAddress write SetAddress;
Это означает, что компилятор понятия не имеет, что свойство Address связано с переменной FAddress - эта "связь" задается в методах GetAddress и SetAddress.

Я конечно не знаю конкретной реализации, но в качестве примера:

Function TPerson.GetAddress: TAddress;  
begin
  Result := FAddress;
end;

Procedure TPerson.SetAddress(NewAddress:TAddress);
begin
  // Возможно какая-то предварительная обработка строки
  FAddress := NewAddress;
  // Возможно какая-то постобработка строки
end;

Для свойства Name - аналогично.

[FliPP]

Вот!!! Теперь все понятно!!! В учебнике не было приведено конкретной реализации методов, а я и не догадался, что в конкретном примере "связи" как таковой и нет то))) Спасибо за разъяснения!!!

[Jeni]

Рад, что помог. В книгах действительно часто всё описано формально правильно, но без объяснения "на пальцах" и отдельные тонкости и "внутренние механизмы" остаются непонятыми. Наверное потому, что авторам эти вещи кажутся настолько "ясными и так", что даже в голову не приходит, что другим оно вовсе не ясно.
Вобщем, как говорится, обращайтесь.