On 30/08/2006, at 5:57 PM, Marcin Lukasiak wrote:

Private API are for framework/library/application implementator use - you should even know that there is any method names X when it's private. Private
API's are private because implementators want to have some internal
structure that they will be able to easily change and usually private API changes a lot. Normally I'd like to have some parts private to do not think
each time I change internals (because of optimization or whatever) if
someone don't relay on this.

That is a very good point, and is the brittle subclass problem. The project management way to get around it is to have a process marking classes as new, experimental, tested, mature, etc.

The next level is to be wise in your use of inheritance, you are quite correct, it only suits some problems and misuse will soon lead to problems, especially the brittle subclass problem.

The technical solution is design by contract, so that it will much more quickly become obvious that a subclass cannot honour the contracts of the parent class and so therefore inheritance is inappropriate. I find this a stronger and yet more flexible approach than Java's final and private, ensuring correct application of inheritance, without blanket ban.

Ian

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to archive@mail-archive.com

Reply via email to