拥有一个拥有整个对象生命周期资源的类成员是一个好主意吗?

时间:2014-01-17 12:39:07

标签: c# resources idisposable

我可以拥有一个拥有一个拥有资源的成员的类,或者至少它实现了IDisposable。这是一个例子(仅用于显示我的意思):

public class Something
{
    private HMACSHA1 HmacSha1;

    public Something()
    {
        HmacSha1 = new HMACSHA1();
    }

    public byte[] DoIt(byte[] bytes)
    {
        return HmacSha1.ComputeHash(bytes);
    }
}

成员HmacSha1实现IDisposable,因此应该在对象的生命周期结束时处置。我知道这并不是我的问题的一部分,故意在示例中遗漏。它也可以是任何其他类型的资源,如数据库或网络连接。

我想知道保持该成员打开(我的意思是在开头创建一次而不是处置)的整个生命周期是否是一个好主意。对象

或者最好在需要的地方创建和处理它 - 在上面示例的方法DoIt()中?

有什么缺点?

1 个答案:

答案 0 :(得分:2)

我认为这实际上取决于对象是什么以及如何使用它。

如果对象包含不方便存储在您需要保留的其他位置的状态信息,那么构造它并保留它可能是有意义的。

如果对象的方法快速执行但创建和释放对象的代价很​​高,那么出于性能原因也可能有意义。如果它的方法处于性能瓶颈中,那么它将提供一个性能优势来保持对象存活并从那些时间敏感的方法调用中移除构造/破坏开销。

考虑一下:

public Something()
{
    someObject = new SomeObject();  //let's say this takes 350ms
}

public byte[] DoIt(byte[] bytes)
{
    return someObject.ComputeHash(bytes);  //let's say this takes 3ms
}

现在...

private void doSomething()
{
    for(int i = 0; i < 100000; i++) { 
      someList.Add(something.DoIt(someBytes)); //this will take 5 minutes
    }  // but if someObject is created and freed in the loop it will take
}      // almost ten hours!

动态创建和释放它的论据几乎以同样的方式工作。如果对象很大并且消耗大量内存,那么只有在需要时才使它活着可能更有效(如果它不包含任何其他地方无法有效保存的状态信息),只要动态创建和释放的性能损失与内存占用的增益相比,该对象很小。

想象一下,类Something的用例将涉及在任何给定时间存活的数百个实例。如果它们都保留了不经常使用的someObject的持久化实例,那么您的内存占用数量会同时存在数百倍,而每个Something可能偶尔只需要它一次。在这种情况下,只有在需要时才能创建它。

作为一项规则,那么,我认为最好说任何对象,结构或变量应该只有在它有持续存在的原因时才会持久存在。如果你不能做出明智的论据来保持它,那么就把它释放出来吧。