将设计模式名称嵌入到适当的界面中是否是一种好的做法/风格，如果它的装饰器设计模式具有抽象装饰器命名为IDecorateInterfaceName 或AbstractClassNameDecorator，如果抽象类用于该模式。例如，java I/O 类使用装饰器模式，但将抽象装饰器类命名为 FilterInputStream，而不是在名称中的某处添加模式名称。或者如果提供了足够的文档，添加此类信息是否会变得多余？在我看来，如果始终遵循此约定，则仅通过查看代码就更容易了解使用了哪些模式，但 API 没有遵循这样的规则这一事实让我大吃一惊。
【问题讨论】：
标签： design-patterns coding-style
幸运的是语言设计者为我们提供了一些见解
在命名您的类、方法和变量时，您的第一个目标应该始终是提高可读性（从而向代码的读者传达实际执行的操作）。在您的装饰器模式示例中，在类的名称中包含“AbstractDecorator”是不相关的，因为这并不能告诉任何人对象实际上做了什么。
不过，这实际上是逐案处理的——例如，在许多 MVC 框架中，为每个作为控制器的类添加“控制器”后缀是常见的约定（根据该设计模式）。在这种情况下，添加设计模式来命名有助于用户了解对象在做什么。
如有疑问，只需问自己一个问题“这会让我的代码更易于阅读和理解吗？”
【讨论】：
恕我直言，知道使用哪种模式并不重要。重要的是班级是什么，做什么。 FilterInputStream 说得很清楚。它实现装饰器模式的事实是一个实现细节，如果您知道该模式，则很容易识别，如果您不知道，则不会添加太多信息。
也就是说，一些模式名称清楚地描述了类是什么，例如工厂或策略，因此它们通常用作类名称的一部分。例如，SecretKeyFactory 是密钥的工厂，并实现了工厂模式。但我不希望有像 RuntimeSingleton 或 FileFilterStrategy 这样的类。这些后缀是噪音。
顺便说一句，我也讨厌 C# 接口的 I 前缀约定。正是这种噪音会降低代码的可读性并且不会添加有意义的信息。
【讨论】：
I前缀就像我喜欢以大写字母开头的类一样多（也就是说，很多）。
如果您希望将您的装饰器暴露给另一个应用程序，您可以使用接口，例如您基于 WCF 架构的开发 n 层必须是实现接口。
【讨论】：
在“清洁代码”一书“有意义的名称”第 2 章的“使用解决方案域名”部分中，罗伯特·马丁说：
请记住，阅读您的代码的人将是程序员。去啊 提前并使用计算机科学 (CS) 术语、算法名称、模式 名称、数学术语等。
“AccountVisitor”这个名字对于程序员来说意义重大 熟悉 VISITOR 模式。什么程序员不知道什么 一个“JobQueue”是什么？有很多非常技术性的东西 程序员要做的。为这些东西选择技术名称是 通常是最合适的课程。
【讨论】：