> > Thomas,
> >
> > I acknowledge your point that using OOP one can write very bad code and the use of public variables does not prevent a developer from writing good code. As long as you are maintaining the code and know and follow your own rules, things could go just fine.
> >
> > I think Borislav brings up the most relevant point, however. Using public variables is like leaving a minefield for a developer that has to follow you in maintaining or modifying your code. (And that developer might be you if you haven't touched the code for a few months and modified your own patterns.)
> >
> > From Steve McConnell's Code Complete: "Public data members are, in my view, always a bad idea. They blur the line between interface and implementation, and they inherently violate encapsulation and limit future flexibility."
> >
> > The simple truth of that statement is undeniable. The degree to which you achieve encapsulation and cohesion is the degree to which extension and modification of your code will be simpler. Public variables do not make it impossible to write decent code but they make it a whole lot harder. If you want to make your life harder, that is certainly your prerogative.
>
> Hi Pamela
>
> A non-hidden property of an object instantiated to a public var is almost as bad as a public var. The property is "encapsulated" into the design of the object at design time, but at runtime said property is not shielded from changes by other running components. I seldom see anyone hiding any properties or methods.
>
> Mike Yearwood
> www.foxridgesoftware.com
> President: Toronto Ontario FoxPro User's Group

A non-hidden property of an object instantiated to a public var is, for all intents and purposes, a public var. (That might actually be Thomas' point.) Steve McConnell follows the above quote with this sentence, "Strongly consider hiding public data members behind access routines."

That said, I admit I have an application object with public properties, in two of my applications. (In my defense they were created in the late 90's when that was the conventional wisdom and I was still new to OOP.) The visible properties are read-only to all except the application object itself who populates them at startup. Still, that's not much different than a startup routine that populates a half dozen public variables that are never altered during the application life.

The difference is that with the public variables, a developer can later come along and decide that a particular public variable is handy and change it's value in a specific routine and there is nothing to prevent him from doing that. Whereas the properties of a public object can be made unalterable outside the object (as per Mr McConnell's advice).

pamela