c# constructor injection and constructor overloads

Question

I'm using constructor injection for the first time and wish to write my code defensively.

Therefore if I have a class with a constructor and a save method as below:

public SomeConstructor(string name, Object someObject)
{
  _name= name;
  _someObject= someObject;
}

public void Save()
{
  // Does a database save
}

But then need to create another related method in this Class that doesn't need the _someObject so I create an overloaded chained constructor as:

public SomeConstructor(string name) : this(name, null)
{
}

How can I successfully stop someone instantiating the class with this second constructor with 1 parameter and using the Save() which has someObject as null?

I'm not using an injection tool.

Above is a simple example and in it, you are correct I could just throw an exception for a null just as I would if a property was not set.

What I wanted to avoid was a series of validation checks at the start of each method.

score 4 · Accepted Answer · answered Jun 02 '11 at 09:17

4

Use the friction you are experiencing as a warning system. It's really telling you that you're likely moving towards low cohesion and violation of the Single Responsibility Principle.

If this is the case, refactor the class into two separate classes.

answered Jun 02 '11 at 09:17

Mark Seemann

225,310
48
427
736

But in the example above you would basically have 1 class to save/delete an object with it being passed in the constructor. I.e. 1 class just for Persistence? All other methods such as Get() the most recent SomeObject would require a seperate class? That kinda sounds like overkill? – asn1981 Jun 02 '11 at 12:06
Sometimes it's overkill, but then you could just accept that one of the arguments passed to the constructor isn't used in all cases. – Mark Seemann Jun 02 '11 at 12:22
mmm... I guess there isn't always a best approach. Programming defensively means taking decisions which might violate some of your other 'principles'. I guess I was just hoping for 1 overriding rule for all situations. – asn1981 Jun 02 '11 at 12:42
1

Adding a second constructor that allows one or more fields to remain null can hardly be called defensive coding... – Mark Seemann Jun 02 '11 at 12:46
Hence the question in the first place: "How can I successfully stop someone instantiating the class with this second constructor with 1 parameter and using the Save() which has someObject as null?" – asn1981 Jun 02 '11 at 14:06
1

Add a Guard Clause: http://stackoverflow.com/questions/6189628/private-readonly-interface-is-it-redundant/6190678#6190678 – Mark Seemann Jun 02 '11 at 15:10

Matías Fidemraizer · Answer 2 · 2011-06-02T09:11:36.620

You may prevent that situation with a run-time exception like InvalidOperationException.

If some instantiated the class with the two-parameters-constructor and tries to call Save, just check if "someObject" is null, and if it's so:

throw new InvalidOperationException("This method cannot be invoked in current object state");

In the other hand, if this second constructor would be used by your library and third-party library developers wouldn't be allowed to use it, this constructor should have the internal modifier.

John Leidegren · Answer 3 · 2011-06-02T09:27:01.967

public void Save()
{  
    if (_someObject == null)
        throw new InvalidOperationException();
}

I guess that this is obvious. But you really can't create a contract in which the type is constructed differently unless you also change your SomeConstructor type to work like a decorator pattern. What the decorator pattern does is that it let's you build the inheritance hierarchy at run-time not compile-time.

You can then create different objects depending on what operations are allowed internally. This is some work for something which can easily be handled with a pre-condition for the Save method. But maybe this is what you need. And if you did it you could stipulate your contract in the constructor of SomeConstructor.

Here's an example:

interface ISomeConstructor
{
    void Save();
}

class SomeConstructor
{
    ISomeConstructor impl;

    public SomeConstructor(string name, object someObject)
    {
        impl = new StringAndObject(name, someObject);
    }

    public SomeConstructor(string name)
    {
        impl = new JustString(name);
    }

    public void Save()
    {
        impl.Save();
    }
}

The types StringAndObject and JustString implements ISomeConstructor and they can handle the Save method as they see fit.

This is a slight variation of the decorator pattern as normally you'd expect ISomeConstructor to be passed as an argument to the constructor as well.

score 0 · Answer 4 · answered Jun 02 '11 at 09:11

The IoC it is just a way to dinamically resolve the dependency but doens't solve any OO problem. I would focus on a good OO design instead of try to find a way to cheat the framework forcing to use a contractor instead of another.The question is how would you do that if you were not using an IoC framework? probabily checking if SomeObject is null?

c# constructor injection and constructor overloads

4 Answers4