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.
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 <item>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 :)
Don'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.
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 <item>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 :)
ConnectionPool, ConnectionInstances, ConnectionLimiter... etc, it depends. There isn't always a great option or it's very difficult to find one.
Underrated