I agree. This point seems moot. If you argue that Get/Set are advantageous because you don't have to modify the middle tier to add a field, but you _do_ have to modifiy the field to practically use the get/Set methods (to add logic), this point defeats itself. IMHO Access/Assign is just as clean as Get/Set.

The property 'accessed' using access/assign doesn't even have to be the property that actually stores the value! I could add a property and corresponding a/a methods called obiz.fullname that returns obiz.fname + " " + obiz.lname. In this case, the real properties aren't exposed at all. Doesn't this conform to the assertion that object should hide properties? If you agree with this then the a/a propertyhaving a different name from the actual property becomes a triviality. I could change the name of the property without changing the public interface at all. Just like get/set.


>Jim,
>
>It seems highly probable though, that adding a field to a table is going to also cause code to be added to the business rule tier. So you would end up changing all three tiers.
>
>>However, six months after release a field is added to the customer table in the database. The property design requires that the database by modified (to add the field), the business object be modified (to add the new porperty), and the UI be modified (to display the enw field).
>>
>>With the Get/Set methods you only need to modify two of the three tiers, because the business object can be coded to try to get whatever field value was requested without restriction. You add the field to the database, and modify the UI to display the field and that's it. No modifications required to the business object.