Gary Dusbabek racontait le 03/06/2014 19:59: > This has come up before. Let's face it, removing the singletons is a > tempting proposition. > > Several of us have been down the path of trying to do it. > > At the end of the day, here's what you'd end up with (absolutely best case): > > 1. Modifying just about every class, sometimes substantially. > 2. A huge patch for someone else to review. > 3. No performance gains, no bug fixes. In fact, since so many classes have > to be changed, I'd say that the risk of introducing a bug/regression is > fairly likely. > 4. Complicated merges when bugs need to be fixed in older versions. > 5. More modular and testable code. > > So far, the positive aspects of 5 have not been able to trump the > challenges presented by 1, 2, 3, and 4.
Thanks for your reply. I understand the reasoning, yet obviously I think your 5th point weighs a lot more than the others, because it also means more hackable code, and though a huge patch might be scary, seeing so many static fields is scary as well ;). We could make the patch more manageable by splitting it in several patches, one per 'service', and start from the leaves of the dependency graph (services not using other services), but we'd have to apply the patches in a specific order. Still, it would make it easier to review. The 3rd point is I guess usual in the life of an healthy project: fixing the 'technical debt' the project accumulated over the years seems almost as important as fixing bugs and improving performance. While doing it, we would also port the tests and hopefully introduce new tests to make sure we didn't introduce bugs, and generally be careful we don't break anything. Yes, there might be new bugs, probably the kind of bugs that are already there but lurking because of the initialization order or relying on specific side-effects, but those already exist and might pop out any time. Refactoring this code seems, for the most part, to be a fairly repetitive process and doing it carefully should allow to avoid most bugs introduced by inattention. The (4) is an important problem, but merging this would probably mean a major version bump (e.g, within the 3.0.0 branch), and at some point in time, older versions will reach their EOL. It seems to me that only bug fixes are backported, and the patches already have to be adapted for the 1.x branch... But unless people give up entirely on the idea of fixing this, this problem is going to become worse as time goes by. Cheers, Simon > Kind Regards, > > Gary. > > >> >> Cheers, >> >> -- >> Simon >> >> >> [1] >> >> http://grokbase.com/t/cassandra/dev/107xr48hek/creating-two-instances-in-code >> >
