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, i.e. some of the public methods may be doing overlapping things. In this case, the solution is to redesign the interface so that each new public method 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' methods 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: 1. It may be possible to generalize some of the utility methods beyond the narrow context of the class in question -- by bundling them with the class, the class author reduces the scope for functionality reuse. 2. 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 methods will end up having a different syntax to the privileged public methods in the class, negatively impacting on code consistency. To refactor a class like this, simply move its utility methods 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 methods in order 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.