A simple question for Abstract Class

[Leo Smith]

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.

 

[Thomas Hawtin]

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

 

[Mariano2012]

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

 

[Leo Smith]

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...tml#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.)

 

[chris brat]

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 Uppal]

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

 

[Roedy Green]

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.

 

[Roedy Green]

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.

 

[chris brat]

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]

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 Uppal]

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

 

[Juha Laiho]

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.

 

[Andrew McDonagh]

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.

 

[Dale King]

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.

 

[yeraycaballero]

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.

 

[Chris Uppal]

Juha Laiho wrote:

[me:]

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

 

[Luc The Perverse]

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++.

 

[Chris Uppal]

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

 

[Dale King]

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.

 

[Chris Uppal]

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