Timeline for Java: Is it okay to abuse Spring beans (@Component) rather than use static final utility classes?
Current License: CC BY-SA 3.0
23 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 9, 2018 at 22:12 | history | edited | Robert Harvey | CC BY-SA 3.0 | deleted 10 characters in body |
| Feb 9, 2018 at 20:44 | history | edited | Robert Harvey | CC BY-SA 3.0 | added 377 characters in body |
| Feb 9, 2018 at 20:44 | comment | added | Laiv | That's It :-). I thougth this could improve your actual answer. Thank you. As usual, very insightful. | |
| Feb 9, 2018 at 20:41 | comment | added | Robert Harvey | @Laiv: Classes have a very specific purpose. If you need that purpose, by all means use a class. But if you don't need it, why use it if your only rationale is that you can't apply your usual class-testing techniques? The remedy to that is to learn a more suitable testing technique, not shoehorn your method into a class just because you think you need a container to test it in. | |
| Feb 9, 2018 at 20:38 | comment | added | Laiv | I Agreed. But I guess the OP is wondering why don't replace static methods by single imstances of a class. Regardless testability | |
| Feb 9, 2018 at 20:36 | comment | added | Robert Harvey | @Laiv: Most TDD advocates claim that static classes are bad because you can't inject dependencies into them (mocks, stubs, etc.), but that's not really true. The method parameters are the dependencies, and calling the method with those parameters is the purest form of DI. I know that doesn't answer your question directly, but... | |
| Feb 9, 2018 at 20:33 | comment | added | Laiv | @RobertHarvey I think I know what is going to be the answer but, would you mind to answer the question when is It too much DI?. I think It would complete the actual answer. | |
| Feb 9, 2018 at 4:12 | comment | added | Thiyagu | @RobertHarvey The main problem I used to face in such situations (as mentioned by @Maybe_Factor) is that you have to make sure you pass data to the SUT that calls the static method so that the static method gets called with data that is required for it to operate properly. Example - I have to make sure that no mocks are passed to the static method - if yes, I have to stub those calls.. If a collection is passed, have to take care of the preconditions that the static method imposes (maybe the collection must be of size x). So all these adds up to the complexity of testing the current SUT. | |
| Feb 8, 2018 at 17:13 | comment | added | Robert Harvey | @DavidPacker: Using Date functions that return unpredictable results within a static method is not what I consider pure. Use the Date class method overload that produces the correct result. (in .NET, it's the one that returns January 01, 0001, or the many others that produce a predictable result from a set of predefined input values). | |
| Feb 8, 2018 at 17:07 | comment | added | Andy | So are database engines, in most cases, Robert. And you don't want to have a static dependency on them either. The problem I have with dates is that calling a new Date with no arguments will usually yield two different values. Which is unpredictable and makes unit testing more difficult. | |
| Feb 8, 2018 at 16:25 | comment | added | Robert Harvey | @DavidPacker: Presumably, the OS is already trustworthy. | |
| Feb 8, 2018 at 16:13 | comment | added | Robert Harvey | @Maybe_Factor: [the problem is that] the unit test for the code calling the static method inevitably also tests the static method -- I don't understand what you meant there. Isn't the whole point to test the static method? | |
| Feb 8, 2018 at 7:51 | comment | added | Andy | I agree that static does not necessarily mean evil, however I personally disagree the creation of a Date object should be delegated to a static method. IMO a factory should be provided in its place, because dates have a dependency on the underlying system used for date generation. | |
| Feb 8, 2018 at 6:28 | comment | added | Laiv | Agreed. That's what makes serviceLocator so infamous. But while a service is a good candidate for IoD, utilities are not necessarily. The last is implementation details. IMO. | |
| Feb 8, 2018 at 6:07 | comment | added | Maybe_Factor | The problem with static methods and unit testing isn't that the static methods are harder to unit test, it's that the unit test for the code calling the static method inevitably also tests the static method. For those pure, simple static methods (e.g. methods in java.lang.Math), it makes sense that these are static, but for anything more complicated, I'd make it an proper object so it can be easily mocked for unit testing of calling code. | |
| Feb 8, 2018 at 1:39 | history | edited | Robert Harvey | CC BY-SA 3.0 | added 23 characters in body |
| Feb 7, 2018 at 23:12 | history | edited | Robert Harvey | CC BY-SA 3.0 | added 181 characters in body |
| Feb 7, 2018 at 21:55 | history | edited | Robert Harvey | CC BY-SA 3.0 | added 58 characters in body |
| Feb 7, 2018 at 21:50 | comment | added | Robert Harvey | Yep. Forgot about purity (added it to my answer). | |
| Feb 7, 2018 at 21:50 | history | edited | Robert Harvey | CC BY-SA 3.0 | added 75 characters in body |
| Feb 7, 2018 at 20:38 | comment | added | Laiv | In addition to this answer. Take a look at Apache Commons. Many of their libs are Utils (mostly). And a lot of these Utils have static methods. The codebase can be checked out, compiled and unit tested. Start with Common-io, common-collections, etc. If methods are pure, they are unit testables. If they don't they still can be tested, up to a point. | |
| Feb 7, 2018 at 20:25 | history | edited | Robert Harvey | CC BY-SA 3.0 | added 13 characters in body |
| Feb 7, 2018 at 20:20 | history | answered | Robert Harvey | CC BY-SA 3.0 |