Just trying to still get my head around IOC principles.
Q1: Static Methods – Should util classes with static helper methods be wired up with IOC?
For example if I have a HttpUtils class with a number of static methods, should I be trying to pass it to other business logic classes via IOC?
Follow on questions for this might be:
Q2: Singletons – What about things like logging where you may typically get access to it via a Logger.getInstance() type call. Would you normally leave this as is, and NOT use IOC for injecting the logger into business classes that need it?
Q3: Static Classes – I haven’t really used this concept, but are there any guidelines for how you’d typically handle this if you were moving to an IOC based approach.
Thanks in advance.
The funny thing about IoC is that objects written in the style are generally decoupled from those details.
Let’s use the utility class as an example:
In a non-IoC-focused application, you might use that method directly:
However, that couples the definition of
DoStuffdirectly to its implementation. IoC strives to divorce those kinds of details, so instead we define the operation on its own:Then, we leave room in
Foofor the implementation to change:This decouples
FoofromHttpUtils. The implementer of the concept ofDoStuffis now a configuration detail, and not an inherent dependency (as it is with the static method).Notice that
Foohas no idea if itsIDoesStuffis a singleton or not. That lifetime is also a configuration detail, and not an inherent detail ofFoo.To sum up, IoC and
staticare generally at odds, since IoC promotes change andstatic, by definition, prevents it. Declare your dependencies in your constructors, and you’ll find you almost never have you usestaticfunctionality.