[fpc-pascal] property or public

[Damien Gerard]

On Jan 21, 2008, at 4:47 PM, Joao Morais wrote:

> Matt Emson wrote:
>> Joao Morais wrote:
>>> Damien Gerard wrote:
>>>>
>>>> On Jan 21, 2008, at 2:52 PM, Joao Morais wrote:
>>>>
>>>>> Damien Gerard wrote:
>>>>>> I have (it would seem) a stupid question :)
>>>>>> We have TStringList vars. User can do what he want with it.
>>>>>> Which one is the stupid or the better way to do it ?
>>>>>> TMyClass = class(TObject)
>>>>>> public
>>>>>>  <snip>
>>>>>>  List1: TStringList;
>>>>>>  List2: TStringList;
>>>>>> end;
>>>>>> or
>>>>>> TMyClass = class
>>>>>> private
>>>>>>  FList1: TStringList;
>>>>>>  FList2: TStringList;
>>>>>> public
>>>>>>  property List1: TStringList read FList1;
>>>>>>  property List2: TStringList read FList2;
>>>>>> end;
>>>>>
>>>>> The later, *much* better. You should never use class members  
>>>>> outside the private area.
>>>>
>>>> Thanks ! What is the reason ? I am happy I was right but I need  
>>>> some reason :)
>>>
>>> Encapsulation, on behalf of the integrity of the instance.
>>>
>> Implementation detail is also a good example. Then:
>> TMyClass = class
>> private
>> FList1: array of string; //convoluted, but uses a different storage  
>> mechanism
>> FList2: array of string;
>> protected
>> function GetList1: TStringList; virtual;
>> function GetList1: TStringList; virtual;
>> public
>> property List1: TStringList read GetList1;
>> property List2: TStringList read GetList2;
>> end;
>> You can implement the storage for GetList1 and GetList 2 any way  
>> that you wish internally, but give a uniform external interface.
>
> Exact, polymorphism is also a reason. You can have abstract methods  
> and no class members if the design requires. The interface continues  
> the same.

That is what I thought too. But I wanted external advice.
Thanks to all !



--
Damien Gerard
milipili at shikami.org

Le temps n'a pas d'importance. Seul le code est important
    -- (f00ty)