I'd lean on the side of many classes with narrow, well defined responsibilities, with equally narrow interfaces (by which I just mean the set of public members). This doesn't mean that a class cannot facilitate "multiple things" to happen by delegating to contained classes (or even to virtual methods of child classes), it's just that the responsibility of that class is to "orchestrate" a process - the pitfall there is if you try and make the orchestrator class have a "pass through" interface, exposing "for convenience" the underlying stuff (doing that defeats its purpose).
↧