Names ending in Manager are usually a poor choice.
See Peter Coad's "-er-er" principle:
> The “-er-er” principle. Challenge any class name that ends in “-er.” If it has no parts, change the name of the class to what each object is managing. If it has parts, put as much work in the parts that the parts know enough to do themselves.
See also: http://www.carlopescio.com/2011/04/your-coding-conventions-a...
Peter Coad advocated against this in favor of modeling the problem domain under consideration using an object oriented approach.
In an object oriented domain model there is no place for such external “controllers”, but I think the commenter doesn’t propose this approach.
Really curious. Do you have any material that explains this way of design?
I work on mostly web apps. End of the day, it's really about moving data and transforming data. So most of my programs have no choice but to deal with data, and so, my whole design process revolves around gathering, storing, operating upon and transferring data.
Why would a TransportMasterManager, which provides factory methods, enumerations, a collection of the current set of TM's, and knowledge of the current user choice for which TM's is being used for what, have "no place" in this design?
> AppDomainAffine, therefore, would be a more appropriate name. Unusual perhaps, but that's because of the common drift toward the mechanics of things and away from concepts (because the mechanics are usually much easier to get for techies)
how is 'AppDomainAffine' not a concept?