Re^3: Documenting non-public OO components

in reply to Re^2: Documenting non-public OO components
in thread Documenting non-public OO components

In Java speek 'private' means only the class that declaired it can use it, 'public' means any one of any class can use it. Java also has the notion of 'protected' and 'package', basicly any subclass has access and any class in the same package has access respectivly.

The "SUBCLASSING" section would declair 'protected' (by convention only) methods. So it would not truely be 'public' in the sense of any class may call them, but it could be seen as 'public' in the sense that you have published their specs for all to see.

Comment on Re^3: Documenting non-public OO components

Replies are listed 'Best First'.
Re^4: Documenting non-public OO components by creamygoodness (Curate) on Sep 06, 2005 at 19:08 UTC
My main concern is to indicate which parts of the libary non-developers may depend upon and which parts they must avoid using. I suppose it is true that any protected or even package components may be accessed if you hack your class just right in Java, but the presence of a protected method in a class which is not explicity intended to be subclassed would not lead me to believe that it was OK to subclass it. The problem that I have with a "SUBCLASSING" heading is that, if it's present it seems to indicate that the library allows users, not just developers, to subclass that class. That wouldn't always be the case. -- Marvin Humphrey Rectangular Research ― http://www.rectangular.com	[reply]
Re^5: Documenting non-public OO components by lachoy (Parson) on Sep 06, 2005 at 19:43 UTC
IMO 'SUBCLASSING' implies developers extending the library rather than people simply using it, but I'll admit that's an interpretation... Chris M-x auto-bs-mode	[reply]
Re^5: Documenting non-public OO components by revdiablo (Prior) on Sep 07, 2005 at 15:49 UTC
the library allows users, not just developers, to subclass that class. That wouldn't always be the case. Wouldn't it? The view I take is that any time you have subclassed, you automatically become a developer. Is there any other reason to subclass than to extend or further develop a class?	[reply]
Re^6: Documenting non-public OO components by creamygoodness (Curate) on Sep 08, 2005 at 00:17 UTC
If you subclass a class I don't want people outside the core development team to subclass, I'm not going to support you and I might just switch up the API on you without warning and break your app. I'd rather you didn't shoot yourself in the head, but I don't think it matters whether you label yourself a "user", a "developer", or a "devil's advocate" if you do. Now, if I put up a big "SUBCLASSING" heading then switched the API on you, I think you'd have a reasonable beef with me, since that can easily be interpreted as granting permission to subclass. So I'm only going to put up that heading when it's actually OK for anyone and their dog to subclass. But there are other ocassions where the development team may want to have a few classes which inherit. It's silly to abridge the documentation of the inheritance hierarchy just because you can't figure out a way to convey to users/non-core-developers/devil's-advocates that they shouldn't subclass while still documenting the way the class es work. The answer is, label it "PROTECTED API" or something similar. On large systems, the interface design is harder, more important, and more expensive than the low-level code... -- Marvin Humphrey Rectangular Research ― http://www.rectangular.com	[reply]

In Section Meditations