Java Best Practices – Interface Subclasses and Constants

interfacesjava

In the case where a couple of classes implements an interface, and those classes have a couple of constants in common (but no functions), were should I put this constant ?

I've had this problem a couple of times.

I have this interface : DataFromSensors that I use to hide the implementations of several sub classes like DataFromHeartRateMonitor DataFromGps etc…

For some reason, those classes uses the same constants. And there's nowere else in the code were it is used.

My question is, were should I put those constants ?

Not in the interface, because it has nothing to do with my API

Not in a static Constants class, because I'm trying to avoid those

Not in a common abstract class, that would stand between the interface and the subclasses, because I have no functions in common, only a couple of constants (TIMEOUT_DURATION, UUID, those kind of things)

I've read best practice for constants and interface to define constants but they don't really answer my question.

Thanks !

Best Answer

The other thing you can do is specify it in a config resource that you include with a jar. Constants are kinda funny: You think they never need to change until they do and then you have to recompile to code to change your TIMEOUT_VALUE.

If you put it in the jar with the rest of the resources then it is, for all intents and purposes, constant. However, it's not code and, in the off chance you have a problem, you can modify it in the field.

Just an idea. Putting statics in the interface is only a problem if it's the ONLY thing that interface does. Somethings in programming just are ugly and you have to make some tradeoffs.

Related Solutions

Abstract Classes vs Interfaces – Key Differences and Usage

In layman's terms:

Interfaces are for "can do/can be treated as" type of relationships.

Abstract ( as well as concrete ) classes are for "is a" kind of relationship.

Look at these examples:

class Bird extends Animal implements Flight;
class Plane extends Vehicle implements Flight, AccountableAsset;
class Mosquito extends Animal implements Flight;
class Horse extends Animal;
class RaceHorse extends Horse implements AccountableAsset;
class Pegasus extends Horse implements Flight;

Bird, Mosquito and Horse are Animals. They are related. They inherit common methods from Animal like eat(), metabolize() and reproduce(). Maybe they override these methods, adding a little extra to them, but they take advantage of the default behavior implemented in Animal like metabolizeGlucose().

Plane is not related to Bird, Mosquito or Horse.

Flight is implemented by dissimilar, unrelated classes, like Bird and Plane.

AccountableAsset is also implemented by dissimilar, unrelated classes, like Plane and RaceHorse.

Horse doesn't implement Flight.

As you can see classes (abstract or concrete) helps you build a hierarchies, letting you inhering code from the upper levels to the lower levels of the hierarchy. In theory the lower you are in the hierarchy, the more specialized your behavior is, but you don't have to worry about a lot of things that are already taken care of.

Interfaces, in the other hand, create no hierarchy, but they can help homogenize certain behaviors across hierarchies so you can abstract them from the hierarchy in certain contexts.

For example you can have a program sum the value of a group of AccountableAssets regardless of their being RaceHorses or Planes.

Design Patterns – Adhering to a Protocol and Being a Subclass Simultaneously

This is the pattern that is often used to address the lack of abstract classes in Objective C.

It is very common for the missing method stubs of the base implementation to raise an exception, to make sure that you catch incomplete implementations. See this answer on stack overflow for details of how it is commonly done.

Best Answer

Related Solutions

Abstract Classes vs Interfaces – Key Differences and Usage

Design Patterns – Adhering to a Protocol and Being a Subclass Simultaneously

Related Topic