When to Use protected

Discussion in 'Java' started by Mike, Jul 6, 2006.

  1. Mike

    Mike Guest

    Hi,
    im relative new to Java and im wondering : what are the rules of using
    private vs protected vs public methods.
    Are there anyone who has had bad experiences with using the protected
    modifier ?
     
    Mike, Jul 6, 2006
    #1
    1. Advertising

  2. Mike wrote:
    > Hi,
    > im relative new to Java and im wondering : what are the rules of using
    > private vs protected vs public methods.
    > Are there anyone who has had bad experiences with using the protected
    > modifier ?


    Not much. even it is not as bad as me. :)

    There are no rules to use accessors. You need a reason for using them.

    protected has its significance in inheritance.

    see Table of Member Access Privileges in any good book to get better
    understanding.

    -- Murali Krishna
     
    Murali Krishna, Jul 6, 2006
    #2
    1. Advertising

  3. Mike

    Moiristo Guest

    Murali Krishna wrote:
    > Mike wrote:
    >> Hi,
    >> im relative new to Java and im wondering : what are the rules of using
    >> private vs protected vs public methods.
    >> Are there anyone who has had bad experiences with using the protected
    >> modifier ?

    >
    > Not much. even it is not as bad as me. :)
    >
    > There are no rules to use accessors. You need a reason for using them.
    >
    > protected has its significance in inheritance.
    >
    > see Table of Member Access Privileges in any good book to get better
    > understanding.


    Usually, it is best to restrict methods as much as possible. So, when a
    method is used only within the class itself, use private. When you have
    cooperating classes within a single package, use protected. Otherwise,
    use public.
     
    Moiristo, Jul 6, 2006
    #3
  4. Mike

    Oliver Wong Guest

    "Moiristo" <> wrote in message
    news:e8j4hg$hpf$...
    > Murali Krishna wrote:
    >> Mike wrote:
    >>> Hi,
    >>> im relative new to Java and im wondering : what are the rules of using
    >>> private vs protected vs public methods.
    >>> Are there anyone who has had bad experiences with using the protected
    >>> modifier ?

    >>
    >> Not much. even it is not as bad as me. :)
    >>
    >> There are no rules to use accessors. You need a reason for using them.
    >>
    >> protected has its significance in inheritance.
    >>
    >> see Table of Member Access Privileges in any good book to get better
    >> understanding.

    >
    > Usually, it is best to restrict methods as much as possible. So, when a
    > method is used only within the class itself, use private. When you have
    > cooperating classes within a single package, use protected. Otherwise, use
    > public.


    If it's cooperating classes within a single package, default might be
    better than protected. Protected additionally allows subclass access (even
    if the subclass is outside of the package).

    That being said, I use default much less frequently than protected. I
    typically don't have classes within a package interact in some special,
    secret way, but I do have parent-child classes interact in a special way
    sometimes.

    - Oliver
     
    Oliver Wong, Jul 6, 2006
    #4
  5. Mike

    Ed Kirwan Guest

    Oliver Wong wrote:
    >
    >
    > If it's cooperating classes within a single package, default might be
    > better than protected. Protected additionally allows subclass access
    > (even if the subclass is outside of the package).
    >
    > That being said, I use default much less frequently than protected. I
    > typically don't have classes within a package interact in some special,
    > secret way, but I do have parent-child classes interact in a special way
    > sometimes.
    >
    > - Oliver


    Interesting. I almost never use protected; if classes are so closely
    related that they inherent from one another, I usually find they belong
    in the same package. Usually, not always. I often find some mildly ...
    distasteful about inter-package inheritance; I tend to use interfaces
    for such business, though I've no great rationale to back it up. Must
    have been some grit that got into my shell when I was starting out, and
    now I don't want to dump the pearl.

    --
    www.EdmundKirwan.com - Home of The Fractal Class Composition.

    Download Fractality, free Java code analyzer:
    www.EdmundKirwan.com/servlet/fractal/frac-page130.html
     
    Ed Kirwan, Jul 7, 2006
    #5
  6. Mike

    ddimitrov Guest

    DISCLAIMER: I'm not an authority on API design and I don't think there
    are one-size-fits-all guidelines. I'm posting what works for me on my
    current project.

    IMHO each of the modifiers has it's place:

    - when I create a class or interface, make it package-private unless it
    is part of the package interface.

    - when I want to expose a class outside a package, make it final,
    unless it's designed for extension.

    - avoid having classes designed for extension as it's too much effort
    to design and document them.

    So, at this point our class falls inside 3 categories - public class,
    public final cllass, and package-private class.

    - You *never* use protected in final classes.

    - In package-private classes, protected is the same as package-private
    access, still it's a matter of style - protected communicates better
    that certain member is intended to be accessed from classes in the same
    hirarchy. On the flip-side, there are no compiler checks to support
    this, so I don't do it usually.

    - The public non-final classes have to be specially designed for
    extension, which also means that you cannot make any assumptions about
    the caller. I find the checkstyle rule s good enough [1]. Also the XOM
    project has very good API design guidelines [2].

    - Protected non-final (PNF) methods imply that a method is intended to
    be overriden and probably used by the base class (hook method). I'd say
    avoid having non-empty or non-abstract PNF methods, as it complicates
    the understanding - prime example is the Eclipse API. It's a good API,
    but from reading other's people source, I figured that many programmers
    repeat in their own method what was already done in the super-method.
    Without detailed documentations on the pre/post conditions you are
    bound to end with this. OTOH, if you do document the pre/post
    conditions, this restricts the class evolution.

    - Protected final - the method is utility method, intended to be called
    by subclasses. Prime example are the JUnit assertions. Such methods
    should have good descriptive names and reasonably good documentation.
    In many cases you can go without them.

    [1]
    http://checkstyle.sourceforge.net/config_design.html#DesignForExtension
    [2] http://www.xom.nu/designprinciples.xhtml#d0e211
     
    ddimitrov, Jul 8, 2006
    #6
  7. Mike

    Ed Guest

    ddimitrov skrev:

    > DISCLAIMER: I'm not an authority on API design and I don't think there


    > Also the XOM
    > project has very good API design guidelines [2].



    You gotta like that chap's style: "However, in all cases, I am the
    final arbiter.
    If I don't think something's a good idea, then it isn't going
    in, no matter
    how many people are crying out for it.
    XOM is a more-or-less benevolent dictatorship,
    not a democracy. I am the only committer.
    This is my API, and it reflects my thoughts and desires."

    I can't say I agree with his preference for concrete class over
    interfaces, but it's refreshing to see someone argue his case so well.

    --

    www.EdmundKirwan.com - Home of The Fractal Class Composition
     
    Ed, Jul 8, 2006
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Andreas Klemt
    Replies:
    2
    Views:
    586
    Andreas Klemt
    Jul 5, 2003
  2. Brian Lowe
    Replies:
    4
    Views:
    3,088
    Karl Seguin
    Apr 19, 2005
  3. Jace/TBL
    Replies:
    16
    Views:
    634
    Arijit
    Nov 2, 2004
  4. Suresh Reddi
    Replies:
    2
    Views:
    326
    Suresh
    May 24, 2006
  5. Be_Reasonable

    Should I use Protected Configuration?

    Be_Reasonable, Jun 21, 2006, in forum: ASP .Net
    Replies:
    4
    Views:
    379
    Be_Reasonable
    Jun 22, 2006
Loading...

Share This Page