2

I'm annoyed to have to pass plumbing objects through Constructor because I'd like to reserve constructor arguments for business entities or values to pass.

So I'd like to pass by Setters but my object which contains the dependencies should not be instantiated as long as these setters has not been fullfilled.

How to do this without a bunch of if dependency01 not empty and dependency02 not empty knowing that BOTH must not be empty ?

user310291
  • 36,946
  • 82
  • 271
  • 487

3 Answers3

1

You are trying to bypass contructor. If the objects are really required to have the object in consistent state I would suggest to re-consider using constructor for this purpose.

EDIT: From my point of view the best is the builder pattern which combines the best of both:

  • Allow creation of immutable objects (!) - the setters violate this
  • Allow to set dependencies by name instead of having to use the indexes - biggest (if not only) advantage of setters
Jan Zyka
  • 17,460
  • 16
  • 70
  • 118
  • I'm not trying to bypass constructor, I want to use constructor of business objects for business dependencies and not mix infrastructure objects with business stuff. – user310291 Apr 18 '11 at 10:10
  • Never mind. I just don't see why people don't like to use constructors. See this nice post on this topic if you are interested in this topic seriously: http://googletesting.blogspot.com/2009/02/constructor-injection-vs-setter.html – Jan Zyka Apr 18 '11 at 10:53
  • I spent on this topic few evenings and conclusion for me is to use the builder pattern. Which combines (from my point of view) the best of both approaches: allow build immutable object + allow to set the dependencies by name. – Jan Zyka Apr 18 '11 at 10:57
1

You can't set anything on an object until it's been instantiated, so your requirement (as stated) is impossible.

If you used a static factory method, you could use setters - but this would require that your constructor be private, so really doesn't change anything beyond the constructor.

You could use an Initialize method that relies on certain properties being set, but you then have to rely on that method being called. That means either a lot of plumbing to make sure the method's been called (e.g. each class method has to call if (!IsInitialized) throw ...), or you just introduce fragility into your code.

Any alternative solution is less robust or more work than just putting absolutely-required data in your constructor - which is what a constructor parameter is for. My suggestion would be that you need to revisit your arbitrary requirement that constructor parameters be "reserved" in favour of something that makes more technical sense.

Dan Puzey
  • 33,626
  • 4
  • 73
  • 96
  • It's not arbitrary: I want to use constructor of business objects for business dependencies and not mix infrastructure objects with business stuff. It's a question of separating concerns per se. – user310291 Apr 18 '11 at 10:14
  • Yes, but your "separation of concerns" doesn't belong where you're trying to put it. Constructor vs properties is not where you enforce separation of concerns - my suspicion would be that you have too few classes! – Dan Puzey Apr 18 '11 at 12:40
1

You could create a factory class which takes in the dependencies.

factory = new Factory(dep01, dep02);

And use the create method to pass in your business entity.

factory.Create(someBusinessObject);

I'm not entirely fond of this (mis)use of the factory's constructor, but it does solve your problem.

koenmetsu
  • 1,044
  • 9
  • 31