1

Is preventing the instantiation of a class a valid reason to make it abstract? For example, if I have a class called Gauge which has subclasses HeadingIndicator and AirSpeedIndicator, is it a good idea to make Gauge abstract? Because instances of Gauge are pretty useless on their own, but might be useful as references to its subclasses.

10

Usually Abstract classes are used when one has a class which has some methods which needs to be implemented by one of its child classes, thus, when one sees an abstract class one also expects to see a series of abstract methods which must be implemented.

So although you can use abstract classes to denote non instantiable classes, I do not think that if you want to stop people from instantiating your class this would be the way to go.

Another thing you could do, if you would like to prevent instantiation would be to declare the constructor of the parent class as protected. That way, it will not be visible to outside classes other than the ones which extend it:

public class Gauge
{
    ...

    protected Gauge(...)
    {
        ...
    }

    ...
}

public class HeadingIndicator extends Gauge 
{
    ...

    public HeadingIndicator(...)
    {
        super(...);
    }

    ...
}

public class AirSpeedIndicator extends Gauge 
{
    ...

    public AirSpeedIndicator(...)
    {
        super(...);
    }

    ...
}

This way, the means to create instances of the Gauge class is restricted only to the extending classes.

  • that's a very good point - I hadn't considered changing the access of the superclass, thank you... I would certainly up-vote your answer if only I had the rep :) – J Smith Jan 28 '15 at 15:45
  • @JSmith: No problem. Note that the above is purely based on my opinion, I wasn't able to find points which say that you should not use abstract classes to remove instantiation. – npinti Jan 28 '15 at 16:01
2

It depends on why you want to prevent instantiation.

If you want to have control over instances e.g. the singleton pattern then you would hide/encapsulate the constructor.

If the class is a generalisation that in its self could never be an instance then it makes more sense for it to be an abstract class.

1

You're already asking yourself the right question: Is a gauge of no specific type useful to anybody? What does it measure? What units does it use? As you've already noticed, it's not.

So clearly a gauge isn't something that needs to be instantiated itself. That means a gauge should probably be either an abstract class or an interface. I usually prefer to make my class interfaces and then if appropriate provide an abstract class implementation of that interface if I need to provide a default implementation of some common behavior.

One thing you should consider, though, is whether or not a gauge should be a type at all, and that all comes down to what specifically you're doing. A lot of 'gauges' don't really do anything common to all gauges. If this is the case, consider loosening up your model a bit and maybe not even having a gauge interface. Let HeadingIndicator and AirspeedIndicator be their own separate, unrelated classes. Or maybe you'd like a uniform way to display these gauges and want an interface with methods like Unit units(), String labe() and double measurement().

I guess the tldr; here is that if it seems to be difficult/awkward to abstract these two entities into an abstract parent, maybe that abstraction isn't needed and can be skipped. Are you going to be writing code that applies to all gauges? If not, skip the parent interface/abstract class. It's easy enough to extract an interface later for the code that will need the interface.

0

From my point of view, yes it is.

The only question is, do you want a class, or an interface is enough?

So the question will be: do you have common behaviour (method implementation) between child classes, so you need a common abstract class, or just method declaration (in this case, better use an interface)?

D.

  • To be honest I've not thought all that far ahead - but I suppose it's entirely possible that you have two gauges that update() differently - meaning that they do not share behaviour. – J Smith Jan 28 '15 at 15:37
0

An abstract class mean that some parts of its implementation may be missing. IMHO, the fact that a Gauge may be useless on its own is your opinion, not the opinion of all the users of your API.

I would only declare such a class abstract if it lacked important methods, but never as a mean to prevent the user from instantiating such an object.

First, I would write some documentation on that specific class, and why it should not be used as is. Then I would ask myself whether I really want to prevent anyone from using that object, and why (because it's not clearly defined in your case).

And the last step would be to either use a special constructor or make the class abstract (but this is really something that I still wouldn't do because it feels like the API and the objects are badly designed).

  • I think that documenting exactly what it is that I want from the class, and what behaviours define the class is certainly a good idea - thank you. – J Smith Jan 28 '15 at 15:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.