

On dependencies in the API - jauco
http://googletesting.blogspot.com/2008/08/by-miko-hevery-so-you-join-new-project.html

======
smhinsey
I have thought at times that allowing the definition of constructors in
interfaces would go a long way towards solving this problem. It's much easier
to manage dependencies with cleaner patterns when you don't have to define
some ugly Configure(MyConfiguration) method and throw exceptions if it hasn't
been called before you do anything else.

In their example an interface doesn't really help since CreditCard is probably
a value object, which don't generally provide implementation variations,
however you see the problem in the Database and OfflineQueue types, whose lack
of an interface is going to add complexity to the test (CreditCardProcessor
takes an OfflineQueue but imagine OfflineQueue requires implementors to
configure a queue address at runtime, taking IQueue instead would allow you to
pass in a mocked IQueue).

------
Hexstream
Takeaway: Representing dependencies explicitly in code will avoid you lots of
trouble. One way to achieve that with an object of type X that requires an
object of type Y is to require an y in the constructor for x's.

~~~
sh1mmer
Maybe I'm being slow, but I didn't get how they were explicitly declaring it
except in the test, and I don't see how one test in a whole suite would help a
newbie discover this problem.

Are they actually implying the constructor should throw an exception moaning
about lack of X dependency?

~~~
Hexstream
You can't call the constructor without passing the reference to the object the
new object depends on... Thus you can't inadvertantly initialize the objects
in the wrong order.

~~~
sh1mmer
Makes sense, thanks!

