class-design - 要避免的类(代码完整)

Question

我对代码完整书中的一段话有些困惑。

在“要避免的类”部分中，内容如下:

“避免以动词命名的类只有行为但没有数据的类通常不是真正的类。考虑将 DatabaseInitialization() 或 StringBuilder() 等类转变为其他类上的例程”

我的代码主要由动词类组成​​，没有数据。有发票阅读器、价格计算器、消息生成器等。我这样做是为了将类(class)集中到每个任务上。然后，我将依赖项添加到其他类以实现其他功能。

如果我正确理解该段落，我应该使用类似的代码

class Webservice : IInvoiceReader, IArticleReader {
    public IList<Invoice> GetInvoices();
    public IList<Article> GetArticles();
}

而不是

class InvoiceReader : IInvoiceReader {
    public InvoiceReader(IDataProvider dataProvider);
    public IList<Invoice> GetInvoices();
}

class ArticleReader : IArticleReader {
    public ArticleReader(IDataProvider dataProvider);
    public IList<Article> GetArticles();
}

编辑感谢大家的回复。

我的结论是，我当前的代码比 OO 更多的是 SRP，但它也受到“贫乏域模型”的影响。

我确信这些见解会对我将来有所帮助。

Answer 1

像 InvoiceReader、PriceCalculator、MessageBuilder、ArticleReader、InvoiceReader 这样的类名实际上并不是动词名称。它们实际上是“名词代理-名词”类名。请参阅agent nouns .

动词类名类似于 Validate、Operate、Manage 等。显然，这些更适合用作方法，但用作类名会很尴尬。

“名词代理名词”类名的最大问题是，它们对于类的实际用途几乎没有什么意义(例如 UserManager、DataProcessor 等)。结果，他们更有可能变得臃肿并失去内部凝聚力。 (参见Single Responsibility Principle)。

因此，具有 IInvoiceReader 和 IArticleReader 接口(interface)的 WebService 类可能是更清晰、更有意义的 OO 设计。

这为您提供了简单、明显的名词类名称“WebService”，以及“名词代理名词”接口(interface)名称，这些名称清楚地宣传了 WebService 类可以为调用者做什么。

您还可以通过在另一个名词前面添加前缀来赋予实际类更多含义，例如 PaymentWebService。

然而，在更具体地描述类可以为调用者做什么方面，接口(interface)总是比单个类名更好。随着类变得越来越复杂，新的接口(interface)也可以添加有意义的名称。