> Concerns are useful when they're genuinely sharing functionality between classes - not just for splitting up "Big Bags O' Methods". Hmmm. I'd say it depends.

> Concerns are useful when they're genuinely sharing functionality between classes - not just for splitting up "Big Bags O' Methods". Hmmm. I'd say it depends. Of course having concerns (a fancy word for modules IMHO) shared between classes is great. But i've also found cases where separating a god class' behaviour into different concerns helped a lot. The important thing in those cases was recognizing and avoiding dependencies between different concerns, so instead of ending up with a god class split across many files of inter-dependant code (i.e. worse than before), you can end up with a "god" class split into its minimal "core" part and a couple of concerns that only depend on that core part but not between each other. Yes, you could still call that a god class, as it will have a very fat public API, but at least you can reason about what it does in terms of different concerns, so you gain something :)