tag:blogger.com,1999:blog-10712480.post8283144968889390624..comments2022-12-04T00:25:01.030+11:00Comments on Search for Simplicity: Dependency InjectionNigel Thornehttp://www.blogger.com/profile/07280667421574609074noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-10712480.post-6447583223269503842008-06-11T10:46:00.000+10:002008-06-11T10:46:00.000+10:00Just looking at your code samples,is this a fair e...Just looking at your code samples,<BR/>is this a fair enough assumption on how a typical MVC app would be constructed if I were to use the framework?<BR/><BR/>public class ShowBananaController<BR/>{<BR/> private ISystemDefinition definition;<BR/><BR/> // default constructor<BR/> public ShowBananaController()<BR/> {<BR/> definition = new SystemDefinition();<BR/> definition.HasInstance(new Banana(1)).Provides<IBanana>();<BR/> definition.HasInstance(new WebFormView("showBanana")).Provides<IViewEngine>();<BR/> this(definition);<BR/> }<BR/><BR/> // dependency injection constructor: most likely used for testing<BR/> public ShowBananaController(ISystemDefinition _definition)<BR/> {<BR/> definition = _definition; <BR/> }<BR/><BR/> // the resource consumer function<BR/> public void PrintName()<BR/> {<BR/> IBanana b = definition.Get<IBanana>();<BR/> IViewEngine view = definition.Get<IViewEngine>(); <BR/> view.Print(b.Name)<BR/> }<BR/>}<BR/><BR/><BR/>p.s more questions later if you say yes (-:Ronald Widhahttps://www.blogger.com/profile/14344147182612857497noreply@blogger.comtag:blogger.com,1999:blog-10712480.post-39627698057655850312008-02-27T20:59:00.000+11:002008-02-27T20:59:00.000+11:00I thought I had explained that I have no Singleton...I thought I had explained that I have no Singleton classes at all. The decision to use a class as a singleton is a wiring decision. <BR/><BR/>Obviously I didn't explain clearly enough.Nigel Thornehttps://www.blogger.com/profile/07280667421574609074noreply@blogger.comtag:blogger.com,1999:blog-10712480.post-78479760971747489742008-02-27T18:09:00.000+11:002008-02-27T18:09:00.000+11:00Your comment was kinda long winded, so I'll just t...Your comment was kinda long winded, so I'll just try coming at the issue from a different angle to try and explain my point of view.<BR/><BR/>The Singleton pattern enforces the rule that only one instance of a class can get created. It usually allows access to that class by calling something like MyClass.getInstance(). When you do that, you and up with lots of methods like this:<BR/><BR/>void foo() {<BR/> ...<BR/> MyClass.getInstance();<BR/> ...<BR/>}<BR/><BR/>This is awful to test. Much better to inject the dependency like this:<BR/><BR/>void foo(MyClass variableName) {<BR/>}<BR/><BR/>The decision to only create one instance in your application is different to the design decision about whether another instance *can* exist. I might want to create ten different ResourceRegistry objects in my test suite, but only one in my application.<BR/><BR/>My point is: Don't make things Singletons just because you only want one in your application. You'll end up with code that is hard to test, because people *will* end up calling the getInstance() method somewhere in the bowels of your code.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-10712480.post-71058005003796790462008-02-27T17:12:00.000+11:002008-02-27T17:12:00.000+11:00Thanks for the feedback Marty.I don't understand "...Thanks for the feedback Marty.<BR/><BR/>I don't understand "Be very wary of changing the class design just for convenience". Please can you expand on this?<BR/><BR/>Here is what I am thinking... <BR/><BR/>Given the assumption that you divide your code into 'definition of classes to use' and 'wiring' [which is the intent of my dependency injection framework]... <BR/><BR/>Then the decision to use a class as a service that there is only one instance of is a wiring decision.<BR/><BR/>If you then define in your writing so that you _can't_ create second instance of the class it is then a Singleton. <BR/><BR/>Can you agree with that? Even if the class in question has no explicit code to enforce a Singleton nature. <BR/><BR/>Assuming you can go with me on that (feel free to disagree)...<BR/><BR/>That just leaves the concept of Scopes having Singletons.<BR/><BR/>I agree that here I am stretching the term Singleton. However, if we can agree that the 'definition of the wiring' is what makes a class a singleton, not the class itself, then extending the concept to say that within a limited scope a class is a Singleton, then that is where I am coming from. <BR/><BR/>Within the Scope every class that wants access to the specific resource or service has to use the same instance. Singularity is enforced by the wiring. <BR/><BR/>To stretch the definition in this way involves seeing each subsystem as its own module with it's own wiring. <BR/><BR/>Imagine you wrote a Plugin-API that exposed a 'ResourceRegistry' class. As far as that plugin is concerned there is only once instance of this registry class and it accessed as a singleton. To your plugin it is a Singleton. <BR/><BR/>However in your application code a plugin is one of many, and you have separate ResourceRegistry instances for each plugin. In this context it is not a Singleton.<BR/><BR/>Does this make sense?Nigel Thornehttps://www.blogger.com/profile/07280667421574609074noreply@blogger.comtag:blogger.com,1999:blog-10712480.post-60339182966894293822008-02-27T07:52:00.000+11:002008-02-27T07:52:00.000+11:00"Within the Application there are objects that you..."Within the Application there are objects that you only have one instance of. These are by definition Singletons."<BR/><BR/>No they're not. A Singleton is a class that you can't create more instances of, not one that you simply don't make more instances of. Be very wary of changing the class design just for convenience.Anonymousnoreply@blogger.com