Changes between Version 4 and Version 5 of DependencyInjection


Ignore:
Timestamp:
Apr 25, 2008, 2:48:39 PM (11 years ago)
Author:
fake51
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DependencyInjection

    v4 v5  
    3434  * 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.
    3535  * 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.
     36   * The point about the PT lib is fair, however: if at any given point you have 225 code-pieces that uses a given class and you want to change the 120 of them ... you'll have to change the 120 of them. Unless you start decoupling things through the use of a registry or perhaps a factory. The point is, it's not the singleton that gives you the problem, it's the fact that you're using one thing in 225 places but only want to use it in 120 places.
    3637
    3738=== Side effects ===
     
    4344 * 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.
    4445  * 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.
     46   * What flawed architechture? The articles cited do not prove singletons as bad in themselves and neither have you. To the contrary, if used right they serve their purpose great. Also, "Especially, a log on localhost or test.bw might not reveal problems you get on production, due to some other global state." goes for ALL DEBUGGING! That again relates to debugging as such, not to singletons. In other words, if debugging doesn't show the problem on different platforms, switching to something else than singletons is not going to help.
    4547  * 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.
     48   * That supposes you know which components have changed. If you do know this, would you not also be able to change the behaviour of reading vars so you call a function to get a var, and the function determines if the caller is the new version or not? Or, you could implement a new method in the singleton, keeping all the old functionality but adding new that new objects can use - designing it better this time. Again, the point is, singletons are simply not bad in themselves - it's a question of how they're used.
     49
     50 * This being said, there's a very good point to considering other patterns for NEW functionality. But before going back and redesigning everything, perhaps we should consider whether it's worth doing just because some articles are against the use of singletons (how many actual bugs do we have that relate to singletons? How much have the singletons slowed productivity down? I haven't spent enough time with the code, so I'd really like to see concrete examples of how the singletons have given us problems).
    4651
    4752== Solutions ==