Win a copy of Learn Spring Security (video course) this week in the Spring forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Abstract Class!!!

 
Brian Smith
Ranch Hand
Posts: 232
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi folks,
read the literature about Abstract class and found that if there is a situation where class is representing abstraction that is general, the class should be Abstract so that the sublcass makes such general abstraction more concrete and specific. now,would it be bad design strategy if we have concrete class represent such general abstraction instead of having Abstract class? if so, WHY? please explain me WHAT would be consequences if we have CONCRETE CLASS represent what ABSTRACT CLASS would represent?
thanks.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
An abstract class does not allow anyone to create an instance. That might be correct if the abstraction is so general that it is not meaningful or functional without extension. I've done frameworks where some abstract methods throw exceptions that say "You must override this method" to force derived classes to provide some functionality.
On the other hand, I have a SAX DocumentHandler base class with valid functionality that could be used as-is for very primitive processing, so the class is not abstract and all method overrides are optional.
Do those examples help?
 
Joel McNary
Bartender
Posts: 1840
Eclipse IDE Java Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To use one of my favorite examples:
Say you were a god and were creating the world using Java. When it came to life, you might have a class:

It is useful to have the "die" method in this class since all LivingThings must be able to use this method, but it makes not sense to have an instance of a "LivingThing." The concept is jsut to vague.
You can then have subclasses. Animalia extends LivingThing, Chordata extends Animalia, Mamalia extends Chordata, etc. All of these would be abstract calsses because, while they provde functionality, it makes no sense to create an instance of a Chordata.
The leaves of this tree would all be concrete, however (how's that for an image? Concrete tree leaves...)
EmperorPenguin extends PenguinFamily, HomoSapiens extends Primate, Ceolocanth extends Fish, etc.
Now, of course, interfaces can be used to group similar things. For example, both Fish and PenguinFamily would implement the Swimmer interface (even though they might implement it differently) A FruitBat class, the Bird class, and several Insect classes would implement the Flyer interface.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic