aspose file tools*
The moose likes Java in General and the fly likes Why are Abstract classes with all concrete methods allowed? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Why are Abstract classes with all concrete methods allowed? " Watch "Why are Abstract classes with all concrete methods allowed? " New topic
Author

Why are Abstract classes with all concrete methods allowed?

Tan Richards
Greenhorn

Joined: Sep 29, 2005
Posts: 18
Hi,
Can anyone plz tell me why abstract classes with all concrete methods are allowed? It doesn't make sense to me bcoz if all the methods are concrete then what is the need for the class to be abstract?


"Failures are pillars of success" - That doesn't mean you go on building pillars
Seb Mathe
Ranch Hand

Joined: Sep 28, 2005
Posts: 225
It is because specifications says that a class must be abstract if it contains abstract(s) methodes, and doesn't say that if a class don't contain an abstract method it must not be abstract...

The only sense of having a class abstract with all contrete methods is to avoid to instantiate the class. But the prefferred way to do this is declaring all constructor private.


Regards,<br />Seb<br /> <br />SCJP 1.4
Jeff Albertson
Ranch Hand

Joined: Sep 16, 2005
Posts: 1780
Two examples of abstract classes with no abstract methods
are java.awt.Component and javax.swing.JComponent. BTW, The
easiest way to see they have no abstract methods is to run:

And let me add in passing that I'm glad these classes have
non-private constructors!

So why are they abstract? because is not such thing as
a generic JComponent, instead there are JButtons and JTrees
etc... So why are there no abtract methods? Because each
could be provided with a reasonable default implementation,
to make it easier to write subclasses.

Does that make sense?


There is no emoticon for what I am feeling!
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
More to the point, why are abstract classes allowed at all?
You're stumbling on the issue of the inappropriate abstractions that Java permits (no compile-time safety). There are thousands more.


Tony Morris
Java Q&A (FAQ, Trivia)
Ken Blair
Ranch Hand

Joined: Jul 15, 2003
Posts: 1078
One reason a developer might want an abstract class with no abstract methods is if the class should not be instantiated but functionality common to a number of classes is desired. This way the code doesn't need to be written repeatedly in multiple classes. That being said, there are much better ways to do this as someone like Tony Morris will quickly point out. Many people believe that implementation inheritance shouldn't be permitted in the first place.

Personally, I tend to agree with them though I'm not nearly educated enough to say one way or the other with any degree of certainty.
Jeff Albertson
Ranch Hand

Joined: Sep 16, 2005
Posts: 1780
Many people believe that implementation inheritance shouldn't be permitted in the first place.


Just wondering how these people would achieve the equivalent of a
custom JComponent. Class javax.swing.JComponent has over 300 public
methods!

Yes, when learning OOP there's a phase everyone goes though -- "when
all you have is a hammer, everthing starts to look like a nail" phase --
and everything gets subclassed. Still there are times when it's the
right thing to do, IMHO.
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608

Just wondering how these people would achieve the equivalent of a
custom JComponent. Class javax.swing.JComponent has over 300 public
methods!

That JComponent has 300 methods does not prevent one from abandoning concrete inheritance. The truth of the matter is that concrete inheritance can never be abandoned, within the context of Java. Simply, class X{} implies concrete inheritance. JComponent not only purports concrete inheritance, it also fails to specify all public operations on an interface, and exceeds contract (failure to assert symbiotism on contractual operations). This is evident, when for example, you call a method of a subclass that "does nothing". What you might be referring to is the alternative whereby, JComponent is an interface, which (erroneously) specifies all 300 operations on that interface. Subtypes (subinterfaces) add more operations, and concrete types typically have to perform delegation to achieve a similar functionality. This is an unfortunate limitation of Java. That Java is verbose, to the point of being laboursome, in a given context is not enough to invalidate that context. More likely, to invalidate Java itself.

Form another perspective, javax.swing is a perfect example of how NOT to design APIs. Have you ever attempted to specify a full set of requirements for a swing application? For example, written a unit test harness that achieves 100% system state coverage, or even 100% code coverage? Why is it impossible? If you are with me at this point (most people have scowled and thrown rocks at me by now), then does the very fact that you cannot (as opposed to "it's difficult") specify requirements when dependant on some arbitrary API imply that the API itself is invalid (defective)?

Time to reflect
Jeff Albertson
Ranch Hand

Joined: Sep 16, 2005
Posts: 1780
Gosh, I wish I was smart enough to understand 15% of what you're saying.
Could you define your terms?
Ken Blair
Ranch Hand

Joined: Jul 15, 2003
Posts: 1078
I'm not clear on everything you said, but when I noticed classes in Swing being forced to throw IllegalOperationExceptionS because they inherited a completely inappropriate method I realized one of two things must be true. Either Swing is of poor design because it abuses concrete inheritance, or concrete inheritance itself is bad. I'm still not sure if concrete inheritance itself is bad or if it's simply misused. I think that my experience so far is leading me to believe it'd be a better idea to define contracts your classes will fulfill through interfaces. All concrete inheritance seems to do is allow more than one class to use the same higher level code. Good in the sense that something common to a number of Objects may only need to be in one place and be easy to change without editing all of them. However, can't you simply create a class to handle that, defined by an interface, that all those Objects the methods are common to delegate to? It only requires a little more typing, adding the methods to each class and then forwarding the calls to the other. Seems like this is a more OOP approach that is less likely to cause problems in the future when a new class needs only some of that functionality. First, because a class can implement any number of interfaces the methods can be broken up into any number of different interfaces where the only methods in it are directly relevent to each other. Second, any class can implement only the interfaces it needs to, so if the interfaces are well defined and only contain relevent methods the class isn't forced to implement inappropriate/irrelevent methods.

