Home/ Questions/Q 8191215
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-07T03:52:11+00:00

I’ve seen some people creating a is-a relationship like the following: class TCPClient :

  • 0

I’ve seen some people creating a “is-a” relationship like the following:

class TCPClient : public Socket
{
public:
    TCPClient(const std::string& host, unsigned short port);
};

where the Socket class implements Winsock functions such as Connect(), Close(), Bind() etc.

Examples:

But this doesn’t feel natural to me who is a newbie in socket programming.

Does the above hierarchy make more logical sense than the following “has-a” counterpart?

class TCPClient
{
public:
    TCPClient(const std::string& host, unsigned short port);
    ....
private:
    Socket m_socket;
};
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    A TCPClient uses a socket or has a socket, but is not itself a socket, and you wouldn’t normally expect to be able to substitute a TCPClient anywhere a socket was expected. As such, public inheritance doesn’t make sense.

    You could use private inheritance for this case, but (at least in a typical case) it probably doesn’t make much sense either. Private inheritance makes sense primarily when the base class provides at least one virtual function you plan to override in the child class. If you have a virtual function and need to override it, you have no real choice but to use inheritance. I wouldn’t expect a Socket class to have an virtual functions though; that wouldn’t normally apply here.

    That basically leads to your second solution: the TCPClient should contain an instance of a Socket, rather than using inheritance at all.

    I should add, however, that the Socket class you’ve shown seems to conflate the notion of an actual socket with the notion of an address. My first socket class (years ago) worked about like that, but since then I’ve concluded that it’s not really an ideal design. I’ve become convinced that it’s worthwhile to keep the notion of an address separate from the socket itself. Though mine is a bit less elaborate, I find it interesting that what I came up with looks almost like it could have been the prototype from which Boost ASIO was derived. It’s a little smaller and simpler, but a lot of the basic ideas are generally pretty similar anyway.

    That leads to my next recommendation: take a look at Boost ASIO. Lacking a fairly specific reason to do otherwise, it’s what I’d advise (and generally use) in most new code. Although (as I said above) I’ve written several socket classes over the years, I haven’t used any of them in much (any?) new code in quite a while now — they really only have two possible advantages over ASIO. The first applies only to me: since I wrote and used them before ASIO existed, I already understand them and how they work. The second may be similar: at least to me, they seem a little bit smaller and simpler (but, again, that may be just because I used them first). Even so, the advantages of (for example) using something other people already understand trumps those quite easily.

    • 0