不要在C＃中使用“静态”？

我提交了我写给其他一些架构师的应用程序，以供代码审查。其中一个几乎立即写信给我，说：“不要使用“静态”。您不能使用静态类和方法编写自动测试。要避免使用“静态”。

我检查了一下，并将全部1/4的班级标记为“静态”。当我不打算创建类的实例时，我会使用static，因为该类是整个代码中使用的单个全局类。

他继续提到了涉及模拟，IOC / DI技术的一些静态代码无法使用的技术。他说，由于第三方库不可测试，当第三方库为静态库时很不幸。

这个建筑师是正确的吗？

更新：这是一个示例：

APIManager-此类保留我正在调用的第三方API的字典以及下一个允许的时间。它强制执行许多第三方在其服务条款中规定的API使用限制。我可以通过调用Thread.Sleep（APIManager.GetWait（“ ProviderXYZ”））在调用第三方服务的任何地方使用它；在拨打电话之前。这里的所有内容都是线程安全的，并且与C＃中的TPL一起使用时效果很好。

这取决于静态类是否保持状态。就我个人而言，在静态类中将无状态函数组合在一起我没有问题。

他对此太笼统了。他是正确的，这阻碍了测试。但是，static类和方法有其位置，它实际上取决于上下文。没有代码示例，您将无法真正分辨。

当我不打算创建类的实例时，我会使用static，因为该类是整个代码中使用的单个全局类。

这可能是严重的代码异味。您将这些课程用于什么？要保存数据？要访问数据库？那他是正确的。在这种情况下，您应该考虑依赖注入，因为这样的静态类实际上是隐式单例。

如果将它们用于扩展方法或辅助程序，而这些方法或辅助程序不更改状态，而仅对提供的​​参数进行操作，则通常可以。

我检查了一下，并将全部1/4的班级标记为“静态”。当我不打算创建类的实例时，我会使用static，因为该类是整个代码中使用的单个全局类。

最好的办法是尝试对代码进行单元测试。尝试设计可重复，独立，简单的测试，一次只测试一种方法。尝试以不同的随机顺序运行测试。您可以获得稳定的“绿色”建筑吗？

如果是，那是保护您的代码的正确点。但是，如果遇到困难，那么也许应该使用基于实例的方法。

已经发布的答案涵盖了很多非常好的要点，但是似乎缺少了一个要点：

静态字段永远不会被垃圾收集。

如果您的应用程序具有很多内存限制，那么这非常重要，当人们尝试实现缓存时，这种模式可能很常见。

静态函数几乎没有那么糟糕，但是其他人已经足够详细地介绍了这一点。

从IoC / DI获得的优点之一是，类之间的大多数交互都是在接口之间协商的。这使单元测试变得容易，因为可以自动或半自动模拟接口，因此可以测试每个部分的输入和输出。此外，除了可验证性之外，在所有内容之间放置接口还可以使您拥有尽可能模块化的代码-您可以轻松地替换一个实现，而不必担心担心搞砸了依赖性。

因为C＃没有元类，所以类不能使用静态功能实现接口，因此类的静态功能最终会花费很多精力来实现纯IoC / DI对象模型。就是说，您不能创建一个模拟来测试它们，而必须创建真正的依赖关系。

如果您的公司/项目在进行IoC方面投入了大量资金，那么这当然是一个合理的问题，而您正在经历的痛苦就是为了所有人的利益。但是，从体系结构的角度来看，我个人不认为应该遵循任何模型。使用静态方法可以实现一些有意义的事情，例如单例设计策略。我本人不太喜欢静态类，因为我认为它们倾向于开始失去OO的优点，但是有时候，库类可能比引擎更自然地表达某种东西。

Commenter让我想起了扩展方法，这些方法当然必须在C＃中的静态类中。这是合法的，并且是一个示例，说明纯IoC如何无法在C＃中很好地工作，至少在您尝试利用该语言的广度的情况下。

静态类有时会被滥用，应该是：

• 一个单例（非静态类具有一个静态成员和一个公共静态Instance变量，仅可检索/创建一次）。
• 另一个类中的方法（状态很重要）。如果您有一个成员，该成员不使用该类中的数据，则该成员可能不应该属于该类。

它也可能是所谓的“实用程序”功能，并且是实用程序类的一部分。实用程序类是仅包含静态方法的类，可充当没有任何上下文的辅助函数。

静态方法很好用，并且在编程中应有的地位。听起来您的架构师拥有一个不完全支持静态方法的测试框架。如果您的代码是更大项目的一部分，那么满足架构师指南很重要。但是，在适当的时候，不要让该项目阻止您使用静态方法。

我一直在使用静态属性来处理类的所有实例所共有的内容。而且我一直在使用静态方法来获取类对象组。我绝不是专家，但是到目前为止，这对我一直有效。

PHP示例：

class vendorData {
  private static $data_table = 'vendor_data'; // static property
  private $id; // instance property
  private $name; // instance property

  public function __construct($vendor_id) {
    if(!self::validId($vendor_id) ) { // static method
      return false; // id doesn't exist
    }
    $this->id = $vendor_id; // id has been validated
    $this->getProperties(); // object method
  }

  private static function validId($vendor_id) {
    // send db query to find if the id exists
    // return true/false;
  }

  private function getProperties() { // object method
    $sql = "SELECT * FROM `{self::$data_table}` // using static property
        WHERE `id` = {$this->id}"; // using object instance property
    // get resultset
    foreach($result as $property => $value) {
      $this->$property = $value; // object instance properties all set
    }
  }

  // and here
  public static function getBy($property,$value) { // static method to return object array
    $sql = "SELECT `id` FROM `{self::$data_table}` // using static property
      WHERE `$property` = '$value'";
    // send query, get $ids array
    $obj_array = array();
    foreach($ids as $id) {
      // create array of current class objects using special static keyword
      // meaning of static here is different than in property/method declarations
      $obj_array[$id] = new static($id);
    }
    return $obj_array;
  }
}

我会说他们有原则，但是声明（不要使用静态）可能是错误的。您的代码覆盖率是多少？如果数量很大，并且您对应用程序的单元测试感到满意，那么您就可以了。如果没有，那么我建议复查代码。您可能会发现静态类是否是原因，这取决于很多事情。

具有静态方法的类滥用OOP的原理。它还不是面向对象编程，而是COP-面向类的编程。

他们很少有明确的“个性”（我在这里用我最喜欢的人类比喻）或身份。所以他们不知道自己是谁。仅此一点就足以摆脱OOP中的这一概念，但是还有更多。

下一个是第一点的结果。由于此类人不知道自己是谁，所以他们往往从大到大。

第三，使您的代码绝对不可维护。静态方法的使用引入了隐藏的依赖关系。它们在整个地方弹出，您永远都不知道课堂上正在发生什么。您不能仅仅通过查看构造函数签名来确保这一点。

慢慢地，但不可避免地，由于对隐藏的依赖关系的控制不力，您的代码变得越来越缺乏凝聚力。他们似乎是看不见的。添加另一个很容易！您不必修改任何方法的签名。您要做的就是调用静态方法。然后是一个丑陋的代码...

好吧，您可能已经猜到了。紧密耦合经常导致低内聚。如果有很多客户在使用某个类，那么耦合会越来越紧密。使用已经编写好的只需要很小的修改的类或方法就会引起很大的诱惑。仅一种方法标志参数。

用什么代替静态方法？好吧，我的建议是OOP。为什么不尝试一下呢？