Real Work in Constructor vs Factory Method

Question

So been doing a lot of reading/research into clean code/design, OOAD, refactoring, TDD, etc. Just trying to improve my designs to be easier to extend and maintain. One thing that is come up quite often is avoiding doing "real work" in a constructor.

I won't post the resources here but names like Misko Hevery, Bob Martin, etc. seem to recommend avoiding doing much work in the constructor (quick Google search turns up a pleathora of articles). My question is not so much HOW to make this happen, but WHY? Why would I choose to use a static factory method? Why does this improve testability (as they say)?

An example of what I'm talking about is here:

public class ConstructorObject
{
    public int Value { get; }

    public ConstructorObject()
    {
      // do work (e.g. calculate divisors, GCD for array, etc.) to calculate value
      Value = value;
    }
}

public class FactoryMethodObject
{
    public int Value { get; }

    public static Create()
    {
        // do work (e.g. calculate divisors, GCD for array, etc.) to calculate value
        return new FactoryMethodObject(value);
    }

    private FactoryMethodObject(int value)
    {
        Value = value;
    }
}

To me, these appear to provide the same advantages and disadvantages. So I'm trying to figure out the WHY... Thanks!

and [Is there ever a reason to do all an object's work in a constructor?](https://softwareengineering.stackexchange.com/questions/159193/is-there-ever-a-reason-to-do-all-an-objects-work-in-a-constructor) — Robert Harvey, Jun 19 '18 at 18:54

esoterik · Accepted Answer · 2018-06-19T19:40:38.047

Why would I choose to use a static factory method?

It provides a single place to change object construction, if you wan to switch implementations, you can change the factory method and everything will use the new implementation, for this usage factory methods almost always return an interface.

A second reason is to hide the concrete typing implementing an interface for similar reasons to the above. It allows one to isolate code and reduce the interaction surface area. Hence the "depend on interfaces not concrete types" advice.

Why does this improve test-ability (as they say)?

Improved isolation improves test-ability.

It improves test-ability in that it gives you a convenient place to inject mocks; replace the static method with one that returns a mock. You can simply change an import or using directive and suddenly your code uses the mocked version.

To me, these appear to provide the same advantages and disadvantages. ...

Because the code you show doesn't use interfaces, which are a key concept in OOA&D.

Fine answer, but note that it is immaterial to the (misguided IMO) "principal" of not doing much in a constructor. — user949300, Jun 19 '18 at 19:37

score 0 · Answer 2 · answered Jun 19 '18 at 19:48

One reason is this: What is constructor injection? ... If you want to do DI properly, you can't double up on your constructors. One can argue IOC containers force you into this pattern to avoid the constructor pattern.

Another reason is scalability, some of our factories inject a dozen other factories, if I was using a constructor based approach I would have to resolve those references each time I called the complex factory turning my code to boiler mush.

Real Work in Constructor vs Factory Method

2 Answers2