About   -   Contact   -   Purchase   -   Search   -   What's New

Object Variables Should Always be Private
When attempting to encapsulate a class that will be inherited you would normally declare the variables as protected so that they can be accessed be derived classes but are protected from aggregate and associated relationships.

The problem with this is that it generates a higher level of coupling between the ancestor and the descendant. The impact of changing the way a particular attribute is managed could potentially impact all operations on the object.

If a class is badly designed allowing protected attributes to be directly accessed and modified by derived classes can cause the impact of a change to be very extensive. To minimize problems, it is better to make all class attributes private and not directly accessible by external or derived classes.

    This design convention has three main benefits;

  • Low Coupling: The way that the attribute is managed, the Datatype or the type of information it holds can be changed while still presenting a standard interface via function overloading.
  • Superclass: By providing get/set operations to the attributes it makes it possible for a derived class to override the operations. This means that other operations on the superclass would be unaware that they were actually invoking a completely different behavior than simply storing and retrieving the attributes value.
  • Attribute Extension: A derived class may want to extend the functionality of an attribute. This would be impossible as all ancestor functions and descendant functions changing the attribute would not make your derived class aware of the change without a design change to the original ancestor.

To summarize all attributes should be private with protected methods for getting and setting the attributes. In my new framework the get and set methods are named the same as the attribute with function overloading:

ls_Var = is_SomeVar()
is_SomeVar( "New Value" )


Top of Page

Legal Notice

Ken Howe 2011