Changes between Version 3 and Version 4 of DependencyInjection


Ignore:
Timestamp:
Apr 25, 2008, 12:31:33 PM (11 years ago)
Author:
lemon-head
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DependencyInjection

    v3 v4  
    3131Now imagine we decide to replace the PPostHandler with something else, that works differently, and has a different classname. We now have to change all the 255 occurances.
    3232
    33 * or do you? You could ALSO just change PPostHandler and have it forward the new object you created. In essence, what you're assuming is that we would HAVE to change all 255 occurrances - but that's obviously not the case.
     33 * or do you? You could ALSO just change PPostHandler and have it forward the new object you created. In essence, what you're assuming is that we would HAVE to change all 255 occurrances - but that's obviously not the case.
     34  * ok, the explanation was a bit too simplified. Instead, what about you start with 255 occurances of a singleton, then you decide that in 120 of these you want implementation A, and in the other cases you want implementation B. With a singleton, you would need a global state to tell it which implementation you want, and a case distinction inside the singleton. And if in one request you need to switch between A and B for different components, it will be a hell to keep track of the global state. With injected objects, we can just make two implementation classes A and B, and give them to the components as they need it.
     35  * And, about PPostHandler: It is part of the PT lib, so we don't really want to change it. If it was a normal passed-around object, we could make do the modifications in a subclass and pass around an object of that type.
    3436
    3537=== Side effects ===
     
    3941Now imagine something goes wrong with the object - then we would have to check all the different places where the object is modified.
    4042
    41 * This is more of an issue but it does NOT mean that Singletons or Registrys are bad designs. What it means is that you have to use them right. So, if you allow code outside a singleton to change it's vars and all other code  depends on it, then log the change. Again, problem solved: you could have a debug function (to switch on or off) that outputs the state of the Singleton on every change, this would also solve the problem. There isn't any basis for assuming that singletons mean we blindly have to look through every piece of code that references the singleton - that is only the case if we implement the singletons badly.
     43 * This is more of an issue but it does NOT mean that Singletons or Registrys are bad designs. What it means is that you have to use them right. So, if you allow code outside a singleton to change it's vars and all other code  depends on it, then log the change. Again, problem solved: you could have a debug function (to switch on or off) that outputs the state of the Singleton on every change, this would also solve the problem. There isn't any basis for assuming that singletons mean we blindly have to look through every piece of code that references the singleton - that is only the case if we implement the singletons badly.
     44  * I don't agree that logging debugging is a solution for a flawed architecture. Especially, a log on localhost or test.bw might not reveal problems you get on production, due to some other global state.
     45  * And, the problem is not only the global write access, but also global read access. If you change the singleton, you will have hundreds of places that break, because they depend on the old behaviour. If you instead change a passed-around object, you can carefully give the new version only to those components which have already adapted to the new behaviour, and give an old version to the other components.
    4246
    4347== Solutions ==