4 ms·
> (..Manager, ..aggregator,etc.) Names ending in Manager are usually a poor choice. See Peter Coad's "-er-er" principle: > The “-er-er” principle. Challenge
by jonahx 6y ago
> (..Manager, ..aggregator,etc.)
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-are-hurting-you.html http://www.carlopescio.com/2011/04/your-coding-conventions-a...
- aryehof 6y agoI think the commenter generally views things as code acting on entities. If so, that code is suited to being called an xxxManager, or xxxService, or xxxCoordinator, or xxxController. Of course we have returned to a place in history by doing so, of creating big balls of mud as complexity increases. 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.
- kumarvvr 6y ago>modeling the problem domain under consideration using an object oriented 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.
- cryptos 6y agoI don't know Peter Coad, but the approach reminds me of domain driven design (DDD). Most business logic would be in objects named entities, but DDD has also services, since there might be logic that affects multiple entities (actually special entities called "aggregate root").
- aryehof 6y agoPeter Coad did write a number of books, which are pretty old and likely out of print. How to actually model a complex system into an object oriented domain model, is something I have long thought to teach. However, sadly there seems little appetite in a world currently dominated by procedural code acting on data, modeled using functional decomposition or through a relational data model. Of course our industry will eventually relearn the forgotten lessons and methods of the past, rename them as something new, and adopt them as the new silver bullet for software development.
- PaulDavisThe1st 6y agoI have an object called TransportMaster, with concrete implementations X_TransportMaster, Y_TransportMaster, Z_TransportMaster. The application instance may contain any number of any mixture of these objects, and they may be created and destroyed at any time by the user. Their use within the application is also subject to the user's whims. 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?
- nullsense 6y agoOne of my favorite classes in my code base is called something FooBarBazListenerListener
- eatthoselemons 6y agoPerhaps you can explain this part from the post you linked which is perplexing me: > 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?
- danparsonson 6y agoI read that as saying that AppDomainAffine is a concept, and that's why it's an unusual name, because a lot of naming these days focuses on mechanics instead of concepts (c.f. MarshalByRefObject)
- eatthoselemons 6y agoah okay that makes sense I was thinking it was opposite of that which made no sense