1

When using IoC in a code base, should one always stick strictly to the pattern without exception?

That means there should be no "new" in any constructor, when the newed object has dependencies.

Or should one just go for convenience with that pattern.

Things like in the example should not be allowed?:

 public ToolbarViewModel(
      ICommand slowCommand,
      string text)
    {
       SlowCommand = new LongRunningCommandDecorator(slowCommand, text);
    }

1 Answer 1

7

Rule #1: there are exceptions to every rule.

The point of IoC is to make it easy to use a different implementation of a dependency. If there's no circumstance in which going to want to use a different implementation (including for unit testing), then just new up the object.

The most common case here is for your platform objects - you're never (see Rule #1) going to want to use a different implementation of string, so it would be a ridiculous amount of overkill to push an IStringFactory into your objects so you can do return stringFactory.create("Hello, World!") rather than return "Hello, World!".

Be practical, not dogmatic. If following a rule costs more than it gains, don't follow the rule.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.