Re: virtual fn, destructor
On Dec 15, 10:31 pm, Paavo Helde <pa...@nospam.please.ee> wrote:
James Kanze <james.ka...@gmail.com> kirjutas:
It's not pessimism, it's design. A class can't be
everything to everyone; it can only be what it was designed
for. If I design an interface Socket, for example, it can't
really be used to implement a window in a GUI system.
It's curious that you chose these exact example classes.
Just the first random idea that came to my mind.
Namely, the MFC library CSocket class is implemented by an
invisible top-level window in the Windows GUI system. So it
seems a window could actually be used for implementing a
socket! (To be honest, not very well, this can easily cause a
lot of problems, like PDF documents not opening any more, or
other random applications getting blocked. I learned this in
the hard way by debugging someone else's code, and I am
allergic to the word CSocket since then.)
In other words, the base class of CSocket makes guarantees that
CSocket can't maintain. A major design error, if this is really
the case. (I know nothing of MFC, so I can't really judge, but
the online documentation says that CSocket derives from
CAsynSocket, which derives from CObject. Which seems reasonable
*IF* you can trust the names; obviously, if CObject guaranteed
that all CObject's can open a PDF document, then CSocket fails.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34