Client - Server Implementation

[vbx_wx]

Hello ,I want to implement a client server program,but I wish to use more OOP into the design(inheritance,virtual....),I only come up with this design and I nedd some pointers what can I do better,any sugestions will be welcome,Thanx

class TCPSocket {
  public:
    virtual void send(std::string buffer_m) throw(Error);
    virtual void recv(std::string buffer_m) throw(Error);
    void showUser() throw(Error);
    void showForeignUser() throw(Error);
    void create() throw(Error);
    void bind() throw(Error);
    void close() throw(Error);
  };

  class TCPClient: public TCPSocket {
  public:
    void connect() throw(Error);
  };

  class TCPServer: public TCPSocket {
    void accept() throw(Error);
    void listen() throw(Error);
  };

PS: ignore what functions return and what arguments they take.

[mike_2000_17]

I can give a few comments that might be useful..

1. I think you have taken too much of an "externalizing" approach. What I mean is that these functions like connect, accept, and listen are kind of trivial in themselves and require the user of your socket class to do most of the work (which is to maintain the connection(s)). These functions seem more to me like they should be private (or protected) helper functions, and maybe your interface could be then a bit higher-level and more abstract.

2. The receive function is not correct IMO. TCP sockets are asynchronous by nature. I assume that the receive function will wait for the next string to come and place it in buffer_m. This forces the user make his own event system (because nobody would consider using a TCP socket in a serial fashion). I would suggest you turn the receive function into a callback mechanism at the very least. This way your socket class can take care of the loop that waits for the incoming messages and issue callbacks when a new one has arrived. This will also allow you to extend the class to a socket that uses a thread pool to be able to respond more quickly to incoming messages by relegating the event handling to an independent thread of execution (so that the receiving loop can go back to listening to the port immediately and not wait for the event handler to be completely finished processing the message).

The way you have it is Ok, but I can hardly see the Object-Oriented benefit of it. Most of the functions are pretty atomic and correspond almost exactly to typical C-style functions for TCP sockets, except that you don't need to pass the handle as parameter to the functions (but that is a trivial thing). Ask yourself, what makes it easier to use and more flexible than a normal C-style library for TCP sockets? And what extra capabilities does this offer? Sadly, so far, I see no positive answers to those questions in your design. Maybe you should start by giving an ideal example of how a user would use a TCP socket class (I don't mean example code with function calls, but just high-level "flow-chart" style explanation). That should be a better start towards a more appropriate design. In other words, when you said ",but I wish to use more OOP into the design", I was expecting this to be followed by "because it would bring the benefit of ... and would allow for ... ". Before you put any time into coding, you should fill in those blanks with specific reasons (not just "benefit of modularity and flexibility" or "allows for polymorphism", these are means not ends).

I hope I wasn't too brutal...

[vbx_wx]

No you waren't :) Thanks for responding