Pragmatisim over purity??? There are places where you can shot for such heresy < bg>


>John,
>
>Assign/Access can be thought of as owner object safety nets. You can prevent your object from being assigned invalid property values, and give them back a result that is potentially filtered. ie they ask for the value of cTopSecretPassword and the object just always replies "None of your business"
>
>Personally I HATE the thought of writing Get/Set for every darn public property. Sometimes practicallity just has to win out over OO puritism. And as long as it's the declared public interface to an object who the heck really cares if it is:
>
>? oObject.TheProperty or ? oObject.GetTheProperty() or ? oObject.Get( "TheProperty" )
>
>personally I prefer the first.
>
>>Maybe it's academic, but responsibility for changing or exposing a property should be in the owner object and not in the calling object. Set Set and Get on object1 side are more in fitting with theory than Assign and Access on object 2 side....
>>
>>Then again, the argument could also be made that you can bend the rules within a single tier and physical layer (DLL,EXE) :-)
>>
>>I'm having one of those "OOP vs. reality" intellectual crises :)
>>
>>
>>>I guess what I meant was that ACCESS is the Get construct and ASSIGN is the Set construct. I don't really see the difference between using ASSIGN and creating your own Set method.
>>>
>>>>Well....but in theory object 1 shouldn't even *query* object 2's property directly at all, although it could call an object2.GetProperty("propertyname")...so...essentially...Access and Assign are N/A in a true object environment because you should be using Set and Get style constructs to message between objects....see?