• 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
  • Paul Clapham
  • Tim Cooke
  • Jeanne Boyarsky
  • Liutauras Vilda
Sheriffs:
  • Frank Carver
  • Henry Wong
  • Ron McLeod
Saloon Keepers:
  • Tim Moores
  • Frits Walraven
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Piet Souris
  • Himai Minh

making superclass abstract -- best practice

 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm working on a project that uses inheritance several times. In all cases. the superclass is not instantiated, so I could make it abstract. Before doing making it abstract, I want to check on what is the 'common practice' here.

Is making the superclass abstract in this situation just documentation that the class is not instantiated? Or am I creating an expectation in a subsequent developer that I have some specific design reason for not instantiating it?

In my case, there is no special reason for this design, it just turns out that every subclass needed to add its own methods, so the superclass is never instantiated as such.

TIA for any advice on what is 'good practice' here.
 
Ranch Hand
Posts: 114
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If there's no reason to make the class abstract then don't make it abstract. You're more likely to get so far down the line and end up making it instantiable again later when you finally need to. My philosophy on how to create code is generally an agile approach -- if you can't explain why (by unit tests or other means) you're complicating an interface, then don't complicate it. If you could provide an test case which showed a problem with drectly instantiating the class then you'd have reason to change your code

I only use abstract classes when:

a) I want to provide an interface along with some partial functionality
b) I want to create a class that must never be instantiated directly

It sounds like you aren't doing either of those so your code should stay as it is

EDIT | Typo..
[ September 02, 2007: Message edited by: Chris Corbyn ]
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Andrew, welcome to the ranch!

I'd vote the other way: use the most abstract thing you can. Prefer interface, abstract class, concrete class in that order. The infamous Extends is Evil article shows the dangers of extending a concrete class. Even if you don't buy everything he says, take away the risks of extending a concrete class and avoid it where possible. If you never do it, you will keep to the Liskov Substitution Principle much more easily.

BTW: If you're into topics like this, scroll on down to the OO, UML, etc. forum. This kind of conversation goes on all the time.
[ September 02, 2007: Message edited by: Stan James ]
 
If you are using a wood chipper, you are doing it wrong. Even on this tiny ad:
the value of filler advertising in 2021
https://coderanch.com/t/730886/filler-advertising
reply
    Bookmark Topic Watch Topic
  • New Topic