You can create a ConnectionPool class with the relevant logic to manage Connections. If you want multiple pools (which you might connect to different servers ;) ) you just instantiate multiple ConnectionPools.

ConnectionPool makes you think of it as an actual object. ConnectionManager makes you think of this all encompassing thing that handles/manages anything that is Connection related.

The Connection Manager in QT, for example, is not a Connection Pool. It's more of an interface to get at all the classes that represent real things within a connection process (requests, responses, active connections, etc). There is no information in the Connection Manager except system/process defaults. The Connection Manager would create connection pools if that is what's needed but it isn't Connection Pool any more than it is a connection.

That said, I sympathize with the impulse that the term "manager" says there's something wrong in your OO design. It is simply that determining how to get around the problem is hard.

The point that is being made is to make sure that the name of the class makes its responsibilities clear. The problem with the term "manager" or "handler" is that it leaves things ambiguous.

ConnectionPool makes me think of a collection of reusable connections that I can borrow from to talk to a server without the overhead of creating an object and opening a socket, it doesn't make me think of managing at all. Maybe I am doing it wrong?

I'm just hoping for a discussion, this is an important topic for me as a developer.

You got it right. Thats exactly what it should be doing. If you have additional requirements you might want to create another class for that requirement or rename it to something else.

That seems like an incredibly appropriate class name, then. I'm glad I wasn't missing something :)

You still might want a connection manager to contain your connection pools. Or even call it a messages or something, so at the relevant point in the code you just call a send function and aren't exposed to any underlying details of connections.

Specifically, what is the class doing with those pools? "Managing" is vague.

Exactly, it's description of the name of the object, rather than trying to be descriptive of what it does. AutomaticallyRetryingConnectionManager or ConnectionPool{.ConnectWithRetry,etc}

You mean "pool connections" not "manage connections".

Exactly. Maybe a better name would be ConnectionFactory? This could then have multiple ConnectionPools internally for sync vs. async if needed. It's certainly better than polluting the whole code base with the logic required to instantiate an individual connection.

The counter-example given is bad in another way, if you have the max retries on a per-connection basis, you're going to be blocking trying to make connections to an end point that's down. If this state is per-end point, handled by a Manager/Factory/Pool, then you can make the retry logic global.

The main key with rules in software engineering is that it takes experience to know when it makes sense to break them. There's few things that fall in the "never ever" category.