Perhaps someone will pipe in with the "good" alternative to concrete inheritance.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Personally I think that getting rid of concrete inheritance just because the Swing developers came up with a ball of mud (an exaggeration I know ) is throwing out the baby with the bath water. I don't see any problem with, for example, MouseAdapter (other than the misleading name, that is).

I use concrete inheritance all the time, for example via the Template Method pattern. Often enough it doesn't hurt and simply is less complex than any other solution. And once it starts to hurt, I refactor to something else. What's the fuss?


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Ken Blair
Ranch Hand

Joined: Jul 15, 2003
Posts: 1078
Any design that has methods throwing IllegalOperationExceptionS because classes inherited methods they can't use is flawed. With that premise in mind that means either the Swing developers abused concrete inheritance or concrete inheritance is itself flawed. It could be either or both. I think they abused the hell out of it which means whether or not concrete inheritance itself is flawed too is still up in the air. As I said, I'm not well enough educated to begin to answer that.

I don't think anyone else contends concrete inheritance is bad because Swing developers abused it either. For those who dislike it Swing is an easy example to point to. I doubt they'd change their mind if Swing had been written differently because I seriously doubt Swing is what made them decide that.
Jeff Albertson
Ranch Hand

Joined: Sep 16, 2005
Posts: 1780
I think the discussion has moved into the topic of "fat interfaces",
a topic need and dear to me (see my profile pic).

The standard example is the collections framework, where certain
interface methods are optional, for example:

Optional operations may throw UnsupportedOperationException.
Now, if you like stronger compile-time type checking this is not
so good, but the alternative would have many more interfaces,
because some collections are only partially mutable: think of
an array-backed List that can't grow, but can support set.

So in this case, the designers went with the simpler solution.
For me, anyway, while I am normally a strongly-typed guy, I
haven't raised many UnsupportedOperationExceptions, so I can't complain.

Notice this has nothing to do with implementation inheritance.
[ October 19, 2005: Message edited by: Jeff Albrechtsen ]
Ken Blair
Ranch Hand

Joined: Jul 15, 2003
Posts: 1078
I'm not an expert here, but it seems to me if a method in an interface is "optional" it shouldn't be in the interface to begin with.

I now have a word for what I was talking about in previous posts. Joshua Bloch refers to it as composition in Effective Java. He seems to come to many of the same conclusions as I did about concrete inheritance which he calls implementation inheritance which is the basis for the reasoning behind using composition instead of inheritance.
[ October 19, 2005: Message edited by: Ken Blair ]
Jeff Albertson
Ranch Hand

Joined: Sep 16, 2005
Posts: 1780
I'm not an expert here, but it seems to me if a method in an interface is "optional" it shouldn't be in the interface to begin with.


So the Java's Collection Framework, java.util.ArrayList, java.util.HashMap, etc... is all wrong?!
[ October 19, 2005: Message edited by: Jeff Albrechtsen ]
Ken Blair
Ranch Hand

Joined: Jul 15, 2003
Posts: 1078
EDIT: This is from a purely intellectual standpoint. Sometimes requirements and available resources make it impossible to do it any other way.

Unless my understanding of interfaces is wrong, yes. Is an interface not defining a contract implementing classes need to live by? If you make it "optional" in the form of an UnsupportedOperationException then as I understand it you've effectively broken the contract specified by the interface. What good is an interface defining a Collection if you've no guarantee that the Collection will actually implement all of the methods in the interface? Some of them are required so you can use those, but if you have a group of required methods and a group of optional methods in the same interface that indicates to me that they don't belong together!

Am I wrong?
[ October 19, 2005: Message edited by: Ken Blair ]
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

The truth is if the class does not have any unimplemented methods, then it can be concrete. And in this case you can do composition as opposed to inheritance. But composition is a bunch of typing and is error prone since Java does not provide any help with it...

Since I dont like concrete inheritance, inheriting from abstract classes makes life easier. If the class is abstract it will never be loose in the wild.
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608

I don't see any problem with, for example, MouseAdapter (other than the misleading name, that is).

I agree entirely. That is, the strongest argument "for" concrete inheritance is "saves typing in the context of Java", an unfortunate trait of the language. The subjective part is whether or not you accept this argument as legitimate; I do not, but if you do, so be it. I urge anyone to consider deferring conclusions until they understand the arguments "against" concrete inheritance (or even more importantly, the proof that it is an implicit requirement defect within a given context (the one that we are all (inadvertantly?) assuming)).
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Well, none of my conclusions are ever final, so I'm prepared to change them when I learn something new. And I plan to learn something new until the end of my life...

I also don't have any problems accepting that there might exist languages with better alternatives to concrete inheritance. Might be interesting to learn them. On the other hand, I think I'm quite well with using concrete inheritance when using it wisely, so I don't feel a strong force to search for such a language or call concrete inheritance "evil".
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5608
    
  15

this is a discussion that goes far above my head and my understanding, but what is meant by "concrete inheritance", because it's just in nearly every post and i never heard of it.

i know there is inheritance, and you can inherit from a abstract and a non-abstract class (concrete class, maybe this is meant by "concrete inheritance", but what's then the difference(s) between inheriting from an abstract and a non-abstract class)


SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
http://www.javaroe.be/
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
As far as I understand, "concrete inheritance" is synonymous to "implementation inheritance" - in contrast to "interface inheritance".
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
To suggest that something is "evil" is a perhaps unintentional over-simplification. Something might be "evil" within a given context. For example, putting your finger on a hot frying pan is "evil" within the context of "you don't want to inflict pain upon yourself", simply because they are contradicting requirements. "concrete inheritance is evil" within the context that we are all assuming (for example, valid software as a solution to a problem statement (a vast simplification for the sake of brevity)).
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Why are Abstract classes with all concrete methods allowed?