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

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开发者_如何学Go 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?

---

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.

---

While adpalumbo is correct that it's not an unusual situation, it can also be indicative of a design problem, particularly if you have a long list of parameters and each implementation uses a different one. E.g.

interface Waffle {
    void iron(int a, int b, int c, int d, int e);
}

class Belgian implements Waffle {
    void iron(int a, int b, int c, int d, int e) {
        doSomethingWith(a);
    }
}

class American implements Waffle {
    void iron(int a, int b, int c, int d, int e) {
        doSomethingElseWith(b);
    }
}

class Scandinavian implements Waffle {
    void iron(int a, int b, int c, int d, int e) {
        andYetAgainWith(c);
    }
}

// etc.

I like waffles, but that's just nasty.

The real question is whether the arguments, taken as a whole, make sense in the context of whatever the interface is supposed to represent.

---

To add in to 2 posts above, I would like to point out following.

1. The use of abstract keyword in interface declaration is considered very bad practice as this is considered obsolete, because the interface is considered abstract implicitly.

2. The use of abstract keyword in method declaration in the interface is considered extremely bad practice for the same reason as pointed in point 1 above. Methods declarations are implicitly abstract.

3. The use of Public keyword in method declaration is also considered very bad practice for the same reason, as methods declared in interface are implicitly public.

4. The methods in interface can not be static as static methods can't be abstract.