在实现类中使用设计模式名称是个好主意吗？[关闭]

最近我碰到有大量的中等大蟒蛇的代码库来了MyClassAbstractFactory，MyClassManager，MyClassProxy，MyClassAdapter等类。

一方面，这些名称指示我研究和学习相应的模式，但它们并不能很好地描述班级的工作方式。

此外，他们似乎落在单词的列表禁止内编程：variable，process_available_information，data，amount，compute：过于宽泛的名字，不给我们介绍一下什么功能不能单独使用。

那么应该存在CommunicationManager还是宁愿PortListener？或者，也许我根本不理解问题...？

• AbstractFactory确实是一个糟糕的名字选择。有没有办法知道什么是此工厂创建的，而当你再找找它创建一个实体Animal公司，您永远也找不到的名字对应的工厂。

• AnimalAbstractFactory也不是明智的选择，因为在大多数语言中，签名中的关键字将是多余abstract的。

  话虽这么说，但有很多很好的理由（以注释突出显示）确实包含Abstract在名称中：不仅在几个上下文中您没有完整的签名，而且还只有名称，而且还要保留AnimalFactory接口可能是一个明智的选择（除非，不幸的是，语言/框架的约定是将前缀为I）。

• AnimalCreationUtility这也是一个不好的选择：如果这是工厂，则使那些将要阅读代码并将其称为工厂的人变得更容易。

• abstract AnimalFactory还可以 它没有冗余，很明显，它是一个抽象工厂，将动物的创作委托给它的子代。

所以是的，包括设计模式的名称是一个好主意，但是它应该只是名称的一部分，而不应该与签名的其他部分重复。

取决于具体示例。命名类* Builder几乎总是可以最好地使用Builder模式，而Singleton通常不需要这样命名。

如果您没有在类名中添加模式名称，即使您这样做，通常也应该在类中添加注释，以说明它实现了特定的模式。

在类中使用模式名称的全部目的是使您易于理解该类的功能。如果您将类命名为AnimalFactory，则很明显该类将创建Animal实例。如果您的类的名称包含模式的名称，并且没有描述它的作用，则说明您选择了错误的模式或错误地实现了该模式。

我认为它可以很好地工作。例如：

// Command for retrying card entry with CVN.
public class RetryCardEntryWithCVNCommand { ... }

// Query for getting expired accounts
public class GetExpiredAccountsQuery { ... }

// Decorator for logging exception. Implies that it's an additional 
//mechanism for logging exceptions.
public class LogExceptionToDbDecorator { ... }

// Factory for creating account filters
public class AccountFilterFactory { ... }