我应该避免使用常用的类名吗？

问题描述

某些类名是如此“通用”，以至于它们经常在几个不同的包中找到，包括库和应用程序代码。一些例子：

• 评论
• 组件
• 工厂
• 位置
• 地区

在我的IDE中，尝试自动完成此类中的一个这样的类的导入会发出一些相互竞争的建议。

在命名类时，最好避免使用已在其他地方使用的类名？

对于其中的一些示例，我会认为不建议使用此类名称，因为它根本不够有意义（例如Factory），但是我想知道是否不建议使用类别名称​​，因为（经常）在其他地方使用。

解决方法

注释，区域和位置似乎不错。就个人而言，从主观上讲，Component和Factory绝对太普遍而无法使用，但客观上我不认为任何不使用它们作为名称的常规原因。例如，我肯定会尝试将这些名称与它们各自的用法结合起来； TaskFactory，WidgetComponent，ButtonFactory等。

,

您应该使用对您来说最有意义的类名称。上面提到的名称中没有一个超出限制，也没有理由不使用它们（假设一种语言支持名称空间，并且可以避免以此方式命名冲突）。

但是，您可以考虑向下钻取更具体和精确的类名，这将更好地描述代码中对象的含义。例如：

• 代替 Comment ： LineComment 或 BreakComment 可以很容易地成为您要在其中创建注释语义块的编译器项目中的类名。 。
在实施UI库时，
• 代替 Component ： ListComponent ， CalendarComponent 或 ViewComponent 特别有意义。您有基于类的组件。
• 如果您想制作比萨饼，那么 PizzaFactory 会更有意义，而不是 Factory ！
在实现基于路线的导航应用程序时，
• 代替 Location ： GeographicLocation 或 SemanticLocation 更有意义，并且您试图区分“北纬45度，西经77度”和“在披萨店旁边”。
• Region ： CodeRegion 可以在编译器中使用， GeographicRegion 可以在Maps应用中使用。

如果您不敢说具体，可以使用名称空间和程序包。但是，没有什么可以阻止您使用与另一个软件包相同的名称的类。具体来说，这些类名称没有版权，并且现在大多数IDE都足够聪明，可以在使用自动补全功能时区分要引用的包。

在大多数情况下，专用性有助于其他开发人员阅读您的代码，每个开发人员都可以欣赏！！

,

取决于我们是在谈论业务还是技术部分。

在技术方面：使用公用名实际上是一种让其他人知道所使用的模式的方法，Factory是一个很好的例子-当您看到一个名为SomethingFactory的类时，您会期望Factory Pattern.可以扩展到框架，库等。-SomethingAutoConfiguration使用Spring-Boot，SomethingEntity使用JPA，我认为使用前端框架（React，Angular）Component是真的很普通。因此，只要正确使用它们，就一定可以使用它们。

在业务部分：很简单，如果这些词描述了您的业务领域，则一定要使用它们。不要仅仅因为单词看起来很普通而发明一些奇特的名字（或词库！），这是您的业务领域-是神圣的。