5

I know that the byteValue() and shortValue() have implementations unlike the other abstract methods and were added in JDK1.1. This wouldn't have been possible if it was an Interface. But when the developers were writing Number class why did they make it an abstract class? Was it only because they expected that they might add more methods later on? I would only need answers supported by authoritative citations. thanks a lot everyone for the time you are taking to review my question and give answers.

Sandeepy
  • 61
  • 4
  • 2
    They could have made it an interface instead of a abstract class, but a concrete class wouldn't have made sense. Before Java 8, they couldn't add implementations to interface. – Peter Lawrey Mar 20 '17 at 15:58
  • 1
    Suggestion: if you edit your question to specify that you want only answers supported by authoritative citations (discussions from the language designers on email lists, etc), then you may avoid some of the votes to close as opinion based. – yshavit Mar 20 '17 at 16:07
  • @yshavit Thank you for your suggestion. – Sandeepy Mar 21 '17 at 20:01
  • 1
    You simply may not like the answer, back in the Java 1 days Sun was still learning to design the API and many mistakes were made. I tend not to really question the older classes that were made prior to Java 5, they're from a different era. – Gimby Mar 21 '17 at 20:06

1 Answers1

1

Nobody here will know what went on in the minds of the designers, however abstract classes and interfaces are used for different purposes.

Classes (in Java) inherit in a strict hierarchy, and this hierarchy is a tool that can be used to ensure seperation of unrelated classes of objects. Classes are also more logical when the core functionality of the entire hierarchy is similar.

For example, with abstract classes Number and Letter it would not be possible to have a class that is both. With interfaces one could create a class that implements both which would make no sense.

Interfaces on the other hand are often used to expose a (usually) small piece of a class in a formal way so they can be used by reusable logic that uses only the functionality specified in the interface. They're more often used for adding supporting functionality, like Serializable, Comparable or Runnable.

An example, Printable and Comparable would be terrible abstract classes, as it would make it impossible to have a Comparable object also be Printable.

So the designers may have specifically chosen to make Number an abstract class to ensure that only one hierarchy of classes can be numbers, and nothing else. Perhaps it may allow for future optimizations where the JDK treats these classes as special cases, just like it does for String.

john16384
  • 7,800
  • 2
  • 30
  • 44
  • 1
    "Nobody here will know what went on in the minds of the designers" -- A couple of them will post here now and then, plus answers like this in the past have sometimes been answered with citations to email list conversations they had. As for a class not making sense as both a Number and a Letter... `char` works similarly to that (though `Character` does not), so I don't think it's fair to assert unequivocally that it makes no sense. – yshavit Mar 20 '17 at 16:55
  • Perhaps I'm unable to word it right, but when designing classes and interfaces I do seem to pick one or the other for specific reasons. I've tried outlining those here. Another good place to look could be here: http://stackoverflow.com/questions/761194/interface-vs-abstract-class-general-oo – john16384 Mar 20 '17 at 17:03