While working on a small class called
FractionNumber I found asking myself if I should implement an interface that I am already implementing. Sounds stupid, I know, but bear with me.
Serializable. And I am unsure if
FractionNumber should explicitly implement
Serializable as well.
Of course it does not really matter because
Serializable only defines final methods and
FractionNumber inherits the
Serializable ‘implementation’ of
Number. But I kind of like making my
Now to my question: Is this simply useless or does the verbosity help in some way? Does it make sense, in a philosophically sense, to declare
FractionNumber being something it already is?
From a code point of view
Contracts set by the parent type should be implied for the sub type.
If you feel the need to express serialization abilities in every type that can be serialized (maybe you feel you need to explicitly remind yourself/co-developers that something can be serialized) you should refactor your code to strengthen the implication.
From a JavaDoc point of view
All interfaces implemented by the type, including inherited interfaces, are displayed in the header under “All implemented interfaces“. The only difference is the actual declaration displayed in the JavaDoc:
If directly implementing interface:
public class Sub extends Super implements Serialization
public class Sub extends Super
To me, this is clutter (duplication), and I recommend against it.
In general, you probably should not be redeclaring that you implement interfaces in this way but
Serializable is not a normal interface. You say that “
Serializable only defines final methods” but that’s not the case (I double-checked).
Serializable declares no methods at all. It’s a marker interface which is widely considered to be an anti-pattern and I am in full agreement with that assessment.
The fact that your class must be serializable because a super-class (or interface) implements
Serializable is an artifact one of the most prominent design flaws in Java.
Serializable is specifed using an interface but
transient is a keyword. Why
serializable isn’t a keyword too is a bit of a head scratcher. If java serialization was designed now, it likely would be done with annotations.
Because of all this wackiness, if you are going to implement
Serializable, I would go ahead and redeclare it to show that you actually intend it to work with java serialization and that it’s not
Serializable because simply because a base class was declared that way. Personally, I wouldn’t use java serialization, though. There are many better ways to create wireformat and I think the idea of ‘object transmission’ is inherently flawed.