• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Abstract Class!!!

 
Ranch Hand
Posts: 232
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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?
 
Bartender
Posts: 1844
Eclipse IDE Ruby Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic