Comments on: I finally get the point of inversion of control http://www.ytechie.com/2008/06/i-finally-get-the-point-of-inversion-of-control.html Productive software development using ASP.NET, C#, Adobe Flex, and other technologies and tools. Thu, 09 Sep 2010 10:53:34 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Jason http://www.ytechie.com/2008/06/i-finally-get-the-point-of-inversion-of-control.html/comment-page-1#comment-1248 Jason Wed, 24 Dec 2008 18:05:19 +0000 http://www.ytechie.com/2008/06/i-finally-get-the-point-of-inversion-of-control.html#comment-1248 small comment: IoC and DI are not synonymous ("aka"). One is an abstract principle, while the other is one way to implement that principle. In other words, there are many ways to implement IoC principle. DI is just one way. small comment: IoC and DI are not synonymous (“aka”). One is an abstract principle, while the other is one way to implement that principle. In other words, there are many ways to implement IoC principle. DI is just one way.

]]> By: Kevin Berridge http://www.ytechie.com/2008/06/i-finally-get-the-point-of-inversion-of-control.html/comment-page-1#comment-610 Kevin Berridge Thu, 24 Jul 2008 16:39:08 +0000 http://www.ytechie.com/2008/06/i-finally-get-the-point-of-inversion-of-control.html#comment-610 I forgot to post back here, its mostly too late now, but I'll link my response anyway: http://kevin-berridge.blogspot.com/2008/06/ioc-and-di-complexity.html I forgot to post back here, its mostly too late now, but I’ll link my response anyway: http://kevin-berridge.blogspot.com/2008/06/ioc-and-di-complexity.html

]]> By: A Dependency Injection example with Spring.NET http://www.ytechie.com/2008/06/i-finally-get-the-point-of-inversion-of-control.html/comment-page-1#comment-481 A Dependency Injection example with Spring.NET Fri, 13 Jun 2008 13:32:59 +0000 http://www.ytechie.com/2008/06/i-finally-get-the-point-of-inversion-of-control.html#comment-481 [...] requested, here is a real world example of how I used dependency injection to simplify a project, increase modularity, and subsequently increase [...] [...] requested, here is a real world example of how I used dependency injection to simplify a project, increase modularity, and subsequently increase [...]

]]> By: superjason http://www.ytechie.com/2008/06/i-finally-get-the-point-of-inversion-of-control.html/comment-page-1#comment-477 superjason Thu, 12 Jun 2008 12:21:19 +0000 http://www.ytechie.com/2008/06/i-finally-get-the-point-of-inversion-of-control.html#comment-477 Egil, great idea. I have a GREAT example too! Subscribe to my feed so you don't miss it. I'll try to shot for posting it tomorrow. Egil, great idea. I have a GREAT example too! Subscribe to my feed so you don’t miss it. I’ll try to shot for posting it tomorrow.

]]> By: Egil http://www.ytechie.com/2008/06/i-finally-get-the-point-of-inversion-of-control.html/comment-page-1#comment-475 Egil Thu, 12 Jun 2008 08:35:46 +0000 http://www.ytechie.com/2008/06/i-finally-get-the-point-of-inversion-of-control.html#comment-475 Jason, thanks for this, I finally get the principle. I would love to see some example code to get my head around it even more. Regards, Egil. Jason, thanks for this, I finally get the principle. I would love to see some example code to get my head around it even more.

Regards, Egil.

]]> By: Steven Harman http://www.ytechie.com/2008/06/i-finally-get-the-point-of-inversion-of-control.html/comment-page-1#comment-473 Steven Harman Thu, 12 Jun 2008 01:50:32 +0000 http://www.ytechie.com/2008/06/i-finally-get-the-point-of-inversion-of-control.html#comment-473 @Kevin, I have to agree with some of the others - the problem you're describing is not one with the pattern, but with your IDE. A weak IDE is not a valid reason to dismiss the Dependency Inversion Principle, nor any of the related SOLID principles (i.e.- Separation of Concerns, Single Responsibility Principle, Liskov Substitution Principle, Law of Demeter, etc...). Following these principles leads to more loosely coupled, highly cohesive code which easily delivers more value than is lost due to the code navigation issues you've described with your IDE. Plus, as a .net guy, likely writing code in Visual Studio - you can easily overcome those navigation issues with ReSharper. @Kevin,
I have to agree with some of the others – the problem you’re describing is not one with the pattern, but with your IDE.

A weak IDE is not a valid reason to dismiss the Dependency Inversion Principle, nor any of the related SOLID principles (i.e.- Separation of Concerns, Single Responsibility Principle, Liskov Substitution Principle, Law of Demeter, etc…). Following these principles leads to more loosely coupled, highly cohesive code which easily delivers more value than is lost due to the code navigation issues you’ve described with your IDE.

