Why you should not have Managers in your class name
karankurani.com
Why you should not have Managers in your class name
1–6 of 6 posts
Re: Why you should not have Managers in your class name
#2Underrated
Re: Why you should not have Managers in your class name
#3Don't think I agree with this.
A "Connection" handles all interaction between two nodes. No argument there.
A "ConnectionManager" handles all the housekeeping to do with the connections - whether there's a limit on connections, whether there's external API that influences behaviour, whether there's resource allocation to split between them and the policy for that, etc. etc. Basically all the things that a more holistic view of the system demands.
There's nothing wrong with a Manager-type class, as long as its task is management of that type. It shouldn't conflate the connection functionality as its own, I agree with that much, but there are two very distinct concepts being modelled here, by different classes.
Re: Why you should not have Managers in your class name
#4Don't think I agree with this. A "Connection" handles all interaction between two nodes. No argument there. A "ConnectionManager" handles all the housekeeping to do with the connections - whether there's a limit on connections, whether there's external API that influences behaviour, whether there's resource allocation to split between them and the policy for that, etc. etc. Basically all the things that a more holist…
There is usually a more precise way to express what a manager manages, so Manager is usually just the lazy option that provides very little information. The question to ask is: What exactly does it manage? Lifetimes? Resource limits? Global configuration? Etc
Re: Why you should not have Managers in your class name
#5Don't think I agree with this. A "Connection" handles all interaction between two nodes. No argument there. A "ConnectionManager" handles all the housekeeping to do with the connections - whether there's a limit on connections, whether there's external API that influences behaviour, whether there's resource allocation to split between them and the policy for that, etc. etc. Basically all the things that a more holist…
There is usually a more precise way to express what a manager manages, so Manager is usually just the lazy option that provides very little information. The question to ask is: What exactly does it manage? Lifetimes? Resource limits? Global configuration? Etc
Ah, but 'Manager' being vague is a feature, not a bug IMHO. Unless there's a 'ConnectionLifetimeManager' (which, to be honest, seems overkill in my experience), then I expect ConnectionManager to handle that. It's the catch-all, not the specific.
The contract I expect it to keep is (as I said above) the holistic view of the system of s that it's managing. That can vary from type to type, but trying to pin down a class to just the exact thing it does is a fools errand (again, IMHO); there is a level of abstraction in naming that is somewhat above the code itself. Manager is the hint, the code is the truth.
YMMV I guess. It's worked pretty well for me for the past 40 years or so :)
Re: Why you should not have Managers in your class name
#6Earlier quoted context omitted.
There is usually a more precise way to express what a manager manages, so Manager is usually just the lazy option that provides very little information. The question to ask is: What exactly does it manage? Lifetimes? Resource limits? Global configuration? Etc
Ah, but 'Manager' being vague is a feature, not a bug IMHO. Unless there's a 'ConnectionLifetimeManager' (which, to be honest, seems overkill in my experience), then I expect ConnectionManager to handle that. It's the catch-all, not the specific. The contract I expect it to keep is (as I said above) the holistic view of the system of s that it's managing. That can vary from type to type, but trying to pin down a clas…
ConnectionPool, ConnectionInstances, ConnectionLimiter... etc, it depends. There isn't always a great option or it's very difficult to find one.