Comments on: PTOM – Brownfield development – Making your dependencies explicit

By: rtpHarry

rtpHarry — Sat, 05 Dec 2009 01:20:39 +0000

Hey, I enjoyed reading this post. I think I read it back when it was originally posted as well. It discusses some advanced topics in a nice way – by explaining them clearly and not getting tied up in all the associated topics such as what SOLID is etc.

I noticed a few typos while I was reading them which I will paste below because I cannot see a way to contact you via PM:

“An implicit dependency of a give class is a dependency that is not discoverable from the outside of this class. The corresponding dependency is never appearing in the contract (or interface) of the class.”

give should be given

Since we are extending an existing application and since we cannot modify the whole code base at once we need to be able to use our modified component the same way as we did before the change was introduced. Probably the OrderSerivce class is used at various points in the legacy code base in the following way

OrderSerivce should be OrderService

Well, there is a simple solution – this solution is also called “poor man’s dependency injection. We can implement a default constructor in the class and just forward the call to the other constructor.

“poor man’s dependency injection is missing closing ”

Not the class is responsible to acquire its dependencies but those dependencies are injected from “outside”.

Not the class is responsible doesn’t make sense.

By: Jim Martin

Jim Martin — Sat, 09 May 2009 17:30:35 +0000

Nicely done! I really like how you explained DI as it relates to brownfield projects.

By: Think before coding

Think before coding — Tue, 05 May 2009 08:41:13 +0000

Good advice for DI new comers.
I would just add that when putting interfaces in front of existing framework parts, you don’t have to mimic framework methods exactly…
For instance, you can create a IConfiguration interface that provide properties for each app setting (this way you can get rid of magic strings, and you don’t have to know if the settings are in the app.config file or elsewhere).

By: Anne Epstein

Anne Epstein — Tue, 05 May 2009 04:56:23 +0000

Excellent article, Gabriel! I particularly like the idea of making the default constructor a factory method as a stopgap. It’s a great way of picking apart dependencies NOW without worrying about having to make risky changes that could cascade over the whole app. That sort of worry often prevents any improvements at all-so, small, low-risk steps like this illustrates are SO important.

I’m really looking forward to the rest of this series!