Plus, as a .net guy, likely writing code in Visual Studio – you can easily overcome those navigation issues with ReSharper.

]]> By: Riccardo http://www.ytechie.com/2008/06/i-finally-get-the-point-of-inversion-of-control.html/comment-page-1#comment-462 Riccardo Tue, 10 Jun 2008 15:16:31 +0000 http://www.ytechie.com/2008/06/i-finally-get-the-point-of-inversion-of-control.html#comment-462 @Kevin Well I don't know if this applies also to .net, but in java (with most IDE's) you can look through the stack trace, you can use step filters to avoid stopping at DI framework proxies when you debug; or you can also go to a specific implementation instead of going to method definition while browsing code. I also found this discussion very interesting and I agree that DI is to be used wisely; I also think that the chance to test code easier is alone worth most downsides of DI. Thanks to everyone, specially to the author which wrote a very good post. @Kevin
Well I don’t know if this applies also to .net, but in java (with most IDE’s) you can look through the stack trace, you can use step filters to avoid stopping at DI framework proxies when you debug; or you can also go to a specific implementation instead of going to method definition while browsing code.
I also found this discussion very interesting and I agree that DI is to be used wisely; I also think that the chance to test code easier is alone worth most downsides of DI.
Thanks to everyone, specially to the author which wrote a very good post.

]]> By: Kevin Berridge http://www.ytechie.com/2008/06/i-finally-get-the-point-of-inversion-of-control.html/comment-page-1#comment-459 Kevin Berridge Mon, 09 Jun 2008 15:12:04 +0000 http://www.ytechie.com/2008/06/i-finally-get-the-point-of-inversion-of-control.html#comment-459 You are all of course correct. You should put comments on things to describe requirements like these. Of course that doesn't guarantee implementors will follow them, or that the comments will remain up to date, but that's beside the point. My argument is, if you weren't using IoC you wouldn't have to worry about any of this. You would simply write your code and be done with it. It's only because you're allowing for arbitrary implementations to be passed in (through DI) that any of this is important. If you intended for many implementations to be used, it makes sense to worry about this. But when you're doing it simply so you can test, is it worth it? @Riccardo: I'm curious. Are you talking about stepping through while you're Debugging, or a "go to definition" type feature when you're just browsing the code? Thanks everyone for the responses! It's been very educational for me. I should also point out that I agree with all of you, and that in real life I actually use DI (though not IoC). I mainly just wanted to spur a discussion about the possible downsides. You are all of course correct. You should put comments on things to describe requirements like these. Of course that doesn’t guarantee implementors will follow them, or that the comments will remain up to date, but that’s beside the point.

My argument is, if you weren’t using IoC you wouldn’t have to worry about any of this. You would simply write your code and be done with it. It’s only because you’re allowing for arbitrary implementations to be passed in (through DI) that any of this is important. If you intended for many implementations to be used, it makes sense to worry about this. But when you’re doing it simply so you can test, is it worth it?

@Riccardo: I’m curious. Are you talking about stepping through while you’re Debugging, or a “go to definition” type feature when you’re just browsing the code?

Thanks everyone for the responses! It’s been very educational for me. I should also point out that I agree with all of you, and that in real life I actually use DI (though not IoC). I mainly just wanted to spur a discussion about the possible downsides.

]]> By: bminews.com http://www.ytechie.com/2008/06/i-finally-get-the-point-of-inversion-of-control.html/comment-page-1#comment-458 bminews.com Mon, 09 Jun 2008 15:02:07 +0000 http://www.ytechie.com/2008/06/i-finally-get-the-point-of-inversion-of-control.html#comment-458 <strong>Inversion of Control...</strong> Discussion about the Inversion of Control design pattern for making modular software.... Inversion of Control…

Discussion about the Inversion of Control design pattern for making modular software….

]]> By: Renato http://www.ytechie.com/2008/06/i-finally-get-the-point-of-inversion-of-control.html/comment-page-1#comment-457 Renato Mon, 09 Jun 2008 14:52:38 +0000 http://www.ytechie.com/2008/06/i-finally-get-the-point-of-inversion-of-control.html#comment-457 I'd have to agree with Jared. The operations should define how the methods will behave. Using something like Design by Contract helps a lot with this. The final state of the db connection can be defined as a postcondition. The validity of a null parameter can be described as a precondition. And so on. I’d have to agree with Jared. The operations should define how the methods will behave. Using something like Design by Contract helps a lot with this. The final state of the db connection can be defined as a postcondition. The validity of a null parameter can be described as a precondition. And so on.

]]>