1

I have a question regarding the specifics of object creation and the usage of properties. A best practice is to put all the properties into a state such that the object is useful when its created. Object constructors help ensure that required dependencies are created.

I've found myself following a pattern lately, and then questioning its appropriateness.
The pattern looks like this...

 public class ThingProcesser
  {
    public List<Thing> CalculatedThings { get; set; }

    public ThingProcesser()
    {
        CalculatedThings = new List<Thing>();
    }

    public double FindCertainThing()
    {
        CheckForException();
        foreach (var thing in CalculatedThings)
        {
            //do some stuff with things...
        }
    }

    public double FindOtherThing()
    {
        CheckForException();
        foreach (var thing in CalculatedThings)
        {
            //do some stuff with things...
        }
    }

    private void CheckForException()
    {
        if (CalculatedThings.Count < 2) throw new InvalidOperationException("Calculated things must have more than 2 items");
    }
  }

The list of items is not being changed, just looked through by the methods. There are several methods on the class, and to avoid having to pass the list of things to each function as a method parameter, I set it once on the class. While this works, does it violate the principle of least astonishment?

Since starting to use IoC I find myself not sticking things into the constructor, to avoid having to use a factory pattern. For example, I can argue with myself and say well the ThingProcessor really needs a List to work, so the object should be constructed like this.

 public class ThingProcesser
    {
        public List<Thing> CalculatedThings { get; set; }

        public ThingProcesser(List<Thing> calculatedThings)
        {
            CalculatedThings = calculatedThings;
        }
    }

However, if I did this, it would complicate things for IoC, and this scenario hardly seems appropriate for something like the factory pattern.

So in summary, are there some good guidelines for when something should be part of the object state, vs. passed as a method parameter? When using IoC, is the factory pattern the best way to deal with objects that need created with state? If something has to be passed to multiple methods in a class, does that render it a good candidate to be part of the objects state?

  • My thoughts are that a good IOC module would handle constructor injection just as well as property injection etc? Seems a shame to determine your design based explicitly on IOC. I always thought IOC just provided the framework for building good design if the problem suited. – dreza Jun 1 '14 at 20:22
0

While this works, does it violate the principle of least astonishment?

I suppose. More importantly, it tightly couples a bunch of stuff to these methods that not all of them (individually) need, and presents a too loose contract with the outside world.

Since starting to use IoC I find myself not sticking things into the constructor, to avoid having to use a factory pattern.

What? I fail to see how those things are in any way related. If something needs IFoo, then let it take an IFoo. If you also want to use IoC containers to provide you a concrete implementation of IFoo then go right ahead. Your constructor doesn't need to know that.

So in summary, are there some good guidelines for when something should be part of the object state, vs. passed as a method parameter?

Who owns the state? If it's an intrinsic part of your class, used across multiple functions on the class, then your class owns the state. Otherwise, pass it in.

If something has to be passed to multiple methods in a class, does that render it a good candidate to be part of the objects state?

Possibly, but it's not a candidate for including something in your class, it's a code smell. It means that this other odd class needs this data to work, but the data isn't part of it.

It's a bit subtle, but "oh, I'll tack this on in the constructor" is a good way to violate the Single Responsibility Principle and otherways make a sucky class. "Hrmm, this doesn't quite work, what if I did XYZ instead?" is a good way to refactor multiple classes so that they have a nice single responsibility and interact in a clean decoupled way.

  • So in this case, every single method in the class needs the collection of objects for any of the methods to do anything. Therefore I could argue that it is an intrinsic part of the class. – GetFuzzy Jun 1 '14 at 21:22
  • As to the point IoC and the constructor... Take a Person class, you could say the person class is worthless till you set its Name, and Address, so Person(string name, string address), I've avoided such things, I'd have IoC create a Person, then map properties from one class to another to set name & address. Not the greatest example as with a person, a factory would easily make sense. The tip on who owns the state is a valuable one for me, perhaps I've taken SRP to far in my mind, and need to recombine some classes to get one object that better represents what I'm trying to do... – GetFuzzy Jun 1 '14 at 21:35

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.