When considering what things meet the definition of a word, we could consider only things that definitely meet the definition of the word, or only those that meet the definition of that word more than any another. For example, one degree centigrade has a definite definition, but we speak of something being a hill only if it is not more like a mountain.
The division of labour in classes is ultimately a semantic consideration, as a class will absorb all code that is within its meaning. So the decision just described will affect the kind of class you get: spartan or helpful.
A spartan class contains only the methods that are strictly within its meaning, and has a very flexible interface to accommodate any possible use. Spartan classes are easier to reuse.
A helpful class contains methods that help it interact with particular other classes and exchange data. Helpful classes make it easier to find a method you're looking for, because you always look in the closest semantic domain first.
Example: when storing an array of customers, it would be spartan to use a basic array of customer objects, but more helpful to have a CustomerArray? with cross-reference methods.
The other difference is that spartan classes support the implementation of any policy, while helpful classes typically hide a lot of methods and data in order to implement a particular policy. Loose coupling can be achieved with helpful classes by having an object be introduced to the objects it has to work with via its constructors.
Suggested design: build spartan classes to provide a supporting role, but cement the overall design together will single-purpose helpful classes.