Hiya Jim -----

External couplings and subsequent dependencies!! Yes. Doggone it, I knew I was overlooking a reason why Set and Get seemed to be purer (my terminology sucks). Then again, look at this:

VFP has Access and Assign
VB has Get and Let
C++ has obj::func(parm)
SmallTalk has something else (Don't remember)

They all operate on the same principal so to quote an old song "Everybody's doing a brand new dance now....c'mon baby, do the locomotion".

TGIF.


>
>Except for the fact that the outside world has to know the name of MyProp. For example, I design a class and it has a property named nTotal. The property is used by the outside world to say Obj.nTotal = obj.nTotal + SomeValue, which is trapped by an assign method and processed correctly. Now I design another object and give it a method named AddToTotal and it is used in
>
>Obj.AddToTotal(SomeValue)
>
>which interface is cleaner? The answer lies in part in how well the implmentation fo teh totalling is hidden from the outside world. In the former the outside world does the totalling by adding a value to the current property value. In the latter, the object with the nTotal property does the totalling and no outside object even knows what the name of the property is. Also, if I later choose to modify the way the class does its totalling I can do that easily in the latter case without changing anything but the AddToTotal method, in the former case I would need to be careful not to change the name of the property or else I would need to visit every object that might use that property and make changes there as well.
>
>It is an issue of external coupling. Using methods reduces external coupling. Does this mean we should never use properties as public interface components? No, it simply means that we need to be aware that using properties as part of the public interface increases the external couling and produces issues that need to be addressed because of that. Then choose the most pratical approach to solving the problem.