覆盖具体方法是否有代码气味？

重写具体方法是否确实有代码异味？因为我认为您需要重写具体方法：

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

不需要继承来覆盖该方法，是真的吗？

不，这不是代码的味道。

• 如果某个类不是最终的，则可以对其进行子类化。
• 如果方法不是最终方法，则可以覆盖该方法。

每个类都有责任仔细考虑子类是否合适，以及哪些方法可以被覆盖。

该类可以将自身或任何方法定义为final，也可以对其子类的生成方式和位置施加限制（可见性修饰符，可用的构造函数）。

覆盖方法的通常情况是基类中的默认实现，可以在子类中对其进行自定义或优化（尤其是在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背景，如果合同设计者希望不重写这些方法，则必须将这些方法显式标记为final。但是，在C＃等语言中，默认设置相反。方法是（没有任何修饰的特殊关键字）“ 密封的 ”（C＃的版本），并且必须明确声明为允许它们被覆盖。finalvirtual

如果已经使用可重写的具体方法为这些语言设计了API或库，则必须（至少在某些情况下）使其有意义。因此，覆盖未密封/虚拟/非final具体方法不是代码异味。     _{（当然，这是假定API的设计者遵循约定并将其设计的适当方法标记为virtual（C＃）或标记为final（Java）。）}

也可以看看

• 结构型系统
• 鸭打字
• 静态打字
• 强大的打字
• 里斯科夫替代原则

是的，因为它可以导致调用超级反模式。它还可以使方法的最初目的变性，引入副作用（=>错误）并使测试失败。您是否会使用单元测试为红色（失败）的类？我不会

我会进一步说，最初的代码味道是方法不是abstractnor时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();
    }
}