Чи переважають конкретні методи кодовим запахом?

Чи правда, що переважаючі конкретні методи - це кодовий запах? Тому що я думаю, якщо вам потрібно перекрити конкретні методи:

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, його можна переписати як:

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 # 's версія 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();
    }
}