[Lazarus] OOP basics - 2

[Marco van de Voort]

On Fri, Apr 16, 2010 at 01:54:55AM +1100, Alexander Klenin wrote:
> > IMHO there is a bigger chance in making mistakes in micromanaging visibility
> > that you regret later, then making dangerous mistakes because private is
> > visible inside an unit.
> 
> Maybe, but note that fixing "too strict" visibility is a trivial
> one-line change,

And of course the reworking of the manual (if public interface changes),
and coping with descendants that define something with higher visibility
already.

IMHO visibility is like a contract. It shouldn't be constantly changed.

> while fixing "too lax" visibility might require a serious code refactoring.

I don't see why. It will very rarely bite you when moving classes out of
units, but then there is already refactoring going on, interfaces are
changed, and one or two lines more won't care.

> More importantly, most bugs are easy to fix once you fully understand
> the software architecture and the nature of the problem.
> It is that understanding that is greatly harmed by too large units and
> excessive fields scope.

Sure. Which is I'm all for the middle ground, but this is IMHO going into
the micromanaging bit. Unit is still local scope for me.

If the visibility in the unit is a problem, the unit is too big. Period.