Originally published in FoxTALK August 1999

To See or Not To See

In this column we will investigate the visibility of properties and methods.  Visual FoxPro gives us three Public, Protected, and Hidden.  What exactly is each of these and where should we use one of them over another?

A Little Class

One of the goals of Object Oriented development is to isolate the data and behavior required in a particular class to that class alone to reduce the level of dependency that a particular class has on other, unrelated, classes.  These dependencies can even be a problem within the same class tree affecting how super (parent) and subclasses interact.

To examine the visibility of these settings we will use a small example of a class structure.  The diagram below describes the example.

In this example there are two class definitions txtBase and txtSubClass.  TxtSubClass is a subclass of txtBase.  There is a form with an instance of txtSubClass, txtSubClass1, in it.  The txtBase class has a property, Prop1, added to it and marked Hidden.  TxtSubClass has a property, Prop2, added and marked protected.


The first visibility to discuss is the Public setting.  Creating a property or method that is Public causes that property or method to be visible, that is able to be read/written/executed from any object or class without limitation.


A Protected property/method is available to only the class that created the property/method and subclasses of that class.  The visibility extends on down the subclassing tree if there are multiple levels below the creator. (Prop2 in the diagram above is visible to txtSubClass but cannot be addressed in code that is in the txtSubClass1 object or in the Form object)


A Hidden property/method is visible ONLY to the class that created it.  Subclasses don’t see this property/method in their property sheet and they cannot access it (a VFP error occurs). (Prop1 in the above diagram is addressable ONLY by the txtBase class, txtSubClass cannot address the property and the property’s name does not appear in txtSubClass’s Property Sheet)

Why should I care?

One of the underlying tenants of OO Design is “Hiding the implementation of an object”.  This means completely concealing the exact mechanism that any particular object or class uses to meet its responsibility.

Often, an object may need some internal data or functionality that is meaningless outside the scope of that object.  If these properties and methods are visible to the outside world then there is a possibility that they may get accessed by some code that should not be doing that.  Using the visibility you can control absolutely, what can and can not access properties and methods.

Note: You can also change the visibility of the Visual FoxPro properties and methods using the Edit Property Method dialog.

A Case for Hidden

You are designing a form class that will be used by other developers through subclassing.  One of the behaviors for the class would be better served if it were divided into multiple methods instead of one big one.  However the sub-methods are useless outside of the class and a developer overriding one of them would render the class non-functional.  You can make one method Public, the one that developers would call to start the behavior, but make the sub-methods Hidden so the developers don’t even know they exist.

A Case for Protected

You are creating a widget class that needs some internal storage of its state.  You create a set of properties to store that state.  If some object outside the class modifies these properties the state of the object is lost.  You make these properties Protected and nothing outside of the object can address them.

Using Access and Assign methods

You might be thinking wouldn’t using access and assign methods do essentially the same thing as protected properties?  No exactly.  Access and assign methods allow you to respond to something addressing a property but they don’t prevent the addressing.  In some situations you may want to allow outside objects to update or read a property and you need to do something based on what was assigned or read.  In this case access or assign method is the way to go.

However, creating an assign method that always discards the assignment is like helping a burning person by holding them under water for 30 minutes.