7

In this thread I found some interesting moment, If class uses only as superclass there isn't rule to make it abstract. Why so?

Thanks

Community
  • 1
  • 1
Stan Kurilin
  • 15,614
  • 21
  • 81
  • 132
  • possible duplicate of [why isn't java.lang.Throwable an abstract class?](http://stackoverflow.com/questions/4306214/why-isnt-java-lang-throwable-an-abstract-class) – user207421 Nov 30 '10 at 09:33

3 Answers3

9

It all depends on whether or not it makes sense to have instances of the class.

Suppose you for instance have one class Dog and one class Cat. They both extend Animal. Now an Animal may have a name and a few methods, but it doesn't make sense to have Animals running around. An Animal is... well an abstract notion.

In other circumstances you may have subclasses (the LinkedHashSet for instance extends HashSet) but it still makes a lot of sense to instantiate the super class (HashSet in this case).

To answer your comment, "Does it make sense to make a class non-abstract even if you don't want to instantiate it."

Well I'd say if you, today, simply don't know of any use-cases in which it should be instantiated, the same rule applies: Does it make sense (logically) to have an instance of the class? If so, make it non-abstract.

If the situation is more like "If you've created an instance of this class, you're probably doing it wrong!" then I'd clarify this by making the class abstract.

aioobe
  • 413,195
  • 112
  • 811
  • 826
  • Yeap, thanks. Bur I still interesting, Is there are any cases when we use non abstract class but don't create it's instances? – Stan Kurilin Nov 30 '10 at 07:11
  • 1
    Well, the closest think I can think of is when you use the singleton pattern. Then you don't want to create any instances after you've created a single instance. In such cases you usually make the constructor private to avoid creating further instances. – aioobe Nov 30 '10 at 07:20
4

Following from @aioobe - Think of the following situation.

In a company, you have a position called Accountant. Now, let's say that hypothetically you have someone that specializes in auditing, and we say his title is Auditor. Now, the company has 100 accountants, but only 4 Auditors. In this case, you would want to instantiate both the Accountant and Auditor classes, even though Accountant is a super-class of Auditor.

Nico Huysamen
  • 10,217
  • 9
  • 62
  • 88
  • Yeah. But in this case 'Accountant' uses not only as a superclass. – Stan Kurilin Nov 30 '10 at 07:28
  • @Stas - Aaah, I see what you mean. Sorry, could not quite make out the question. In that case, I agree with @aioobe 's post. Seems to have gotten it spot on. – Nico Huysamen Nov 30 '10 at 07:31
  • Couldn't you make a `specialties` instance variable that holds the `Auditing` role? If an existing `Accountant` becomes an Auditor, you could just call the `addSpecialty()` method. – Eva Sep 30 '13 at 21:24
  • @Eva - That is a very specific use-case that you are talking about, namely role-based functionality. In something like a web application where a lot of functionality is driven by the role of the *user*, then sure, just add the specialty role. But when talking about normal OOP programming, you might want to add extra functions to the Auditor class, while inheriting all the Accountant functionality. For instance an Auditor needs the `audit(final Book book);` function, which an Accountant wont have. You cannot add that simply by calling `addSpecialty()`. – Nico Huysamen Oct 01 '13 at 08:43
1

If the class is complete and usable it makes sense that you should be able to instantiate and use the class, even if the user decides to extend it later.

The class should only be abstract if the user needs to implement some logic to make it functional within the framework in which it is being used i.e. where the class designer does not know the exact implementation details of how the class will be used, like the template or command design patterns for example.

Neal Donnan
  • 1,733
  • 1
  • 13
  • 18