Since no-one seems to know why my sockets are working, thought I'd revisit my socket classes and see what I've learnt over the pas couple of years
I have a base socket class, which handles the reading and writing of data to the actual socket handle. I also have a "Client" and "Server" socket class.
"Why ?" I hear you ask. Well, both server and client need a socket, and a server spawns more sockets when a client connects. The default behaviour of reading and writing is common to both types, so there is a "base" class. The connection of a socket is handled by either the client or server class as appropriate.
Now, should the server and client socket inherit the base class, or should they create a "new" base class when they are instantiated ?
Since no-one seems to know why my sockets are working,
... and you're complaining?
Sounds like you have a SocketServer (or -Broker) and a Socket thingymajig going on.
-- peter
It has been a while since I did any work with sockets, so I am a bit rusty on the details of what you are doing here, but let me tell you what my thinking is.
One of the really good ways to think about decomposing a problem space into classes is in terms of set theory or Venn diagrams. I.e., if one has a collection of problem space entities that have the same knowledge and behavior attributes, that's a class. If you have two or more such classes which share some knowledge and behavior attributes, but have others attributes that they don't share, that is an indicator for Generalization. Of course, it is often possible to decompose the same problem space in more than one way, so that is where the "fun" comes in.
While I understand that both client and server both need to read and write, thus sharing knowledge and behavior, which would support the decomposition you have made, I can also see that one could think each was a very different area of responsbility, which would argue against using a supertype. What then would one do about the common parts? One possible answer would be to solve the problem with composition rather than generalization. If you can put the common knowledge and behavior into its own class which both use and put the remaining unshared knowledge and behavior in one or more other classes, then you could create a client or a server by composing the appropriate set of smaller objects. I think that, if this is possible, it is actually a better solution because the individual classes are smaller and simpler and you should have some flexibility in the composition to create variations in behavior by varying what is in the composition.
Without analyzing the specific knowledge and behavior requirements, I can't say whether that is possible or not, but maybe that will give you a different way to look at the problem.