Use of static factory methods for vectors and matrices library

Question

I've been working on a Java-based mathematics library focusing on vectors and matrices. I plan to use it for an important upcoming project, so the classes are analogous to data types available in GLSL (e.g. Vector2 for GLSL's vec2, Matrix4 for GLSL's mat4, and so on).

I'm trying to only expose interface to clients (e.g. Vector2) and keep implementation classes package-private (e.g. Vector2f). I'm trying to use the static factory methods and, since I'm using Java 1.8, I'm trying to take advantage of the new option that allows static methods to be added to interfaces.

However, there's something I currently don't like too much and I'm wondering if there's a way to improve the code design to address it.

Here's what the interface looks like (I've omitted the non-static methods for brevity because they're not relevant to the question):

public interface Vector2 extends Measurable, Bufferable {

    static Vector2 createZeroVector() {
        return Vector2f.createZeroVector();
    }

    static Vector2 createFrom(float x, float y) {
        return Vector2f.createFrom(x, y);
    }

    static Vector2 createFrom(double x, double y) {
        return Vector2f.createFrom(x, y);
    }

    static Vector2 createFrom(final float[] values) {
        return Vector2f.createFrom(values);
    }

    static Vector2 createFrom(final double[] values) {
        return Vector2f.createFrom(values);
    }

    static Vector2 createNormalizedFrom(float x, float y) {
        return Vector2f.createNormalizedFrom(x, y);
    }

    static Vector2 createNormalizedFrom(double x, double y) {
        return Vector2f.createNormalizedFrom(x, y);
    }

    static Vector2 createNormalizedFrom(final float[] values) {
        return Vector2f.createNormalizedFrom(values);
    }

    static Vector2 createNormalizedFrom(final double[] values) {
        return Vector2f.createNormalizedFrom(values);
    }

    // ... non-static methods omitted ...
}

I'll briefly note that:

final class Vector2f implements Vector2 {
    // details omitted
}

Since the interface methods are static, they must be implemented in the interface itself. Classes implementing the interface don't get overrides because this can be resolved at compile time.

However, if a client goes ahead and does something like this:

public class Vector2d implements Vector2 {
    // a double-precision implementation
}

and then tries to use the interface as intended:

// ...
Vector2 vec = Vector2.createFrom(5f, 3f);

Then there seem to be at least 2 problems:

1. the interface knows about a specific implementation and can only return Vector2f instances, and

2. a client expecting a Vector2d implementation class gets a Vector2f instead!

Since the methods in the interface are static, there seems to be no way for the client to actually get an instance of the hypothetical Vector2d implementation without changing the interface itself.

How can I improve the code's design in order to resolve this problem for clients?

I've read other articles and I'm not aware of something else that might be helpful here, though I might be wrong.

Answer 1

To put it simply, you're using the wrong language elements to achieve your goals.

The purpose of interfaces is to serve as a contract. They define a set of actions that implementations must be able to perform. Although Java 8 made it possible to add static and default methods to an interface (and I'll have to read up on why they did that), it's best when an interface contains no implementation at all. Before adding static or default methods, think twice, and question yourself if there's a better way.

In this example, it seems quite clear that all those createFrom* methods are in fact utility methods, that would be best in a utility class. There's no point putting them anywhere else if they cannot be extended or overridden. So it would be better to extract these to a Vector2dUtils class or similar.

And why does a Vector2d extend Bufferable and Measurable? What does that even mean? It seems like this interface is trying to do too much. I strongly suspect violations of the single responsibility principle in your implementation.

1. the interface class knows about a specific implementation and can only return Vector2f instances, and

Why does an interface know about any implementations at all? It really shouldn't.

2. a client expecting a Vector2d implementation class gets a Vector2f instead!

Why would a client expect a specific implementation from a method that returns an interface type? It really shouldn't.

You seem deeply confused. I recommend further reading on the subject:

• In Effective Java by Joshua Bloch (in this order):

  • Item 19: Use interfaces only to define types
  • Item 17: Design and document for inheritance or else prohibit it
  • Item 18: Prefer interfaces to abstract classes
  • Item 16: Favor composition over inheritance

• Consider a related pattern used by java.util.Collections (source code), in particular the facilities provided by methods like .emptyList, .unmodifiableList, .synchronizedList

• Consider a related pattern used by java.util.EnumSet (source code), especially how its various factory methods create either RegularEnumSet or a JumboEnumSet depending on what is appropriate given the input params, and the client just doesn't need to know whatever is the actual implementation.