Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Access and Assign vs. OOSE
Message
General information
Forum:
Visual FoxPro
Category:
Object Oriented Programming
Miscellaneous
Thread ID:
00149911
Message ID:
00150125
Views:
45
Jim,

I can see a small difference here, but not a large one. After all, in your example the outside world needs to know the name of your method. And if you change the method name, you'll break everything. Using Access and Assign, you just have to think of public properties as part of the interface and change them at your peril (just like a public method).

I can see your point if the user will only need to perform a limited number of tasks related to the property (as in your AddToTotal example), but if you're just going to write a GetMyProperty method and a SetMyProperty method, what are you really gaining over Access and Assign?

>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.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform