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.