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).
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.
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?
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.
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).