what are the other ways to prevent a class from being subclassed. one way is to declare the class fi

Discussion in 'Java' started by srinivas.veeranki@gmail.com, Feb 8, 2006.

  1. Guest

    Hi All,

    what are the other ways to prevent a class from being subclassed. one
    way is to declare the class final.


    Thanks

    Srinivas
    , Feb 8, 2006
    #1
    1. Advertising

  2. NullBock Guest

    You could throw an exception in the ctor, if it's being called on a
    derived class:

    class NoExtend {
    public NoExtend() {
    if (this.getClass() != NoExtend.class) {
    throw new RuntimeException();
    }
    }
    }

    Or you could have a private ctor, with a public factory method:

    class NoExtend {
    private NoExtend() {
    }

    public static NoExtend create() {
    return new NoExtend();
    }
    }

    Those are two methods that come to mind...

    Walter

    ----
    Walter Gildersleeve
    Freiburg, Germany

    ______________________________________________________
    http://linkfrog.net
    URL Shortening
    Free and easy, small and green.
    NullBock, Feb 8, 2006
    #2
    1. Advertising

  3. Guest

    hi...

    Thanking you very much for ur help..
    Thanks..
    Srinivas
    NullBock wrote:
    > You could throw an exception in the ctor, if it's being called on a
    > derived class:
    >
    > class NoExtend {
    > public NoExtend() {
    > if (this.getClass() != NoExtend.class) {
    > throw new RuntimeException();
    > }
    > }
    > }
    >
    > Or you could have a private ctor, with a public factory method:
    >
    > class NoExtend {
    > private NoExtend() {
    > }
    >
    > public static NoExtend create() {
    > return new NoExtend();
    > }
    > }
    >
    > Those are two methods that come to mind...
    >
    > Walter
    >
    > ----
    > Walter Gildersleeve
    > Freiburg, Germany
    >
    > ______________________________________________________
    > http://linkfrog.net
    > URL Shortening
    > Free and easy, small and green.
    , Feb 8, 2006
    #3
  4. Roedy Green Guest

    On 8 Feb 2006 01:04:12 -0800, wrote,
    quoted or indirectly quoted someone who said :

    >what are the other ways to prevent a class from being subclassed. one
    >way is to declare the class final.


    Why do you want to know another method? What is the matter with
    declaring a class final?
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
    Roedy Green, Feb 8, 2006
    #4
  5. EJP Guest

    Re: what are the other ways to prevent a class from being subclassed.one way is to declare the class final.

    wrote:

    > Hi All,
    >
    > what are the other ways to prevent a class from being subclassed. one
    > way is to declare the class final.


    Declare its constructors as private.
    EJP, Feb 8, 2006
    #5
  6. Roedy Green Guest

    On Wed, 08 Feb 2006 23:41:01 GMT, EJP
    <> wrote, quoted or indirectly quoted
    someone who said :

    >> what are the other ways to prevent a class from being subclassed. one
    >> way is to declare the class final.

    >
    >Declare its constructors as private.


    Doing that and not declaring the class final is what I call
    "tantalising"
    ..
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
    Roedy Green, Feb 9, 2006
    #6
  7. Roedy Green Guest

    On Thu, 09 Feb 2006 00:06:31 GMT, Roedy Green
    <> wrote, quoted or
    indirectly quoted someone who said :

    >On Wed, 08 Feb 2006 23:41:01 GMT, EJP
    ><> wrote, quoted or indirectly quoted
    >someone who said :
    >
    >>> what are the other ways to prevent a class from being subclassed. one
    >>> way is to declare the class final.

    >>
    >>Declare its constructors as private.

    >
    >Doing that and not declaring the class final is what I call
    >"tantalising"
    >.

    see http://mindprod.com/jgloss/tantalising.html
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
    Roedy Green, Feb 9, 2006
    #7
  8. "Roedy Green" <> wrote in
    message news:...
    > On Thu, 09 Feb 2006 00:06:31 GMT, Roedy Green
    > <> wrote, quoted or
    > indirectly quoted someone who said :
    >
    >>On Wed, 08 Feb 2006 23:41:01 GMT, EJP
    >><> wrote, quoted or indirectly quoted
    >>someone who said :
    >>
    >>>> what are the other ways to prevent a class from being subclassed. one
    >>>> way is to declare the class final.
    >>>
    >>>Declare its constructors as private.

    >>
    >>Doing that and not declaring the class final is what I call
    >>"tantalising"
    >>.

    > see http://mindprod.com/jgloss/tantalising.html


    hehehe.

    Silly rabbit, tricks are for kids.

    --
    LTP

    :)
    Luc The Perverse, Feb 9, 2006
    #8
  9. EJP Guest

    Re: what are the other ways to prevent a class from being subclassed.one way is to declare the class final.

    Roedy Green wrote:
    > On Wed, 08 Feb 2006 23:41:01 GMT, EJP
    > <> wrote, quoted or indirectly quoted
    > someone who said :
    >
    >
    >>>what are the other ways to prevent a class from being subclassed. one
    >>>way is to declare the class final.

    >>
    >>Declare its constructors as private.

    >
    >
    > Doing that and not declaring the class final is what I call
    > "tantalising"


    Not as tantalising as all that. You certainly don't have to wait until
    'bebug time' to discover it as your glossary claims. The first
    compilation will tell you. More generally you might declare the ctors as
    package-private: would you describe that as 'tantalising'? inside a
    sealed package? where you do draw the line?
    EJP, Feb 9, 2006
    #9
  10. Roedy Green Guest

    On Thu, 09 Feb 2006 05:51:59 GMT, EJP
    <> wrote, quoted or indirectly quoted
    someone who said :

    >Not as tantalising as all that. You certainly don't have to wait until
    >'bebug time' to discover it as your glossary claims.



    If it is an alternate implementation, you won't find out till run
    time, or maybe never. The compile will be quite happy so long as your
    method signatures you use match.

    If it a totally unrelated class you will find out at compile time, and
    you will likely be puzzled all the heck why it does not recognise your
    methods.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
    Roedy Green, Feb 9, 2006
    #10
  11. EJP Guest

    Re: what are the other ways to prevent a class from being subclassed.one way is to declare the class final.

    Roedy Green wrote:
    > If it is an alternate implementation, you won't find out till run
    > time, or maybe never. The compile will be quite happy so long as your
    > method signatures you use match.


    You will definitely find out, because of super() being private, but
    actually we seem to be getting a fair way off the point here. A
    replacement class newly marked as 'final' will also have some
    'tantalizing' behaviour at runtime.

    > If it a totally unrelated class you will find out at compile time, and
    > you will likely be puzzled all the heck why it does not recognise your
    > methods.


    My compiler complains about not being able to call super() because it is
    private. This doesn't puzzle me. I don't know what is meant by 'not
    recognizing your methods'.

    I was really only answering the OP's question for completeness, not to
    advocate any particular style, but the use of this pattern e.g. for
    factory or singleton classes seems perfectly legitimate to me, and not
    'tantalising'.
    EJP, Feb 9, 2006
    #11
  12. Roedy Green Guest

    On Thu, 09 Feb 2006 08:36:19 GMT, EJP
    <> wrote, quoted or indirectly quoted
    someone who said :

    >You will definitely find out, because of super() being private, but
    >actually we seem to be getting a fair way off the point here. A
    >replacement class newly marked as 'final' will also have some
    >'tantalizing' behaviour at runtime.


    I am confused since we have been discussing vaguely related issues in
    different threads.

    1. if you use wildcard imports you can get he wrong class and not
    notice even at run time. All that has to happen is the signatures to
    match of the methods you actually use.

    2. if someone makes all constructors private but leaves the class
    itself public, someone researching his problem will note the class is
    not final and base a design on that. when he actually comes to do the
    work of extending the class he finds out when he compiles he is in
    trouble since the super constructor is private. He has wasted time
    designing and writing his class. That is tantalising. Shoot the
    asshole who pulled this childish stunt.



    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
    Roedy Green, Feb 9, 2006
    #12
  13. NullBock Guest

    The problems you mention are pretty far-fetched, and would be caught
    early in production, in any case. Indeed, you'd have to give me an
    example to show that problem 1) could happen without compile-time
    errors--normally you'd get a ambiguity error:

    import java.util.*;
    import javax.swing.*;

    class MyTimer extends Timer {//won't compile
    }

    As has been mentioned, non-final, non-inheritable classes are useful in
    certain design patterns, including singletons, abstract factories and
    prototypes.


    ----
    Walter Gildersleeve
    Freiburg, Germany

    ______________________________________________________
    http://linkfrog.net
    URL Shortening
    Free and easy, small and green.
    NullBock, Feb 9, 2006
    #13
  14. Roedy Green wrote:
    > On Thu, 09 Feb 2006 08:36:19 GMT, EJP
    > ...
    >
    > 2. if someone makes all constructors private but leaves the class
    > itself public, someone researching his problem will note the class is
    > not final and base a design on that. when he actually comes to do the
    > work of extending the class he finds out when he compiles he is in
    > trouble since the super constructor is private. He has wasted time
    > designing and writing his class. That is tantalising. Shoot the
    > asshole who pulled this childish stunt.
    >
    > ...


    When the constructor is declared private, it can be documented. The
    developer who does the research will definitely come across the
    documentation of the class and realize that it has a private
    constructor and thought it is non-final, it cannot be extended. So it
    is is common sense that he wud not waste his time developing a subclass
    to a class which he knows is not inheritable.
    Ranganath Kini, Feb 9, 2006
    #14
  15. Besides, nothing stops bad design. The language to its best possible
    extent prevents accidental design flaws, but intentional efforts cannot
    be stopped. So if developer decides to create a bad design, it's his
    call.

    In object oriented world, contracts rely on other contracts to do what
    they are supposed to do. There has to be a default level of trust among
    objects. In an ideal world, developers make their best effort to ensure
    that their object implementation does what the object's public contract
    declares to do in the manner that it does. But there is nothing to
    enforce this kind of nature in the language.
    Ranganath Kini, Feb 9, 2006
    #15
  16. EJP Guest

    Re: what are the other ways to prevent a class from being subclassed.one way is to declare the class final.

    Roedy Green wrote:
    > On Thu, 09 Feb 2006 08:36:19 GMT, EJP
    > I am confused since we have been discussing vaguely related issues in
    > different threads.


    Not me.

    > 1. if you use wildcard imports you can get he wrong class and not
    > notice even at run time. All that has to happen is the signatures to
    > match of the methods you actually use.


    I agree, but this applies to *any* class, whether a mis-import or an
    alternate implementation, which doesn't entirely meet the binary
    contract of the expected class.

    > 2. if someone makes all constructors private but leaves the class
    > itself public, someone researching his problem will note the class is
    > not final and base a design on that. when he actually comes to do the
    > work of extending the class he finds out when he compiles he is in
    > trouble since the super constructor is private. He has wasted time
    > designing and writing his class. That is tantalising. Shoot the
    > asshole who pulled this childish stunt.


    I disagree. He has wasted his time by not doing his homework. This
    applies to many situations, not just this one.

    In *the situation under discussion*, there may be legitimate reasons for
    making it non-final but with private constructors. The abstract factory
    pattern is an example: the concrete subclass can be provided as a static
    inner class. This seems like a useful feature to me and I may even have
    used it some time.

    Your language is not justified.
    EJP, Feb 12, 2006
    #16
  17. Roedy Green Guest

    On Sun, 12 Feb 2006 04:38:22 GMT, EJP
    <> wrote, quoted or indirectly quoted
    someone who said :

    >
    >I agree, but this applies to *any* class, whether a mis-import or an
    >alternate implementation, which doesn't entirely meet the binary
    >contract of the expected class.


    but it won't likely happen because if the class names differ because
    you explicitly mention the class name in your code. The confusion
    comes with generic wildcards that can give you an alternative class
    you did not even know about.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
    Roedy Green, Feb 12, 2006
    #17
  18. Roedy Green Guest

    On Sun, 12 Feb 2006 04:38:22 GMT, EJP
    <> wrote, quoted or indirectly quoted
    someone who said :

    >I disagree. He has wasted his time by not doing his homework. This
    >applies to many situations, not just this one.


    It is a trap for the unwary. There is no benefit in it. It is
    motivated by malicious pranksterism. So I put the blame on the person
    who set the trap, not the one who fell into in. Maintainable code
    should not have traps.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
    Roedy Green, Feb 12, 2006
    #18
  19. EJP Guest

    Re: what are the other ways to prevent a class from being subclassed.one way is to declare the class final.

    Roedy Green wrote:
    > It is a trap for the unwary. There is no benefit in it. It is
    > motivated by malicious pranksterism.


    1. It is a trap for the unwary. I agree. There are many of these in Java
    and elsewhere.

    2. The benefit has already been cited, but, to re-iterate, it provides
    finer-grained control over *who* may subclass the class. Consider this
    form of the abstract factory pattern:

    public abstract class AbstractFactory
    {
    private AbstractFactory() {}
    public abstract MyObject createMyObject();
    public static createFactory() { return new ConcreteFactory(); }

    static class ConcreteFactory extends AbstractFactory
    {
    public Object createMyObject() { return new MyObject(); }
    }
    }

    You might describe the ability to write that as a marginal or dubious
    benefit, but it is certainly not 'no benefit'. Consider also the case
    where the constructors in question are protected or package-private.

    3. You can ignore evidence all you want, but when you are reduced to
    speculating on motives (whose?) you are getting pretty ridiculous.
    EJP, Feb 13, 2006
    #19
  20. Roedy Green Guest

    On Mon, 13 Feb 2006 02:25:38 GMT, EJP
    <> wrote, quoted or indirectly quoted
    someone who said :

    >2. The benefit has already been cited, but, to re-iterate, it provides
    >finer-grained control over *who* may subclass the class. Consider this
    >form of the abstract factory pattern:
    >
    >public abstract class AbstractFactory
    >{
    > private AbstractFactory() {}
    > public abstract MyObject createMyObject();
    > public static createFactory() { return new ConcreteFactory(); }
    >
    > static class ConcreteFactory extends AbstractFactory
    > {
    > public Object createMyObject() { return new MyObject(); }
    > }
    >}


    I don't understand your benefit. With this convolution what the net
    result Who do you include/exclude doing it both ways.

    Even if that were true it is too weird and convoluted. Don't do it.


    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
    Roedy Green, Feb 13, 2006
    #20
    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. -
    Replies:
    3
    Views:
    453
    Thomas Fritsch
    Jul 24, 2005
  2. Oliver Wong
    Replies:
    16
    Views:
    596
    Oliver Wong
    Jun 28, 2006
  3. Sun
    Replies:
    27
    Views:
    732
    Steven D'Aprano
    Feb 16, 2008
  4. Merciadri Luca
    Replies:
    4
    Views:
    799
  5. Sergey Ilinsky
    Replies:
    2
    Views:
    104
    Michael Winter
    Mar 28, 2005
Loading...

Share This Page