Is it common practice to have args in a method signature for the sole purpose of fulfilling a contract

Question

I'm a little curious about some of the code that I saw at school and whether or not this is common practice in the field or just bad design.

Consider the following interface and the two classes that implement it...

public abstract interface Anchor
{
    public abstract double x(double x);

    public abstract double y(double y);
}

Notice in the Cycle class the arguments in x() and y() are actually used...

public class Cycle implements Anchor
{
    public Anchor anchor;
    public double radius;
    public double period;
    public double phase = 4.0D;

    public Cycle(Anchor anchor, double radius, double period) {
        this.anchor = anchor;
        this.radius = radius;
        this.period = period;
    }

    public double angle(double day) {
        return this.phase * 3.141592653589793D * (day / this.period) / 2.0D;
    }

    public double x(double x) {
        return this.anchor.x(x) + Math.cos(angle(x)) * this.radius;
    }

    public double y(double y) {
        return this.anchor.y(y) + Math.sin(angle(x)) * this.radius;
    }
}

But here in the Center class the arguments in x() and y() exist solely to fulfill the contact with the Anchor interface and aren't actually used in the method...

public class Center implements Anchor
{
    public double x;
    public double y;

    public Center(double x, double y) {
        this.x = x;
        this.y = y;
    }

    public double x(double x) { return this.x; }
    public double y(double y) { return this.y; }
}

Is this something that you'll see commonly in production java code? Is it an accepted practice or a bad work around?

Answer 1

Yes, this is very common to all OOP code.

An interface defines a set of methods that are available on any objects that implement that interface. The implementation of those methods is something that a caller isn't supposed to care about, and it's not at all unusual that some arguments seen in an interface don't apply to certain implementations.