在过去的一年中,我的团队代码基础上有一些工作,我注意到命名约定的稳步发展.
例如,有很多类被命名为表达它们是一个可以帮助你做某事的类.
这是我发现的:
MyClassUtil MyClassFactory MyClassHelper MyClassManager MyClassService
在我看来,随着时间的推移,人们会为相对相同的事情提出命名约定,因此您不必以一致的方式命名所有内容,而是使用具有一些约定的代码库.所有新东西都是根据最新的时尚命名惯例命名的,所以你几乎可以通过当时流行的惯例告诉一些代码的时代.
处理这种趋势的最佳方法是什么?这真的是个问题吗?随着这些命名时尚流行,人们应该使用最新的时尚吗?是否应该使用新的命名约定重命名所有现有项目?或者,人们应该接受这种多样性作为不可避免的东西?
它们看起来并不像时尚......所有这些名字暗示了这个阶级的目的,而且这些目的是不同的.通过编程,这一切都在名称中,应该非常谨慎地选择它们.品种不需要逃脱.名称各不相同,因为课程的目的各不相同.
MyClassUtil - 用于处理MyClass的一些实用程序,它没有附带.也许MyClass属于你正在使用的库,但你经常使用它的一些更高级别的函数,你需要在某个地方放置它们.
MyClassFactory 以抽象的方式创建MyClass的实例.这允许您编写需要MyClass实例的代码.它可以从MyClassFactory获取这些新实例.这将允许工厂在将来修改以提供MyClass的不同特定实现.也许在单元测试下,工厂只提供虚拟/模拟MyClasses.这意味着可以在不需要更改工厂的情况下测试使用工厂的类,只需更改工厂,并且可以隔离正在测试的类.
MyClassHelper -Ok ,我可能同意,也许这可能更具体.它可以帮助MyClass,但是什么.也许这有点类似于MyClassUtil.但是,可能MyClassUtil是与MyClass一起使用的通用函数,而帮助器是使用MyClass的特定实例初始化的,然后可以对该一个实例执行操作.您需要为每个想要帮助的MyClass提供一个新助手.
MyClassManager -Maybe它处理MyClass实例池并存储或编排它们.例如.在CommunicationsManager中,该类将处理与处理端口或连接(如以太网或串行)的类连接的类,以及处理通过它发送的通信协议的类,以便它可以传输数据包,以及处理这些数据包中的消息.
MyClassService -A服务可以为您做一些事情,就像给定邮政编码将其转换为网格引用一样.通常,服务可以解决许多特定事物.使用邮政编码示例,此类可能具有可与不同网站通信以进行转换的实现.