Well, yes, but no, but yes. A counter example of a good bag of function is every languages Math static class. Also it is quite viable to have a bag of data an

Well, yes, but no, but yes. A counter example of a good bag of function is every languages Math static class. Also it is quite viable to have a bag of data and multiple different classes which have algorithm which operate on that data. Those algorithms should not be trivial (but there is no good definition of what trivial is or isn't). If you toss all those algorithms into the bag-o-data class you will wind up with a massive class which changes under too many circumstances and clearly violates separation of concerns. If you have a three line function that should clearly not go into its own class. If you have a dozen methods that implement an algorithm on a class, and the private methods don't need to be shared amongst other algorithms, and perhaps you have some private state dedicated to just that algorithm that doesn't make sense to have in the data-holding class, then you should probably extract that into a stand alone class. Where is the actual dividing line? I don't know. Wrestling with it all right now with some code that I've been writing for the past several weeks. It doesn't help that I don't yet have a second algorithm that hits this data, so there's no good dividing line for me between what should be private to the algorithm and what should be public hanging off the data. It is not anywhere near as clear as the author of this blog makes it out to be though. And the algorithm I'm implementing is a Job, which inherits from BackgroundJob as well. The horrors. (I do at least have three different BackgroundJobs now which all need common task handling and cancellation/timeout kinds of logic wrapped around them so that's a bit more clear what that abstract base class should look like).