Является ли обычной практикой использование аргументов в сигнатуре метода с единственной целью выполнения контракта

Question

Мне немного любопытно, какой код я видел в школе, и является ли это обычной практикой или просто плохим дизайном.

Рассмотрим следующий интерфейс и два класса, которыереализовать его ...

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

    public abstract double y(double y);
}

Обратите внимание, что в классе Cycle аргументы в x () и y () фактически используются ...

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;
    }
}

Но здесь, вкласс Center, аргументы в x () и y () существуют исключительно для выполнения контакта с интерфейсом Anchor и фактически не используются в методе ...

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; }
}

Это то, что вы часто будете видеть в рабочем коде Java?Это общепринятая практика или плохая работа?

Answer 1

Да, это очень распространено для всего кода ООП.

Интерфейс определяет набор методов, доступных для любых объектов, которые реализуют этот интерфейс. Реализация этих методов - это то, что не должно заботить вызывающую сторону, и совсем не необычно, что некоторые аргументы, видимые в интерфейсе, не применяются к определенным реализациям.

Answer 2

Чтобы добавить к 2 постам выше, я хотел бы отметить следующее.

1. Использование абстрактного ключевого слова в объявлении интерфейса считается очень плохой практикой, поскольку считается устаревшим, поскольку интерфейс неявно считается абстрактным.

2. Использование абстрактного ключевого слова в объявлении метода в интерфейсе считается крайне плохой практикой по той же причине, что указана в пункте 1 выше. Объявления методов неявно абстрактны.

3. Использование ключевого слова Public в объявлении метода также считается очень плохой практикой по той же причине, поскольку методы, объявленные в interface, неявно являются публичными.

4. Методы в интерфейсе не могут быть статическими, так как статические методы не могут быть абстрактными.

Answer 3

Хотя adpalumbo правильно, что это не необычная ситуация, это также может указывать на проблему проектирования, особенно если у вас длинный список параметров, и каждая реализация использует другой.Например,

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.

Мне нравятся вафли, но это просто противно.

Реальный вопрос заключается в том, имеют ли смысл аргументы, взятые в целом, в контексте того, что должен предполагать интерфейс.представлять.