From: Charles O Nutter <headius@...>
Date: 2006-06-01T08:44:23+09:00
Subject: Re: OO / Private verse Protected

------=_Part_21913_4770268.1149119060384
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I believe the purpose of privatising methods is to avoid exposing internal
implementation details that may change in future revisions of the code. You
don't want people depending on methods you created internally to support
your public API, especially since those methods may be tied to
implementation details that should not be exposed.

Also, protected methods are not public..they are simply callable or
extensible within that branch of a class hierarchy. When a class extends
your base, it implicitly accepts responsibility for fulfilling the contract
of your public API. If it chooses to use your protected methods, or even
expose them, it may do so at its own peril. Your base implementation could
change in the future rendering that class nonfunctional and in violation of
the base class's explicit contract. However, protected methods have the
option of being overridden; the extending class can (and often should)
provide its own internalized version of a protected method and have the
parent's methods then behave according to that new implementation.

The reason for protected versus private is this:

- protected methods define behavior that could logically differ between
classes in a hierarchy, but should generally not be exposed for direct calls
to clients of the classes in that hierarchy. These are class-specific
methods that alter behavior between parent and child, allowing child classes
to literally "extend" the behavior of the parent by providing a new
implementation without altering the public API.
- private methods are dependent enough on your specific implementation or
localizable enough to a single level in the class hierarchy that they should
not be exposed or overridden in any way. The behavior of a class or its
public API may be wholely dependent on that one implementation of an
algorithm, and child classes should not be allowed to replace it. By the
same token, that algorithm may have to change or go away in the future, and
clients of the class or its subclasses should not call it directly.

On 5/31/06, Joost Diepenmaat <joost@zeekat.nl> wrote:
>
> On Thu, Jun 01, 2006 at 06:36:11AM +0900, Alexandru Popescu wrote:
> > >My argument was that you then have to disallow people from implementing
> > >their own classes based on your classes, because if they do, they still
> > >can call the protected methods you just worked so hard to "protect".
> > >
> >
> > But I haven't worked on protecting them against overridding, but
> > against direct calls. Big difference.
>
> Ofcourse.
>
> > >My main point though, is that if you think you need protected methods
> you
> > >should think really hard about wether other classes might find those
> > >methods useful too (i.e. just make them public instead).
> > >
> >
> > This is a matter of the API designer skills. However making everything
> > public, for the sake that somebody may find one of the methods usefull
> > is imo worse than having to evolve your initial API.
>
> That's not what I meant. You can still make methods private. But if
> methods
> are useful enough to make protected / need to be accessible from
> subclasses
> or other instances, you should really stop and think if you _have_ to deny
> access from the rest of the code. If your classes are only going to be
> used
> in one project, knock yourself out - you can always change it later. But
> if
> you are writing reusable components... well, I think I've made my point
> :-)
>
> > >I've ran into too many problems with libraries where you just can't
> call
> > >very handy methods because the designer decided you shouldn't and then
> it
> > >takes hours to work around that. My gut feeling is that protected
> methods
> > >are usually either badly designed, or made so the designer can feel
> good
> > >about not binding the API to the implementation. If your implementation
> is
> > >so bad you don't want _other_ people relying on it, but _you_ still
> need
> > >access to it to make your code work, you're doing something wrong.
> > >
> >
> > It's sad to hear this, but unfortunately I would say that it was your
> > bad luck to work with bad designed APIs. Agreed, some projects get it
> > right from the 1st version, other are learning how to do it.
>
> True enough.
>
> Cheers,
> Joost.
>
>
>


-- 
Charles Oliver Nutter @ headius.blogspot.com
JRuby Developer @ jruby.sourceforge.net
Application Architect @ www.ventera.com

------=_Part_21913_4770268.1149119060384--