使用过多的静电是好是坏?

但这是好是坏

我想到的第一个形容词是“不必要”。C++有自由函数和命名空间,那么为什么需要在类中使它们成为静态函数呢?

C#和Java中非实体类中静态方法的使用 是一种变通方法 因为这些语言没有自由函数(即直接驻留在名称空间中的函数,而不是作为类的一部分)。C++没有这个缺陷。只需使用命名空间。

我完全赞成使用静态 功能 。尤其是当组织成模块时,这些才有意义( static class 在C#中)。

然而, 一…就 这些函数需要某种外部(非编译时const)数据,那么应该将该函数作为实例方法,并将其数据封装到类中。

简而言之:静态函数正常,静态数据不好。

那些说静态函数可以被名称空间替换的人是错误的,这里有一个简单的例子:

class X
{
   public:
   static void f1 ()
   {
      ...
      f2 ();
   }

   private:
     static void f2 () {}
};

如您所见,公共静态函数 f1 调用另一个静态但私有的函数 f2 .

这不仅仅是一组函数,而是一个具有自己封装方法的智能集合。命名空间不会为我们提供此功能。

许多人使用“单例”模式,只是因为这是一种常见的做法,但在许多情况下,你需要一个具有多个静态方法和一个静态数据成员的类。在这种情况下,根本不需要单例。同时调用该方法 instance() 比直接访问静态函数/成员慢。

使用命名空间创建函数集合:

namespace Console {
    void WriteLine(...) // ...
}

至于内存,函数在函数外部、静态成员函数或命名空间中使用相同的量。也就是说:除了代码本身,没有其他内存。

静态数据不好的一个具体原因是,C++不保证不同转换单元中静态对象的初始化顺序。在实践中,当一个对象在不同的翻译单元中依赖于另一个对象时,这可能会导致问题。Scott Meyers在他的《更有效的C++》一书的第26项中讨论了这一点。

同意Frank的观点,静态(全局)函数没有问题(当然,只要它们是有组织的)。。只有当人们认为“哦,我会把这部分数据的范围扩大一点”时,问题才会真正开始蔓延。.滑坡:)

为了真正正确地看待它。。 Functional Programming ;)

静态函数的问题在于,它们可能会导致破坏封装的设计。例如,如果你发现自己在写这样的东西:

public class TotalManager
{
    public double getTotal(Hamburger burger)
    {
        return burger.getPrice() + burget.getTax();
    }
}

…那么你可能需要重新考虑你的设计。静态函数通常需要使用setter和getter,它们扰乱了类的API,通常会使事情变得更加复杂。在我的例子中,最好删除Hamburger的getter,然后将getTotal()类移动到Hamburger本身。

我倾向于创建由静态函数组成的类,但有人说这样做的“正确方法”通常是使用名称空间。(我在C++有名称空间之前就养成了自己的习惯。)

顺便说一句,如果你有一个只由静态数据和函数组成的类,你应该将构造函数声明为私有的,这样就不会有人试图实例化它。(这是一些人认为使用名称空间而不是类的原因之一。)

对于组织,请按照前面的说明使用命名空间。

对于全球数据,我喜欢使用 singleton 模式,因为它有助于解决静态对象初始化顺序未知的问题。换句话说,如果将对象用作单例,则可以保证在使用时对其进行初始化。

还要确保你的静态函数是无状态的,这样它们才是线程安全的。

我通常只将静态数据与好友系统结合使用。

例如,我有一个类,它使用大量(内联)内部辅助函数来计算内容,包括对私有数据的操作。

当然,这增加了类接口的函数数量。 为了摆脱这种情况,我在原始classes.cpp文件中声明了一个辅助类(因此外界看不到),使其成为原始类的朋友,然后将旧的辅助函数移动到辅助类的静态(内联)成员函数中,除了旧的参数外,还按引用传递旧的类。

这使界面保持纤薄,不需要大量的免费好友功能。 内衬也很好用,所以我并不完全反对静电。 (我尽量避免使用它,但我喜欢这样使用它。)