一般的OOP和特别的C＃ - 构造函数应该快速返回吗？

Question

I'm currently refactoring some old code for my work. Some idiot (me, 2 years ago) wrote a few things that I think stink. I have this feeling in my gut (I've might read somewhere and forgotten the source) that a constructor in C# should return quickly, because of some technical detail, possibly to do with garbage collection. Ie the following

class A
{
     public object Result {get; private set;}
     private object RunLongOperation(){/* ... */}
     public A(){
         Result = RunLongOperation();
     }
}

is bad practise. So my question is twofold - Is it actually bad, and if so why? The above can be rewritten as

class A
{
     public object Result {get; private set;}
     private static object RunLongOperation(){/* ... */}
     private A() { }
     public static A Make(){
        return  new A { Result = RunLongOperation() };
     }
}

through a kind of factory static method. This to me just seems more code than necessary, but the actual object is constructed quickly.

To shine a light, the constructor takes a few parameters and renders an image in RunLonOperation() , and does some other stuff based on the input parameters. The class then reduces to immutable result container. The operation takes about 10 to 20 seconds, based on parameters.

Answer 1

Yes doing real work in a constructor is a bad thing from a testability point of view.

It is very hard to write a test for a class that does heavy work in the constructor because you don't have any means left to change the dependencies needed for that object or to inject some custom behaviour by mocking the object.

See http://misko.hevery.com/code-reviewers-guide/flaw-constructor-does-real-work/ for a good explanation of this design flaw.

Answer 2

I don't think that there is a technical requirement (eg GC) that a constructor should not take more than a certain time. However from a programmers point of view, I certainly do not expect that new -ing an object will take a long time. The factory method seems better suited for that use to me.

You also might consider removing the long running operation and injecting the result into the constructor and have a RenderImageFactory instead. Would make the process more obvious and might help with unit testing (meaning: If you want to unit tets class A you might not want to have to render the image every time but instead be able to just mock it out to speed things up and reduce test setup overhead)

Answer 3

我不认为应该有一个通用的规则，但实际上最好使用工厂模式，而不是在构造函数中处理太多的东西。

Answer 4

There is no hard rule about how long a constructor may take. It depends on what you could reasonably expect depending on what the object does.

If it's possible to use lazy loading, you should consider it that is good for your class. If you for example are loading different things in the constructor, and some of them are not always used, it could be better to load them when and if they are actually needed.

Other than that there isn't often a good reason to put work anywhere else than the constructor, if it needs to be done anyway.

Answer 5

There's no reason at all why a constructor should not take as long as it needs to do its job. The options proposed by you and others look to me like they will make your code more complex for no discernible benefit.

Answer 6

Anytime we consider a long-running task call from the .ctor is a good sign of a bad design smell. I was always keeping this in my mind until I stuck on a similar issue, running a log code in a type .ctor. In my case I'm about to run a Task<T> asynchronously in the constructor and total the problem, I can't get rid of the task at all since it's all about reflections where your hands are off of any good design principle implementation.

The Thread.Suspend and Thread.Pause seemed to be the only dangerous candidates for running long tasks from constructors, but they're obsolete (after 1.1) and now it seems there's no any reason to limit the execution of the .ctor but the intuitive principle of any API design (that the .ctor is simply a way to quickly "prepare" the object for further usage. MSDN has a good guideline for that).

My suggestion would be using a Factory instead, since constructors are not the place to put business logic within, typically. If you can refactor then you should . If you can't nobody will punish you for that ;)

Answer 7

Be lazy:

class A 
{
     private A() { } 
     private static object _Result;
     public static object Result 
     {
         get
         {
              if (_Result == null)
                   _Result = RunLongOperation();
              return _Result;
         }
     }
     private static object RunLongOperation(){/* ... */} 
} 

Answer 8

If the long running operation is referentially transparent , then you could only run it once for each possible outcome of 'Result', and re-use those results for each object instance. This may provide a performance benefit. If there are multiple possible results then you'll need some way to look up which result is appropriate.

This is just a rough example, may need some tweaking:

class A 
{      
   static Dictionary<String, Object> memoizationCache;

   public static bool TryGetMemoizedResult(A instance, out object result)
   {
       // do the checking etc. 

       result = memoizationCache[instance.SomeMember]; 
   } 

   public static void AddMemoizedResult(A instance, object result)
   {
       memoizationCache.Add(instance.SomeMember, result); 
   } 

   public object Result {get; private set;}   

   public string SomeMember { get; private set; }   

   private object RunLongOperation(){/* ... */}   

   public A()
   {   
       object result;

       if (TryGetMemoizedResult(this, out result))
       {
            Result = result;
       }
       else 
       {
            Result = RunLongOperation();  
            AddMemoizedResult(this, this.Result); 
       }    
   } 
} 

The reason I bring that up is because it looks like in your case the operation may be referentially transparent, but if not, then I'd go with the lazy loading approach. As it stands I dont think there should be a huge performance difference between your two initialization techniques, though.