Question

This question may be a little bit subjective, but I'm just trying to follow the best programming practices for organization of code.

I have a class Polynomial that makes a lot of reference to the class Rational, and in many different methods it uses a Rational value that is equivalent to 1, 0, or -1 for comparisons.

As such, I have the following constants defined:

public static final Rational ZERO    = new Rational(0);
public static final Rational ONE     = new Rational(1);
public static final Rational NEG_ONE = new Rational(-1);

However, the thing I'm not certain about is where to store these values in a meaningful way.

On the one hand, Polynomial is what uses them, so storing them inside of the class localizes it to where it is going to be used. This also means that it can be changed to private so that it is only used within the one class.

On the other hand, if it is defined inside of Rational, then all calls to the values become Rational.ZERO, Rational.ONE,Rational.NEG_ONE -- which makes it very human-readable, and organizes it in a lexically understandable manner. It also gives the opportunity to define similar constants in Polynomial as well if ever it were needed.

So basically, opinions aside, what's the most common practice for organization in something like this? Are my thoughts right for either of the locations for it, or is there another solution that I hadn't considered?

Was it helpful?

Solution

They should be in the Rational class since they are abstraction for rational numbers. It would be debatable if you would want to move them to a RationalPolynomial class, but even then I believe keeping them in Rational would be better.

A big requirement for doing this is making your Rational class immutable; otherwise you shouldn't expose them as public. Effective Java mentions at page 76:

Immutable classes should take advantage of this by encouraging clients to reuse existing instances wherever possible. One easy way to do this is to provide public static final constants for frequently used values. For example, the Complex class might provide these constants:

public static final Complex ZERO = new Complex(0, 0);
public static final Complex ONE = new Complex(1, 0);
public static final Complex I = new Complex(0, 1);

OTHER TIPS

Another suggestion - you could do something similar like Java does with Strings, which is, reusing existing instances.

So you could give Rational private constructors, which prevents other classes to create direct instances of it, and introduce a public static factory method, e.g. "Rational.get(1)" or "Rational.of(1)".

That way, you could keep some popular numbers like the ones you mentioned in static fields and return them instead of creating new instances. You could even think of keeping a (limited) pool that could increase performance further in case a bigger number of Rationals are reused over and over again.

The big plus of this solution is that new developers, that don't know about the constants you introduced, do not use "Rational(1)" by mistake, as everyone is forced to use the factory method.

Of course, with that approach, you should also make sure the Rational class is immutable!

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top