tag:blogger.com,1999:blog-7242182.post109273236578150474..comments2023-06-27T13:38:50.019+02:00Comments on You Are Number 6: Getter-based is the mother of all dependency injectionstraunhttp://www.blogger.com/profile/16418566670316468267noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-7242182.post-1092770953833338692004-08-17T21:29:00.000+02:002004-08-17T21:29:00.000+02:00In response to the comments:
Howard, you need to ...In response to the comments:<br /><br />Howard, you need to check your alarm clock - DIP suggests this approach and that has been around since 1996 (Tapestry started in 1999?) and 'services through extension' had been a HOOD technique for at least 5 years before that. But yes there was a blog on this particular technique around the time of the big DI meeting.<br /><br />I did not want to repeat my previous blog too much on this subject. That blog entry suggests using velocity to generate these extensions. With generated code I have fewer qualms about using a more open extensive class structure, and in this case I suggest that there is a business requirement for being able to support multiple container paradigms. I am not suggesting that any particular library should do this, I am merely pointing out that you can keep your IoC options open.<br /><br />I know inheritance is evil and if there are any dude children watching out there then they should ask an adult before attempting any of these activities (including finals). But in this case it is necessary as providing a delegating/aggregation implementation itself requires an injection, and as I said in my previous blog something like 'these things should be as close to normal Java as possible'; I chose flexibility over ease of maintenance in this case. I concede that being unable to instantiate is a drawback.<br /><br />Testing all your classes no matter how trivial is a noble endeavour, I wish anyone who does this luck. It is however the second most ineffective way of testing your system (after not testing at all) - expect a blog on this as a separate subject.<br /><br />My words above are intended to presuade people to use DI as a technique because of its obvious benefits. The readers who are worried about which type of IoC technique they should use are my real intended audience and my message is "use it, it won't bite, and here is a way you can hedge your bets a bit".straunhttps://www.blogger.com/profile/16418566670316468267noreply@blogger.comtag:blogger.com,1999:blog-7242182.post-1092748829832610812004-08-17T15:20:00.000+02:002004-08-17T15:20:00.000+02:00Yuck! Yuck yuck yuck! Yuck yuck yuck yuck yuck ...Yuck! Yuck yuck yuck! Yuck yuck yuck yuck yuck yuck yuck!<br /><br />Dude, get some training in basic OO design skills. If not for yourself, do it for the poor saps who will have to maintain your code when you've gone.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7242182.post-1092740014480427162004-08-17T12:53:00.000+02:002004-08-17T12:53:00.000+02:00I can speak from experience that people don't like...I can speak from experience that people don't like the fact that their classes are abstract. I believe that this approach to DI is derived from Tapestry 3.0's approach to creating properties. Yes, the flexibility is good, but the cost (in terms of a proliferation of classes, even if just for testing) is high, and the frustration of not being able to instantiate your own classes is hard to dismiss.<br /><br />I'm often surprised by this aspect of DI. I vastly prefer setter injection, and the setter methods are not part of my service interface and are completely inaccessible to client code, even via reflection, due to the intervening layers of proxies and interceptor objects.Anonymoushttps://www.blogger.com/profile/04486596490758986709noreply@blogger.com