杂项功能的静态类的理想类名
什么是我的静态类的理想类名，它有一些静态方法来处理常规/通用功能，例如备份、保存最近的项目等。（事实上，杂项项目）在 C# 中。我希望 Manager 作为类名的后缀（例如：SaleManager（处理销售相关功能），ContatManager（处理联系人相关功能）
Whats is the ideal class name for my static class which has some static methods to handle General/Common functionalities iike taking backup,saving recent items etxc.. (Infact Misc items ) in C#. I would like to have Manager as suffix of the class name (ex: SaleManager(to handle sales related functionalities),ContatManager(to handle contact related functionality)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
重构MeManager。
RefactorMeManager.
以下是执行这些类型操作的一些 .NET Framework 类：
如您所见，例程是按主题分组为类，并且没有一个类附加“Helper”或“Utilities”。以下是我制作的一些类，它们执行其中一些类型的操作：
Here are some .NET Framework classes that perform these types of operations:
As you can see, the routines are grouped by topic into classes, and none of the classes have "Helper" or "Utilities" appended. Here are some classes I've made that perform some of these types of things:
事实证明，“效用”是有争议的，而“数学”则没有。因此，这个名称似乎应该表明静态类中方法的整体功能。
It turns out that "Utility" is controversial, while "Math" is not. So it would seem that the name should suggest the overall functionality of the methods in the static class.
如果您有一个包含大量静态方法的 Utility（或 UtilityManager）类，那么这确实是一种反模式，应该立即重构。
然而，有些东西就是这样的——实用程序，人们不应该把它们放在一个单独的实用程序类中（我个人最喜欢的）。是的，这为各种丑陋的场景打开了大门，一个人必须掌控一切，否则任何事情都会最终在那里，是的，需要将方法“提升”到他们自己的类（通常是 XXXHelper）如果需要的话，但是，尽管如此，我发现 Utilities 类是一个有用的构造，而不是其本身的反模式。模式毕竟是一种建议，它们不是一种宗教:)
Manager 作为此类类的后缀会令人困惑，因为该类实际上不管理任何东西。
If you have a Utility (or UtilityManager) class that has lots and lots of static methods, that is indeed an anti-pattern and should be refactored pronto.
However, there are the things that are just that - utilities, and one should not refrain from putting them in a separate Utilities class (my personal favourite). Yes, that opens the door for all sorts of ugly scenarios, and one has to hold the reins, or anything and everything will end up there, and yes, there is a need to "promote" methods to their own class (usually XXXHelper) if the need arises, but, nonetheless, I find the Utilities class a helpful construct, and not an anti-pattern by itself. Patterns are a recommendation after all, they are not a religion :)
Manager as a suffix for that kind of a class is confusing, because the class does not in fact manage anything.
内部静态类 Utils 万岁。
Long live
internal static class Utils.我总的感觉是不应该上这么一般的课。特别是电子邮件，很可能扩展到不仅仅是 SendEmail() 方法，而且坦率地说，new Email({to, subject, body}).Send() 更具有面向对象的意义。
My general feeling is that one should not have such a general class. Email in particular is quite likely to expand to more than just a SendEmail() method and frankly
new Email({to, subject, body}).Send()makes a lot more OO sense.实用程序管理器..？
UtilityManager..?
工具
实用工具
扩展（如果您只在其中放置扩展方法 (C#)）
Tools
Utils
Extensions (if you put just extension methods in there (C#))
有
There are very good reasons not to do that kind of thing. It is considered an anti-pattern.
即使对于静态类（顺便说一句：我更喜欢 XxxHelper 后缀），我也会坚持“关注点分离范例”并且不会在一个类中混合不同的实用程序。
Even for static classes (btw: I prefer the XxxHelper suffix) I'd stick to the paradigm "Separation of Concerns" and would not mix different utilities in one class.