A simple question for Abstract Class

Discussion in 'Java' started by Leo Smith, May 26, 2006.

  1. Leo Smith

    Leo Smith Guest

    Dear All,

    I am confused about Abstract Class. I know Abstrac Class is a class
    contains > 1 abstract methods. I know Abstract Class can only be used as
    a base class and cannot have instances of it.

    What I am not clear is: if A is the abstract class, which has two
    abstract methods.
    public abstract class A
    {

    public abstract void method_1();

    public abstract void method_2();

    }

    public class B extends A
    {
    public void method_1() {
    //implementation
    }
    //but not implementing method_2()
    }

    Is B an abstract class? Can B has objects of its own? My foggy impresion
    is that B can have objects of its own. B is not an abstract class either.

    Am I correct? Thank you.
     
    Leo Smith, May 26, 2006
    #1
    1. Advertising

  2. Leo Smith wrote:
    >
    > I am confused about Abstract Class. I know Abstrac Class is a class
    > contains > 1 abstract methods. I know Abstract Class can only be used as
    > a base class and cannot have instances of it.


    Since 1.1 abstract classes have not needed any abstract methods. Take
    for instance, java.awt.event.MouseAdapter. This differs from C++, where
    an abstract class is one with at least one pure virtual method (often
    the destructor, which should also have an implementation).

    > public abstract class A
    > {
    >
    > public abstract void method_1();
    >
    > public abstract void method_2();
    >
    > }
    >
    > public class B extends A
    > {
    > public void method_1() {
    > //implementation
    > }
    > //but not implementing method_2()
    > }
    >
    > Is B an abstract class? Can B has objects of its own? My foggy impresion
    > is that B can have objects of its own. B is not an abstract class either.


    You will need to declare B abstract.

    However, if you compile both classes with A not having method_2, and
    then recompile A only with both abstract methods, then you'll get a
    mess. It will load okay, but you'll get an AbstractMethodError if you
    try to call method_2 on a B. The only place you are likely to see this
    deliberately done is in java.sql, which regularly adds methods to
    interfaces.

    Tom Hawtin
    --
    Unemployed English Java programmer
    http://jroller.com/page/tackline/
     
    Thomas Hawtin, May 26, 2006
    #2
    1. Advertising

  3. Leo Smith

    Mariano2012 Guest

    B is a abstract class, In this way a object of class B can't be
    created. You must implements all abstract methods or extend class B.

    public abstract class A {
    public abstract void methodA1();
    public abstract void methodA2();
    }//EndClass

    public abstract class B extends A{
    public abstract void methodB();
    }//EndClass

    // Class A and Class B can't be created
    // because are abstract classes
    public class C extends B {
    public void methodA1(){}
    public void methodA2(){}
    public void methodB(){}
    }//EndClass

    Regards,
    Mariano
     
    Mariano2012, May 26, 2006
    #3
  4. Leo Smith

    Leo Smith Guest

    I am not sure you two above are correct. If you two are correct, how to
    understand the following:

    Just see the top part explanation
    http://java.sun.com/j2se/1.5.0/docs...html#windowClosing(java.awt.event.WindowEvent)

    For example, WindowAdapter is an abstract class, which implements
    several interfaces(WindowListener, WindowFocusListener,
    WindowStateListener, EventListener). Needless to say, WindowAdapter has
    a lot of methods ("abstract methods") in it.

    If I have a sub-class of WindowAdapter, I can just redefine the methods
    I care, no need to worry about other methods. (I don't even know how
    many methods and their names in WindowAdapter.)
     
    Leo Smith, May 26, 2006
    #4
  5. Leo Smith

    chris brat Guest

    If any class extends any abstract class it must also be defined as an
    abstract class - this is enforced by the compiler.

    The classes in the WindowAdapter class are not abstract - the class
    itself is.
    You cannot instantiate an instance of the WindowAdapter class as is -
    you would need to do the following :



    public abstract class DummyClass {

    public DummyClass(){
    System.out.println("Dummy class output");
    }

    public void method1(){
    // not abstract but does nothing
    }

    public void method2(){
    // not abstract but does nothing
    }


    public static void main(String[] args) {
    new DummyClass(){
    // override any methods here
    // could override method1() or method2() to give them
    // logic but since they aren't abstract it isn't
    necessary
    };
    }
    }


    You should get the following output (unless I mistyped) :

    Dummy class output
     
    chris brat, May 26, 2006
    #5
  6. Leo Smith

    Chris Uppal Guest

    Leo Smith wrote:

    > For example, WindowAdapter is an abstract class, which implements
    > several interfaces(WindowListener, WindowFocusListener,
    > WindowStateListener, EventListener). Needless to say, WindowAdapter has
    > a lot of methods ("abstract methods") in it.


    WindowAdapter is an abstract class, that's true. (Though /why/ it's abstract
    puzzles me -- I think it's a design error). But none of the methods defined in
    WindowAdapter are abstract, they are all real, concrete methods, with proper
    bodies. None of the methods /do/ anything, but that doesn't make them
    abstract.

    -- chris
     
    Chris Uppal, May 26, 2006
    #6
  7. Leo Smith

    Roedy Green Guest

    On Fri, 26 May 2006 11:46:58 -0400, Leo Smith <> wrote,
    quoted or indirectly quoted someone who said :

    >I know Abstrac Class is a class
    >contains > 1 abstract methods.


    Not necessarily. Oddly you can declare a class abstract even though
    all its method bodies are defined. The idea is you have to extend the
    class to use it.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
     
    Roedy Green, May 26, 2006
    #7
  8. Leo Smith

    Roedy Green Guest

    On Fri, 26 May 2006 11:46:58 -0400, Leo Smith <> wrote,
    quoted or indirectly quoted someone who said :

    >public class B extends A
    >{
    > public void method_1() {
    > //implementation
    > }
    > //but not implementing method_2()
    >}
    >
    >Is B an abstract class? Can B has objects of its own? My foggy impresion
    >is that B can have objects of its own. B is not an abstract class either.


    If you implement all the abstract methods of the base class, and don't
    declare the new class abstract then it is not abstract. The new class
    can also have its own fields and methods.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
     
    Roedy Green, May 26, 2006
    #8
  9. Leo Smith

    chris brat Guest

    As far as I know it is for easier coding of window events - you only
    override the methods to be processed by your window in an anonymous
    class.

    Don't think it was a design error but it is still clunky.
     
    chris brat, May 26, 2006
    #9
  10. Leo Smith

    chris brat Guest

    sorry, the first sentence doesn't makes sense. It should be

    "If any class extends any abstract class and does not implement all the
    methods (those defined as abstract or defined by implemented interfaces
    ) it must also be defined as an
    abstract class - this is enforced by the compiler."
     
    chris brat, May 26, 2006
    #10
  11. Leo Smith

    Chris Uppal Guest

    chris brat wrote:

    > As far as I know it is for easier coding of window events - you only
    > override the methods to be processed by your window in an anonymous
    > class.
    >
    > Don't think it was a design error but it is still clunky.


    No, I meant: why is the class declared /abstract/ ? I know what the class
    itself is for, and it's a pretty good idea, given the architecture it's part
    of. But there is no good reason to declare it abstract. Instances would work
    /exactly/ as well for all its current applications if it were a concrete class.
    /And/ it could be used as a "null" implementation as well (which is
    occasionally useful, for testing, and suchlike).

    Presumably someone at Sun had a design twitch and confused: "I, having thought
    about the matter for about three seconds (but not with any great care), do not
    immediately see a reason to use this class without subclassing it", with the
    rather different: "it could never be anything other than an error for someone
    to use this class without subclassing it".

    -- chris
     
    Chris Uppal, May 26, 2006
    #11
  12. Leo Smith

    Juha Laiho Guest

    "Chris Uppal" <-THIS.org> said:
    >chris brat wrote:
    >> As far as I know it is for easier coding of window events - you only
    >> override the methods to be processed by your window in an anonymous
    >> class.

    >
    >No, I meant: why is the class declared /abstract/ ?

    ....
    >Presumably someone at Sun had a design twitch and confused: "I, having
    >thought about the matter for about three seconds (but not with any
    >great care), do not immediately see a reason to use this class without
    >subclassing it", with the rather different: "it could never be anything
    >other than an error for someone to use this class without subclassing it".


    Chris;

    I'd consider declaring this kinds of classes abstract is a kind of safety
    belt. This forces the programmer to make a conscious decision about methods
    needed for the current case.

    As for your need for the nullobject variant of this, you could have that
    just by extending the class and not overriding any of the methods - but
    even in that case, it'll be a conscious decision.

    Whether this "safety belts" -design is good or not is a different matter;
    I won't comment on that. But I guess this is the rationale.
    --
    Wolf a.k.a. Juha Laiho Espoo, Finland
    (GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
    PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
    "...cancel my subscription to the resurrection!" (Jim Morrison)
     
    Juha Laiho, May 26, 2006
    #12
  13. Juha Laiho wrote:
    > "Chris Uppal" <-THIS.org> said:
    >> chris brat wrote:
    >>> As far as I know it is for easier coding of window events - you only
    >>> override the methods to be processed by your window in an anonymous
    >>> class.

    >> No, I meant: why is the class declared /abstract/ ?

    > ...
    >> Presumably someone at Sun had a design twitch and confused: "I, having
    >> thought about the matter for about three seconds (but not with any
    >> great care), do not immediately see a reason to use this class without
    >> subclassing it", with the rather different: "it could never be anything
    >> other than an error for someone to use this class without subclassing it".

    >
    > Chris;
    >
    > I'd consider declaring this kinds of classes abstract is a kind of safety
    > belt. This forces the programmer to make a conscious decision about methods
    > needed for the current case.
    >
    > As for your need for the nullobject variant of this, you could have that
    > just by extending the class and not overriding any of the methods - but
    > even in that case, it'll be a conscious decision.


    Yep.

    frame.addWindowListener( new WindowAdapter() {} );

    Only its not to clear that we have created an anonymous inner class, its
    easy to miss the '{}'.

    However,....
    >
    > Whether this "safety belts" -design is good or not is a different matter;
    > I won't comment on that. But I guess this is the rationale.


    whilst i agree in principle, I think the confusion stems from the
    classes name - WindowAdapter.

    If it was called AbstractWindowAdapter, then as a developer I'd see it
    as a design choice that the API provider expects us to derive from it in
    order to fulfill a desired approach.

    Likewise with the NullObject pattern, If there was a derived (final)
    class called WindowAdapterNullObject (or something) then its clear that
    it has a single purpose. In fact we could have had the
    WindowAdapterNullObject class derive from the AbstractWindowAdapter
    class as part of the JDK.
     
    Andrew McDonagh, May 26, 2006
    #13
  14. Leo Smith

    Dale King Guest

    Chris Uppal wrote:
    > chris brat wrote:
    >
    >> As far as I know it is for easier coding of window events - you only
    >> override the methods to be processed by your window in an anonymous
    >> class.
    >>
    >> Don't think it was a design error but it is still clunky.

    >
    > No, I meant: why is the class declared /abstract/ ? I know what the class
    > itself is for, and it's a pretty good idea, given the architecture it's part
    > of. But there is no good reason to declare it abstract. Instances would work
    > /exactly/ as well for all its current applications if it were a concrete class.
    > /And/ it could be used as a "null" implementation as well (which is
    > occasionally useful, for testing, and suchlike).
    >
    > Presumably someone at Sun had a design twitch and confused: "I, having thought
    > about the matter for about three seconds (but not with any great care), do not
    > immediately see a reason to use this class without subclassing it", with the
    > rather different: "it could never be anything other than an error for someone
    > to use this class without subclassing it".


    I can't really come up with a very likely scenario where you would
    really need an implementation of WindowAdapter that did nothing. If you
    don't need the window events then don't register a listener for them.
    The closest I can come up with is a state pattern where you have a
    window listener that forwards on events to a different listener
    depending on state and in one of those states you are to ignore the events.

    You are right that there was no *need* for it to be abstract. But one
    could make a case for saying it was a way to send a message to someone
    that didn't quite know what they were doing that they are probably doing
    something wrong by instantiating this class.

    So it would be difficult to make a case for saying that it harms anyone
    by making it abstract and one could make a case for it being helpful to
    make it abstract.

    --
    Dale King
     
    Dale King, May 27, 2006
    #14
  15. Leo Smith

    Guest

    I don't understand you, but I can eplain you this concepts.

    - An Abstract class is a class that can't be instanced. An Abstract
    class can have 0 or more abstract methods. if you have an abstract
    class A which has abstract methods and a class B which extends A, you
    would have to implements all this methods.

    "An abstract method on super class force you to implement this on child
    classes."

    In your case

    public class B extends A
    {
    public void method_1() {
    //implementation
    }
    //but not implementing method_2()
    }

    you will have to implement method_1() and method_2(), and you could
    create instances of B class because B is a concrete class.
     
    , May 27, 2006
    #15
  16. Leo Smith

    Chris Uppal Guest

    Juha Laiho wrote:

    [me:]
    > > Presumably someone at Sun had a design twitch and confused: "I, having
    > > thought about the matter for about three seconds (but not with any
    > > great care), do not immediately see a reason to use this class without
    > > subclassing it", with the rather different: "it could never be anything
    > > other than an error for someone to use this class without subclassing
    > > it".

    >
    > I'd consider declaring this kinds of classes abstract is a kind of safety
    > belt.


    IMO, the "abstract" doesn't add any safety, it just reduces functionality. (I
    do understand your point, I just don't really agree with it.)


    > Whether this "safety belts" -design is good or not is a different matter;
    > I won't comment on that. But I guess this is the rationale.


    Another possible reason is that the programmer was blindly applying a "rule" of
    good design -- don't subclass from concrete classes. Rules are all very well
    if they are applied with discretion, but some programmers forget that following
    rules is not a substitute for thinking.

    BTW, I don't think the class is at all well named. It isn't a kind of
    adapter at all (though subclasses /may/ be). It is either conceived as an
    abstract framework for creating Listener implementations, in which case it
    might be called AbstractWindowListener; or it could be viewed as the root, or
    default, implementation of a Listener, in which case NullWindowListener or
    BasicWindowListener would be reasonable names.

    -- chris
     
    Chris Uppal, May 30, 2006
    #16
  17. "Chris Uppal" <-THIS.org> wrote in message
    news:447c159c$1$778$...
    >> I'd consider declaring this kinds of classes abstract is a kind of safety
    >> belt.

    >
    > IMO, the "abstract" doesn't add any safety, it just reduces functionality.
    > (I
    > do understand your point, I just don't really agree with it.)


    Hmm - for a novice programmer who doesn't know what he/she is doing,
    something like a carefully placed assert or abstract class to prevent them
    from doing something wrong can be very helpful. I have never encountered a
    problem like this in Java, but in MSVC++.

    --
    LTP

    :)
     
    Luc The Perverse, May 30, 2006
    #17
  18. Leo Smith

    Chris Uppal Guest

    Luc The Perverse wrote:

    [me:]
    > > IMO, the "abstract" doesn't add any safety, it just reduces
    > > functionality.[...]

    >
    > Hmm - for a novice programmer who doesn't know what he/she is doing,
    > something like a carefully placed assert or abstract class to prevent them
    > from doing something wrong can be very helpful.


    I agree that safety is a worthwhile goal, I even agree -- with strong
    reservations -- that safety is still a worthwhile goal even when the only
    direct beneficiaries are people who don't fully understand the language.

    What I /don't/ agree with is that declaring WindowAdapter abstract adds any
    safety at all.

    -- chris
     
    Chris Uppal, May 31, 2006
    #18
  19. Leo Smith

    Dale King Guest

    Chris Uppal wrote:
    > Luc The Perverse wrote:
    >
    > [me:]
    >>> IMO, the "abstract" doesn't add any safety, it just reduces
    >>> functionality.[...]

    >> Hmm - for a novice programmer who doesn't know what he/she is doing,
    >> something like a carefully placed assert or abstract class to prevent them
    >> from doing something wrong can be very helpful.

    >
    > I agree that safety is a worthwhile goal, I even agree -- with strong
    > reservations -- that safety is still a worthwhile goal even when the only
    > direct beneficiaries are people who don't fully understand the language.
    >
    > What I /don't/ agree with is that declaring WindowAdapter abstract adds any
    > safety at all.


    I think safety is probably a bad word to describe it, but there is some
    benefit to a newbie to tell keep them from instantiating a WindowAdapter.

    On the flip side, I don't think there is any benefit to not declaring
    WindowAdapter abstract. You claim it reduces functionality, but there
    really isn't a plausible use for an instance of WindowAdapter.

    --
    Dale King
     
    Dale King, May 31, 2006
    #19
  20. Leo Smith

    Chris Uppal Guest

    Dale King" <"DaleWKing [at]gmail [dot] com wrote:

    > I think safety is probably a bad word to describe it, but there is some
    > benefit to a newbie to tell keep them from instantiating a WindowAdapter.


    "Safety" wasn't the best choice of word, I agree.


    > [...] You claim it reduces functionality, but there
    > really isn't a plausible use for an instance of WindowAdapter.


    Sure there is. Once you've got working Null objects (or deaf objects) then
    uses crop up all over the place. E.g. dummying stuff out during development,
    debugging, and testing (these form the main uses, IMO). As a default for
    configurable/pluggable architectures. As "safe" placeholders to replace the
    normal listener during updates which could generate unwanted notification. As a
    way to avoid ugly if (xxx != null) tests all over the place. And so on...

    Null objects are useful. The person at Sun writing this class apparently
    forgot that.

    -- chris
     
    Chris Uppal, May 31, 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. Matthias Kaeppler
    Replies:
    1
    Views:
    443
    R.F. Pels
    May 22, 2005
  2. Sameer
    Replies:
    4
    Views:
    605
    Roedy Green
    Aug 31, 2005
  3. Uzytkownik
    Replies:
    3
    Views:
    595
    Uzytkownik
    Apr 3, 2005
  4. Iyer, Prasad C

    Abstract Methods & Abstract Class

    Iyer, Prasad C, Oct 20, 2005, in forum: Python
    Replies:
    0
    Views:
    535
    Iyer, Prasad C
    Oct 20, 2005
  5. Replies:
    4
    Views:
    824
    Rolf Magnus
    May 17, 2006
Loading...

Share This Page