I use a lot utilities (classes whose methods are all statics) inside my Java classes (i. e.: StringUtil, DateUtil and whatnot). Should this practice be avoided in favour of ID?
They are helpers that don't affect to my code, they only transform the input to generate useful output for my logic. Are they fine?
That's a common and excellent question, Abelardo! You're hitting on a key distinction in design.
For utility classes like StringUtil or DateUtil that contain pure static methods (meaning they take input, transform it, and always return the same output for the same input, with no internal state or side effects), they are generally perfectly fine.
They don't introduce mutable global state, which was the main concern of the article, and their stateless nature makes them inherently testable without needing Dependency Injection.
However, if a "utility" method needs to access external resources (like a file system, network, or database) or maintain any internal mutable state, then it's no longer a pure utility.
In those cases, Dependency Injection (DI) would be a much better approach than a static utility, as it allows you to easily substitute dependencies (especially for testing with mocks) and maintain better control over behavior, aligning more strongly with the principles of testability and maintainability discussed in the article.
So, for your StringUtil and DateUtil performing simple, stateless transformations, you're usually in the clear!
Loved the explanation, its very helpful to have the examples that show how avoiding global state in code can make code more maintainable and less prone to bugs!
Thanks a ton for your kind words! 😊 I'm really happy to hear that the explanation and examples on avoiding global state resonated with you and were helpful in understanding how it leads to more maintainable, less buggy code
I use a lot utilities (classes whose methods are all statics) inside my Java classes (i. e.: StringUtil, DateUtil and whatnot). Should this practice be avoided in favour of ID?
They are helpers that don't affect to my code, they only transform the input to generate useful output for my logic. Are they fine?
That's a common and excellent question, Abelardo! You're hitting on a key distinction in design.
For utility classes like StringUtil or DateUtil that contain pure static methods (meaning they take input, transform it, and always return the same output for the same input, with no internal state or side effects), they are generally perfectly fine.
They don't introduce mutable global state, which was the main concern of the article, and their stateless nature makes them inherently testable without needing Dependency Injection.
However, if a "utility" method needs to access external resources (like a file system, network, or database) or maintain any internal mutable state, then it's no longer a pure utility.
In those cases, Dependency Injection (DI) would be a much better approach than a static utility, as it allows you to easily substitute dependencies (especially for testing with mocks) and maintain better control over behavior, aligning more strongly with the principles of testability and maintainability discussed in the article.
So, for your StringUtil and DateUtil performing simple, stateless transformations, you're usually in the clear!
This was a good question. Let's connect Abelardo. I'm also Java developer and I will love to learn more from you…. 🧡
Loved the explanation, its very helpful to have the examples that show how avoiding global state in code can make code more maintainable and less prone to bugs!
Thanks a ton for your kind words! 😊 I'm really happy to hear that the explanation and examples on avoiding global state resonated with you and were helpful in understanding how it leads to more maintainable, less buggy code