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

我可以有一个拥有资源成员的类，或者至少它实现了IDisposable。这里是一个例子（只是用于示出我的意思）：拥有一个拥有整个对象生命周期资源的类成员是一个好主意吗？

public class Something 
{ 
    private HMACSHA1 HmacSha1; 

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

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

的构件HmacSha1IDisposable实现，因此应该在对象的生命周期的结尾处。我知道这一点，这不是我的问题的一部分，故意排除在这个例子中。它也可以是任何其他类型的资源，如数据库或网络连接。

我想知道它是否是一个好主意，让该成员开放（我指的是在开始创建一次，而不是配置）为对象的整个生命周期？

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

有什么缺点？

来源

2014-01-17 Dio F

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

构建一次并保持它可能是有意义的，如果对象包含不方便存储在别处的状态信息，您需要坚持。

如果对象的方法执行起来很快，但是对象创建和释放的代价很高，那么对性能的原因也是有意义的。如果其方法处于性能瓶颈，那么它将提供性能优势来保持对象的活性，并消除那些时间敏感的方法调用的构建/销毁开销。

考虑：

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可能只需要一次。在这种情况下，只需要创建它就好多了。通常情况下，我想最好是说任何对象，结构体或变量都应该只在持久存在的原因时才会持续存在。如果你不能做出一个明智的论点来保持它，然后释放它。

来源

2014-01-17 12:47:27

听起来很合理。 –

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

回答

相关问题