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 ―

      IMO 'SUBCLASSING' implies developers extending the library rather than people simply using it, but I'll admit that's an interpretation...

      M-x auto-bs-mode

      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?

        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 ―