【发布时间】:2010-12-12 13:07:54
【问题描述】:
Whats 是我的静态类的理想类名,它有一些静态方法来处理通用/通用功能,例如备份、保存最近的项目 etxc .. (Infact Misc items) 在 C# 中。我想将 Manager 作为类名的后缀(例如:SaleManager(处理与销售相关的功能),ContatManager(处理与联系相关的功能)
【问题讨论】:
标签: c# naming-conventions classname
Whats 是我的静态类的理想类名,它有一些静态方法来处理通用/通用功能,例如备份、保存最近的项目 etxc .. (Infact Misc items) 在 C# 中。我想将 Manager 作为类名的后缀(例如:SaleManager(处理与销售相关的功能),ContatManager(处理与联系相关的功能)
【问题讨论】:
标签: c# naming-conventions classname
实用程序管理器..?
【讨论】:
事实证明,“Utility”是有争议的,而“Math”则没有。因此,该名称似乎应该暗示静态类中方法的整体功能。
【讨论】:
我的总体感觉是不应该有这样一个普通的课程。尤其是电子邮件很可能扩展到不仅仅是一个 SendEmail() 方法,坦率地说,new Email({to, subject, body}).Send() 更有意义。
【讨论】:
有very good reasons不做那种事。它被认为是一种反模式。
【讨论】:
RefactorMeManager。
【讨论】:
即使对于静态类(顺便说一句:我更喜欢 XxxHelper 后缀),我也会坚持范式“Separation of Concerns”,并且不会在一个类中混合不同的实用程序。
【讨论】:
以下是一些执行这些类型操作的 .NET Framework 类:
如您所见,例程按主题分组到类中,并且没有一个类附加了“Helper”或“Utilities”。以下是我创建的一些执行这些类型的事情的类:
【讨论】:
如果您的 Utility(或 UtilityManager)类包含大量静态方法,那确实是一种反模式,应该立即重构。
但是,有些东西就是实用程序,我们不应避免将它们放在单独的 实用程序 类中(我个人最喜欢的)。是的,这为各种丑陋的场景打开了大门,一个人必须掌握缰绳,否则任何事情都会结束,是的,需要将方法“提升”到他们自己的类(通常是 XXXHelper)如果需要,但是,尽管如此,我发现 Utilities 类是一个有用的构造,而不是它本身的反模式。模式毕竟是一种建议,它们不是一种宗教:)
Manager 作为此类类的后缀令人困惑,因为该类实际上不管理任何东西。
【讨论】:
工具
实用工具
扩展(如果您只在其中放置扩展方法(C#))
【讨论】:
万岁internal static class Utils。
【讨论】: