Classes have wide interfaces for a variety of different reasons, and the appropriate fix is different in each case:

• The class may be too large in general, and taking on more responsibilities than it should (see [Martin] for more on responsibilities). In this case, the solution is to identify each of the different responsibilities the class is taking on, and split it into multiple classes, e.g. using the 'Extract Class' refactoring from [Fowler].
• There may be lots of duplication within the class itself, that is, the actions of some of the public functions may overlap. In this case, the solution is to redesign the interface so that each new public function has a single, unique responsibility.
• The class may be quite small at the implementation level, but trying to provide its user with a wide range of 'utility' functions that don't actually need to be part of the class. (A classic example of this is the std::string class in the C++ Standard Library.) As [Sutter] observes, there are at least two key problems with this approach:
  • It may be possible to generalize some of the utility functions beyond the narrow context of the class in question -- by bundling them with the class, the class author reduces the scope for functionality reuse.
  • It's usually impossible for the class author to know every possible operation that the user might want to perform on the class, so the public interface will inherently be incomplete. New utility functions will end up having a different syntax to the privileged public functions in the class, negatively impacting on code consistency.
  To refactor a class like this, simply move its utility functions elsewhere, paring its public interface down to the bare minimum.
• The class may be a base class in a badly-designed inheritance hierarchy. Such classes have many public functions to support features that are only used by one or two of their descendants. In this situation, the solution is to redesign the hierarchy, possibly by refactoring it into a component-based architecture.