What is the best implementation once you have decided to use a utility class?
Exactly what you proposed. Create a private constructor, make the class final and implement static utility methods. In such cases, there's no need to make things more complex.
Of course, you must be careful to not falling back into imperative/procedural programming style... just one opinion.
For Utilty Classes for little everyday Problems like Converting Stuff etc is a static class with no constructor the best implementation. Very Handy to access:
Utils.ConvertDateToCake();
My Utility Classes which need an Constructor are implemented as Singletons. So you can access them like this:
发布评论
评论（3）
一旦您决定使用实用程序类，最好的实现是什么？
正是您所建议的。创建一个私有构造函数，将类设为
final并实现static实用方法。在这种情况下，没有必要让事情变得更复杂。当然，您必须小心，不要陷入命令式/过程式编程风格……只是一种意见。
What is the best implementation once you have decided to use a utility class?
Exactly what you proposed. Create a private constructor, make the class
finaland implementstaticutility methods. In such cases, there's no need to make things more complex.Of course, you must be careful to not falling back into imperative/procedural programming style... just one opinion.
恕我直言：
对于像转换东西等日常小问题的实用程序类来说，没有构造函数的静态类是最好的实现。非常方便访问：
我的实用程序类需要构造函数，它们被实现为单例。所以你可以像这样访问它们：
IMHO:
For Utilty Classes for little everyday Problems like Converting Stuff etc is a static class with no constructor the best implementation. Very Handy to access:
My Utility Classes which need an Constructor are implemented as Singletons. So you can access them like this:
实用程序类在 OOP 中是纯粹的邪恶。查看此博客文章以获得更好的解释：http:// /www.yegor256.com/2014/05/05/oop-alternative-to-utility-classes.html
简而言之，实用程序类将过程式编程引入 OOP，使得您的代码可测试性较差，可维护性/可读性较差，并且速度较慢（！）。
Utility classes are pure evil in OOP. Check this blog post for better explanation: http://www.yegor256.com/2014/05/05/oop-alternative-to-utility-classes.html
In a nutshell, utility classes bring procedural programming into OOP, making your code less testable, less maintainable/readable, and slower (!).