C# Object construction outside the constructor

Question

When it comes to designing classes and "communication" between them, I always try to design them in such way that all object construction and composing take place in object constructor. I don't like the idea of object construction and composition taking place from outside, like other objects setting properties and calling methods on my object to initialize it. This especially gets ugly when multiple object try to do thisto your object and you never know in what order your props\methods will be executed.

Unforunatly I stumbl on such situations quite often, especially now with the growing popularity of dependecy injection frameworks, lots of libraries and frameworks rely on some kind of external object initialization, and quite often require not only constructor injection on our object but property injection too.

My question are:

1. Is it ok to have objects that relly on some method, or property to be called on them after which they can consider them initialzied?

2. Is ther some kind of pattern for situations when your object acting is receiver, and must support multiple interfaces that call it, and the order of these calls does matter? (something better than setting flags, like ThisWasDone, ThatWasCalled)

Answer 1

I don't see anything wrong in this. It may be not so convinient, but you can not ALWAYS use initialization in ctor, like you can not alwats drive under green light. These are dicisions that you made based on your app requirements.

1. It's ok. Immagine if your object, for example, need to read data from TCP stream or a file that ciuld be not present or corrupted. Raise an exception from ctor is baaad.

2. It's ok. If you think, for example, about some your DSL language compiler, it can looks like:

A) find all global variables and check if there mem allocation sum sutisfies your device requierements

B) parse for errors

C) check for self cycling

And so on...

Hoe this helps.

Answer 2

First of all, Factory Method.

public class MyClass
{
    private MyClass()
    {
    }

    public Create()
    {
        return new MyClass();
    }
}

Second of all, why do you not want another class creating an object for you? (Factory)

public class MyThingFactory
{
    IThing CreateThing(Speed speed)
    {
        if(speed == Speed.Fast)
        {
            return new FastThing();
        }

        return new SlowThing();
    }
}

Third, why do multiple classes have side effects on new instances of your class? Don't you have declarative control over what other classes have access to your object?

Answer 3

Is it ok to have objects that relly on some method, or property to be called on them after which they can consider them initialzied?

No. Init methods are a pain since there is no guarantee that they will get called. A simple solution is to switch to interfaces and use factory or builder pattern to compose the implementation.

@Mark Seemann has written a article about it: http://blog.ploeh.dk/2011/05/24/DesignSmellTemporalCoupling.aspx

Is there some kind of pattern for situations when your object acting is receiver, and must support multiple interfaces that call it, and the order of these calls does matter? (something better than setting flags, like ThisWasDone, ThatWasCalled)

Builder pattern.

Answer 4

I think it is OK, but there are implications. If this is an object to be used by others, you need to ensure that an exception is thrown any time a method or property is set or accessed and the initialization should have been called but isn't.

Obviously it is much more convenient and intuitive if you can take care of this in the constructor, then you don't have to implement these checks.

Answer 5

Answering (1)

Why not? An engine needs the driver because this must enter the key for the car, and later power-on. Will a car do things like detecting current speed if engine is stopeed? Or Will the car show remaining oil without powering-on it?

Some programming goals won't be able to have their actors initialized during its object construction, and this isn't because it's a non-proper way of doing things but because it's the natural, regular and/or semantically-wise way of representing its whole behavior.

Answering (2)

A decent class usage documentation will be your best friend. Like answer to (1), there're some things in this world that should be done in order to get them done rightly, and it's not a problem but a requirement.

Checking objects' state using flags isn't a problem too, it's a good way of adding reliability to your object models, because its own behaviors and consumers of them will be aware about if things got done as expected or not.