Re:Why you should never ever ever have Managers in your clas...
by azov on Sunday March 31, 2013 @09:32PM
(#5470977)
> the purpose of ThingManager is perfectly clear--to manage miscellaneous or common functionality
Ironic, isn't it? :)
PS. Don't get me wrong - a Manager, or Util, or Helper is not the greatest crime against software design. The intention here is clear, functionality - no, not really. However engineering is about tradeoffs, and it is sometimes practical to have a dumping place for miscellaneous stuff. Just keep in mind that it is a "be careful" territory, those places do tend to turn into ugly and hairy mess over time.
Re:Why you should never ever ever have Managers in your clas...
by sha90 on Sunday March 31, 2013 @11:10PM
(#5471230)
It's not that it "doesn't belong in Thing", but rather, it can be performed by another entity. These are the same fundamental "responsibility" questions we struggle with in designing OO systems every day. When you have two or more entities collaborating on a responsibility, which one of them get the actual method? Incidentally, this is kind of what real life managers are for too, as much as we like to dislike them.
For example, we're using a legacy codebase now where there is some complicated logic involved in managing attributes for products. ProductService is a singleton with no internal state that does things like removeAttribute(product, "foo") and serves other purposes. Before we introduced this pattern this kind of functionality was copy-pasted all around our controllers.
In short, I don't see the harm in this convention. Perhaps Manager or Service is bland name, but it's immediately clear to our developers what it does, and if you want to see if something has been done before with products, you look in Product or ProductService.