3 ms·
In my experience "swapping out an alternate implementation" happens so rarely that it isn't really worth the additional architectural complexity and making debu
by umanwizard 10y ago
In my experience "swapping out an alternate implementation" happens so rarely that it isn't really worth the additional architectural complexity and making debugging harder.
Seems to me like DI (at least the heavy-handed Spring XML style of it) is a solution looking for a problem, but I've only worked at one company that used it heavily so I'd be happy for people to try to change my view.
- niftich 10y ago"Swapping out an alternate implementation" sometimes means you shipped a bunch of components and the customer (who is not you, and doesn't necessarily have a direct line to you) can configure their software to enable or disable features. By having externalized some of the tight coupling into some config file (like Spring's XMLs), they can go in and say that the AuthorizationFilter is OAuth20Filter instead of OAuth10Filter, or maybe their CookieParser is StrictRFCCompiantCookieParser instead of the WhateverGoesCookieParser. The same would be doable if you compiled all this into code and only exposed some different config parameter that says "enforceRFC6265Cookies=true/false", but then the customer couldn't use some consultant company's SuperSpecialCustomCookieParser class in its stead, whereas with Spring they can. But say none of this applies; DI is often used in testing. You can inject a mock class with next-to-no effort without having to figure out what to do about all of those StorageManagers whose hardcoded dependency is your ActuallyRealDatabaseStorageManagerImpl.
- mavelikara 10y ago> In my experience "swapping out an alternate implementation" happens so rarely that it isn't really worth the additional architectural complexity and making debugging harder. It happens all the time if you test your code with mocks and stubs.