"Stylistically" abstract classes?

[Joona I Palaste]

I'm wondering about whether "stylistically" abstract classes are needed.
"Stylistically" abstract classes are classes which are declared as
abstract without including any abstract methods. Is there real need for
them? And what would be a more proper term for them?

--
/-- Joona Palaste ([email protected]) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"The obvious mathematical breakthrough would be development of an easy way to
factor large prime numbers."
- Bill Gates

 

[Thomas Weidenfeller]

I'm wondering about whether "stylistically" abstract classes are needed.
"Stylistically" abstract classes are classes which are declared as
abstract without including any abstract methods. Is there real need for
them?

Need? Well, that's the old discussion about language features. You
don't need it to be turing-complete, so in that sense it is not
essential. However, you "need" it if you want to capture common parts
of distinct types, so you can provide a polymorphic unified interface
to a group of related types.

And what would be a more proper term for them?

Interfaces And in Java you have this nice "interface" keyword for
this

In C++ you call such a class a pure abstract class, because you enforce
this behavior by using a pure virtual function in the class (one pure
virtual function in a C++ class, and you can't instantiate it).

I have seen the term deferred class, too.

/Thomas

 

[Joona I Palaste]

Need? Well, that's the old discussion about language features. You
don't need it to be turing-complete, so in that sense it is not
essential. However, you "need" it if you want to capture common parts
of distinct types, so you can provide a polymorphic unified interface
to a group of related types.

Interfaces And in Java you have this nice "interface" keyword for
this

No, these are different from interfaces. Interfaces can't implement
anything. The classes I'm after implement methods, but still aren't
directly instantiable.

An example of such a class:

public abstract class StylisticallyAbstract {
public void greet() {
System.out.println("Hello world!");
}
}

--
/-- Joona Palaste ([email protected]) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"Make money fast! Don't feed it!"
- Anon

 

[Jon Skeet]

Interfaces And in Java you have this nice "interface" keyword for
this

Nope - because abstract classes can have method implementations, and
interfaces can't.

 

[Jon Skeet]

I'm wondering about whether "stylistically" abstract classes are needed.
"Stylistically" abstract classes are classes which are declared as
abstract without including any abstract methods. Is there real need for
them? And what would be a more proper term for them?

They're useful because you can then give a loud-and-clear signal that
on their own they're useless, but that they're designed to be
subclassed.

The AWT adapter classes are good examples - except they haven't been
made abstract. It would make sense for them to be abstract because
there's no point in having a straight KeyAdapter, for instance - but
there are no abstract methods because the point is to be able to only
override *some* of the methods.

 

[Darryl L. Pierce]

Thomas Weidenfeller wrote:

Interfaces And in Java you have this nice "interface" keyword for
this

Interfaces can't have implementation. Abstract classes can have
implementation, which is why there's the distinction.

 

[Frank]

They're useful because you can then give a loud-and-clear signal that on
their own they're useless, but that they're designed to be subclassed.

Valid... Though I feel documentation is a better approach, rather than
strictly enforcing it.

The AWT adapter classes are good examples - except they haven't been made
abstract. It would make sense for them to be abstract because there's no
point in having a straight KeyAdapter, for instance - but there are no
abstract methods because the point is to be able to only override *some*
of the methods.

Actually, they're bad examples... you'll find that all the adapter classes
in java.awt.event *are* abstract - and it's a pain in the butt. In this
case, it is much easier to use something of the form

void setListener(WindowListener wl) {
if (wl==null) wl=new WindowAdapter();
//no more checking against null pointers
//yet still null affect
//really usefull if this is a wrapper
//class for WindowListener, and we have
//to write out a series of fall through
//methods

//too bad this doesn't work since some
//programmer made WindowAdapter abstract!#!#!!!
listener=wl;
}

Point being, be carefull with enforcement: just because you don't see the
point in someone not subclassing your class doesn't mean they might not see
things from a different perspective. If your class doesn't *need* to be
abstract, you're better off not making it abstract, but do note that it is
intended for subclassing in your documentation.

HTH,

Frank

 

[Bent C Dalager]

Actually, they're bad examples... you'll find that all the adapter classes
in java.awt.event *are* abstract - and it's a pain in the butt. In this
case, it is much easier to use something of the form

void setListener(WindowListener wl) {
if (wl==null) wl=new WindowAdapter();

It's not really a lot more work to write
if (wl==null) wl=new WindowAdapter(){};

although it doesn't feel entirely right. Which is probably as it
should be anyway. Creating entirely empty objects _should_ be setting
off a warning light or two.

Cheers
Bent D

 

[Thomas Weidenfeller]

No, these are different from interfaces. Interfaces can't implement
anything. The classes I'm after implement methods, but still aren't
directly instantiable.

Ups, I misread the original question as "without including any method".
Sorry.

/Thomas

 

[Steven Coco]

This doesn't _necessarily_ address the design issue of a class that is
abstract yet has implemented all of its methods; but:

Valid... Though I feel documentation is a better approach, rather than
strictly enforcing it.

I don't necessarily agree with that as a "sentiment"; simply meaning:

When you leave something to documentation, it is (a) more breakable--the
documentation can't keep anyone from using it wrongly; and (b) left to
english--or whatever your language--to explain programmatic behavior
when instead you could use a language designed to capture programmatic
behavior with accuracy--namely your programming language.

So; it _would_ be nice if there were a programmatic way to implement a
desired pattern "correctly".

So; when I've said "programmatic", it doesn't necessarily mean "more
strict" or "limiting" as in you can't deviate from an implemented rule;
instead it may mean literally "more open" or "unrestricted" as in this
method will perform this operation on _any_ object--the implementation
has *defined* an open pattern.

This I think makes a better product than a whole lot of documentation.



Peace,
Steev.