【问题标题】:Is it anti-pattern?它是反模式吗?
【发布时间】:2012-06-22 18:40:38
【问题描述】:

我经常看到这样的代码:

public abstract class AbstractDataReader
{
    public void Read()
    {
        var reader = new StreamReader(FileName);
        ........
    }

    protected abstract string FileName
    {
        get;
    }
}

public class DataReader : AbstractDataReader
{
    protected override string FileName
    {
        get { return "data.txt"; }
    }
}

对我来说,它接缝为反模式,因为 DataReader 类没有逻辑,我不能使用AbstractDataReader 而不从它继承,我必须继承类只是为了指定参数而且我也很奇怪工作速度比只通过构造函数传递参数要慢。

但是我找不到这个反模式的名字。

有人知道吗?

【问题讨论】:

  • 这是C#代码,不是java,为什么是Java标签?
  • @Mauricio:Java 标记是由另一个用户编辑的,而不是由 OP 编辑​​的。我已将其回滚并将其正确地重新标记为 C#。
  • 正如我发布的那样,它没有被任何语言标记。但我认为这样的代码也可以用 Java 语言来处理。

标签: c# design-patterns inheritance anti-patterns


【解决方案1】:

是的,这是一种反模式。抽象类已经规定了派生类的工作方式,这里的类层次结构比单个类没有优势。

如果抽象类改为调用纯虚函数来获取StreamReader,那将是有意义的。然后不同的派生类可以附加到文件、网络流或动态生成的数据。

这里的反模式是“违反开闭原则”(SOLID的第二部分)。

【讨论】:

  • 本,继承总是违反开闭原则,因为子类不能完全保护基类不发生变化。但这不是称其为违规的理由。那么你能澄清一下危险的确切位置吗?
  • @Oleg:这不仅仅是“子类不受基类更改的保护”。它们不应该是,子类与基类强耦合。这里发生的情况是,基类使用通用编程技术(纯虚函数、虚拟分派)而没有增加任何灵活性。基类不能与任何非文件一起使用,因此抽象没有任何好处。
【解决方案2】:

是/否。

对我来说,这看起来像是一种抽象 setter 注入的尝试,我不确定这是一个好主意。它使事情变得不清楚并导致发布代码,但 setter 注入本身并不是反模式。

【讨论】:

    猜你喜欢
    • 2018-03-27
    • 2011-08-04
    • 2010-11-04
    • 2023-03-11
    • 2011-05-25
    • 2011-01-28
    • 1970-01-01
    相关资源
    最近更新 更多