Changes between Version 5 and Version 6 of DependencyInjection


Ignore:
Timestamp:
Apr 25, 2008, 7:27:32 PM (10 years ago)
Author:
lemon-head
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DependencyInjection

    v5 v6  
    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.
    3636   * 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.
     37    * Not really, or not always. Consider an object $dog of class Dog, that is passed around to different components. The function $dog->action() will make the dog bark. Now you introduce a DogThatBites, where the action() command causes the dog to bite. You decide that some of your components should use the DogThatBites, and the others get a DogThatBarks. You don't have to change any of your components, because it all works with the $dog->action() method. Ok, sounds a bit hypothetical, but that's the nature of these stupid examples..
    3738
    3839=== Side effects ===
     
    4344
    4445 * 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.
    45   * 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  * I don't agree that logging or 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.
    4647   * 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.
     48    * well, your argument was that we do some debugging to keep track of global state changes. So, if we avoid global things (or reduce them, at least) in the first place, we don't need the debugging. I disagree with the argument to introduce or defend something that could eventually cause problems, and then say it doesn't hurt thanks to our debugging and logging.
    4749  * 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.
     50   * 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?
     51    * That sounds quite dirty to me! A component's behavior should not depend on the calling component, unless it is given as an argument.
     52   * 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.
     53    * Sure, that would usually be the quick way to solve the problem, and to get around big code restructuring.
    4954
    5055 * 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).
     56  * One example was PApps (or was it called like that?). It's a PT class, so I don't want to touch it. It used to be responsible for finding an application controller for a given request string. Now the nasty thing about PApps is that it only accepts controllers which are a direct subclass of PAppController. This sucks, because I wanted to introduce a layer in between, class RoxControllerBase extends PAppController. The singleton nature of PApps makes it hard to do customization by subclassing, so I made a new component doing this job (RequestRouter). I don't know if this is the best example, but it's the one I currently had in mind.
     57  * In general we have less problems with singletons we write ourselves.. because we can always change them.
     58  * And I agree the singleton isnot the most evil thing we have. Far worse are classes which grow too big.
     59
     60
    5161
    5262== Solutions ==