Является ли переопределение конкретных методов запахом кода?

Правда ли, что переопределение конкретных методов - это запах кода? Потому что я думаю, что если вам нужно переопределить конкретные методы:

public class A{
    public void a(){
    }
}

public class B extends A{
    @Override
    public void a(){
    }
}

это можно переписать как

public interface A{
    public void a();
}

public class ConcreteA implements A{
    public void a();
}

public class B implements A{
    public void a(){
    }
}

и если B хочет повторно использовать a () в A, его можно переписать как:

public class B implements A{
    public ConcreteA concreteA;
    public void a(){
        concreteA.a();
    }
}

который не требует наследования для переопределения метода, это правда?

Нет, это не кодовый запах.

• Если класс не является окончательным, он позволяет разделить его на подклассы.
• Если метод не является окончательным, он позволяет быть переопределенным.

В обязанности каждого класса входит тщательное рассмотрение вопроса о том, подходит ли подкласс и какие методы могут быть переопределены .

Класс может определять себя или любой метод как конечный или может накладывать ограничения (модификаторы видимости, доступные конструкторы) на то, как и где он находится в подклассе.

Обычным случаем переопределения методов является реализация по умолчанию в базовом классе, которая может быть настроена или оптимизирована в подклассе (особенно в Java 8 с появлением методов по умолчанию в интерфейсах).

class A {
    public String getDescription(Element e) {
        // return default description for element
    }
}

class B extends A {
    public String getDescription(Element e) {
        // return customized description for element
    }
}

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

interface DescriptionProvider {
    String getDescription(Element e);
}

class A {
    private DescriptionProvider provider=new DefaultDescriptionProvider();

    public final String getDescription(Element e) {
       return provider.getDescription(e);
    }

    public final void setDescriptionProvider(@NotNull DescriptionProvider provider) {
        this.provider=provider;
    }
}

class B extends A {
    public B() {
        setDescriptionProvider(new CustomDescriptionProvider());
    }
}

Правда ли, что переопределение конкретных методов - это запах кода?

Да, в общем, переопределение конкретных методов - это запах кода.

Поскольку с базовым методом связано поведение, которое разработчики обычно уважают, его изменение приведет к ошибкам, когда ваша реализация сделает что-то другое. Хуже того, если они изменят поведение, ваша ранее правильная реализация может усугубить проблему. И вообще, довольно сложно соблюдать принцип подстановки Лискова для нетривиальных конкретных методов.

Теперь есть случаи, когда это можно сделать, и это хорошо. Полу-тривиальные методы могут быть безопасно переопределены. Базовые методы, которые существуют только как «нормальный» тип поведения, предназначенный для переопределения, имеют хорошее применение.

Следовательно, мне это кажется запахом - иногда хорошим, обычно плохим, посмотрите, чтобы убедиться.

если вам нужно переопределить конкретные методы [...], его можно переписать как

Если это можно переписать таким образом, это означает, что у вас есть контроль над обоими классами. Но затем вы знаете, разработали ли вы класс A таким образом, и если вы это сделали, то это не запах кода.

Если, с другой стороны, у вас нет контроля над базовым классом, вы не можете переписать его таким образом. Таким образом, либо класс был разработан таким образом, чтобы его можно было выводить, и в этом случае просто вперёд, это не запах кода, или это не так, и в этом случае у вас есть два варианта: искать другое решение вообще или продолжать в любом случае , потому что рабочие бьют дизайнерскую чистоту.

Во-первых, позвольте мне отметить, что этот вопрос применим только в определенных системах ввода. Например, в системах структурной типизации и типизации Duck - класс, имеющий просто метод с тем же именем и сигнатурой, будет означать, что класс совместим по типу (по крайней мере, для этого конкретного метода, в случае типизации Duck).

Это (очевидно) очень отличается от области статически типизированных языков, таких как Java, C ++ и т. Д. А также от природы строгой типизации , используемой как в Java и C ++, так и в C # и других.

Я предполагаю, что вы пришли из Java-фона, где методы должны быть явно помечены как окончательные, если разработчик контракта намеревается их не переопределить. Однако в таких языках, как C #, по умолчанию используется обратное. Методы (без каких-либо декораций, специальных ключевых слов) « запечатаны » (версия C # final) и должны быть явно объявлены так, как virtualесли бы им было разрешено переопределять.

Если API или библиотека были разработаны на этих языках с конкретным методом, который можно переопределить, то он должен (по крайней мере, в некоторых случаях) иметь смысл для его переопределения. Следовательно, не является запахом кода переопределение незапечатанного / виртуального / не finalконкретного метода.     _{(Это предполагает, конечно, что разработчики API следуют соглашениям и либо помечают как virtual(C #), либо помечают как final(Java) подходящие методы для того, что они проектируют.)}

Смотрите также

• Структурная система типов
• Утка печатать
• Статическая печать
• Строгая типизация
• Принцип подстановки Лискова

Да, это потому, что это может вызвать супер -паттерн. Он также может денатурировать начальную цель метода, вводить побочные эффекты (=> ошибки) и делать тесты неудачными. Вы бы использовали класс с юнит-тестами красного цвета (с ошибками)? Я не буду

Я пойду еще дальше, сказав, что первоначальный запах кода - это когда метод не является ни тем, abstractни другим final. Потому что это позволяет изменить (переопределив) поведение созданного объекта (это поведение может быть потеряно или изменено). С abstractи finalнамерение однозначно:

• Аннотация: вы должны представить поведение
• Финал: вам не разрешено изменять поведение

Самый безопасный способ добавить поведение в существующий класс - это то, что показывает ваш последний пример: использование шаблона декоратора.

public interface A{
    void a();
}

public final class ConcreteA implements A{
    public void a() {
        ...
    }
}

public final class B implements A{
    private final ConcreteA concreteA;
    public void a(){
        //Additionnal behaviour
        concreteA.a();
    }
}