Utility Pattern

Intent: For a utility class, which does not require instantiation and only has static methods, use a private constructor. The compiler can then enforce that no instances are created.

http://publib.boulder.ibm.com/infocenter/rtnlhelp/v6r0m0/index.jsp?topic=/com.ibm.r2a.archdisc.doc/topics/rdesignpatterns.html

http://today.java.net/pub/a/today/2006/11/28/PrivateConstructorsSQ15.html?page=last&x-maxdepth=0

http://www.cenqua.com/forums/thread.jspa?threadID=1187&tstart=0

Using all static methods in a utility class supports and enforces the class to have no state. Stateless objects are more efficient and easier to debug and test.[1][2] All utility classes are stateless. Good candidates for utility classes are where there is a grouping of ConvenienceMethods.

[1] http://www.scottishdevelopers.com/modules/newbb/viewtopic.php?viewmode=flat&order=ASC&topic_id=792&forum=4300&move=prev&topic_time=1142942463

[2] http://info.borland.com/techpubs/delphi/delphi5/dg/mts.html

I wouldn't call this a pattern so much as a workaround for the deficiencies of languages (such as JavaLanguage) that don't have proper namespaces. Except in such languages, there is no reason to make a class that will never be instantiated, and so this should generally be considered an AntiPattern. (In RubyLanguage, for example, you'd use a module instead of a class for this purpose. In CeePlusPlus, I think you'd be better off using a namespace, but my C++ is rusty enough that I hesitate to say for sure.) --MarnenLaibowKoser

Your C++ isn't rusty.

CategoryPattern CategoryCreationalPatterns