将设计模式名称嵌入接口名称是否很好？

Question

将设计模式名称嵌入到适当的界面中是不错的做法/风格让我们说如果它的装饰器设计模式将抽象装饰器命名为IDecorateInterfaceName或AbstractClassNameDecorator，如果抽象类用于图案。例如，java I / O类使用装饰器模式，但只是将Abstract Decorator类命名为FilterInputStream，而不是在名称中的某处添加模式名称。或者，如果提供足够的文档，添加此类信息会变得多余吗？在我看来，只要通过查看代码就可以更容易地了解使用哪些模式，如果遵循这一惯例，那么API不遵循这样的规则会让我失望。

Answer 1

幸运的是语言设计师为我们提供了一些见解

• Java naming guidelines
• C# Naming guidelines

在命名类，方法和变量时 - 你的首要目标应该是提高可读性（从而向读者传达你的代码实际上在做什么）。在你的装饰模式的例子中，在类的名称中包含'AbstractDecorator'是不相关的，因为这不会告诉任何人实际上做什么。

这实际上是个案基础的事情 - 例如在许多MVC框架中，为每个作为Controller的类（根据该设计模式）添加“Controller”后缀是常见的惯例。在这种情况下，将名称设计模式添加到帮助用户了解对象正在做什么。

如果有疑问，请问问自己“这会让我的代码更容易阅读和理解吗？”

Answer 2

恕我直言，知道使用哪种模式并不重要。重要的是班级是什么和做什么。 FilterInputStream清楚地说明了这一点。它实现装饰器模式的事实是一个实现细节，如果你知道模式就很容易识别，如果你不知道它就不会添加很多信息。

也就是说，一些模式名称清楚地描述了类是什么，如工厂或策略，因此它们经常被用作类名的一部分。例如，SecretKeyFactory是用于密钥的工厂，并实现工厂模式。但我不喜欢有像RuntimeSingleton或FileFilterStrategy这样的类。这些后缀是噪音。

BTW，我也讨厌接口的C＃的I前缀约定。这种噪声使得代码的可读性降低，并且不会添加有意义的信息。

Answer 3

如果您希望将装饰器暴露给另一个应用程序，可以使用接口，例如，基于WCF架构的开发必须是实现接口。

Answer 4

在“清洁代码”一书的“有意义名称”第2章的“使用解决方案域名”部分中，Robert Martin说：

  

请记住，阅读代码的人将是程序员。去啊   提前使用计算机科学（CS）术语，算法名称，模式   名称，数学术语等。

     

名称“AccountVisitor”对程序员来说意义重大   熟悉VISITOR模式。什么程序员不知道什么   一个“JobQueue”是？有很多非常技术性的东西   程序员必须这样做。为这些东西选择技术名称是   通常是最合适的课程。