2

Whats 是我的静态类的理想类名，它有一些静态方法来处理通用/通用功能，例如备份、保存最近的项目 etxc .. (Infact Misc items) 在 C# 中。我想将 Manager 作为类名的后缀（例如：SaleManager（处理与销售相关的功能），ContatManager（处理与联系相关的功能）

4

10 回答 10

28

重构MeManager。

于 2009-11-03T07:01:08.073 回答
11

以下是一些执行这些类型操作的 .NET Framework 类：

  • 系统.环境
  • 系统数学
  • System.IO.文件
  • System.IO.目录
  • 系统.IO.路径
  • System.Runtime.InteropServices.Marshal

如您所见，例程按主题分组到类中，并且没有一个类附加了“Helper”或“Utilities”。以下是我制作的一些执行这些类型的事情的类：

  • SymbolicMath（类似于 Math 类，但用于处理符号数学表达式）
  • BigIntegerMath（使用 System.Numerics.BigInteger 类型的大整数算术库 - 素数证明、因式分解和其他一些东西）
于 2009-11-03T07:12:27.207 回答
4

事实证明，“Utility”是有争议的，而“Math”则没有。所以看起来这个名字应该暗示静态类中方法的整体功能。

于 2009-11-03T06:58:18.203 回答
3

如果您有一个具有大量静态方法的 Utility（或 UtilityManager）类，那确实是一种反模式，应该立即重构。

但是，有些东西就是这样 - 实用程序，人们不应该避免将它们放在单独的实用程序类中（我个人最喜欢的）。是的，这为各种丑陋的场景打开了大门，一个人必须掌握缰绳，否则任何事情都会结束，是的，需要将方法“提升”到他们自己的类（通常是 XXXHelper）如果需要，但是，尽管如此，我发现 Utilities 类是一个有用的构造，而不是它本身的反模式。模式毕竟是一种建议，它们不是一种宗教:)

Manager 作为此类类的后缀是令人困惑的，因为该类实际上不管理任何东西。

于 2009-11-03T07:57:52.577 回答
3

万岁internal static class Utils。

于 2010-07-10T11:40:18.997 回答
2

我的总体感觉是，一个人不应该有这样一门普通的课。尤其是电子邮件很可能扩展到不仅仅是一个 SendEmail() 方法，而且坦率地说new Email({to, subject, body}).Send()，它更具有 OO 意义。

于 2009-11-03T06:59:19.760 回答
1

Tools
Utils
Extensions（如果您只在其中放置扩展方法（C#））

于 2009-11-03T08:03:36.700 回答
0

实用程序管理器..？

于 2009-11-03T06:56:24.027 回答
0

有很好的理由不做那种事情。它被认为是一种反模式。

于 2009-11-03T07:00:07.530 回答
0

即使对于静态类（顺便说一句：我更喜欢 XxxHelper 后缀），我也会坚持“关注点分离”范式，并且不会在一个类中混合不同的实用程序。

于 2009-11-03T07:01:38.400 回答