Abuse Of Utility Classes

Too many UtilityClasses and too many operations in such classes is one of the ClassicOoAntiPatterns.

A large number of such classes (particularly those with only a single method) indicates that the designers are thinking upside-down, ie. thinking of that which can be done to an object rather than that which can done by the object. -- ChanningWalton

On the other hand, ScottMeyers argues that Non-Member Functions Can Improve Encapsulation http://www.ddj.com/dept/cpp/184401197

In multi-paradigm languages which support both OO and functional styles, the benefits of isolating pure functions are more apparent. While ScottMeyers notes that the use of non-member functions can result in inconsistencies of access, language features such as C#'s extension methods can remove this stylistic drawback.

It is a fundamental breach of encapsulation to give functions more access to private state than they require. Utility methods that are left as members of a class are often granted more access than they require, making it harder to identify and enforce design invariants. If a method's functionality can be expressed in terms of a class's public interface, then writing it as a non-member function increases overall encapsulation.