This morning I began writing a minimal chat using Java socket and threads but it took some minutes for me to experience a lot of problems in the MVC management.

Currently I have 3 classes:

  • Main, this is just the main class used for starting the Control.
  • ChatController, I use this for managing Model and View classes (this is a Controller class).
  • Host, a class containing a Socket attribute and two Scanner and PrintStream attributes for reading and writing to and from the socket.

The problem here is which class extending from Thread to let the program both read and write features concurrently. My professor told me to extend the ChatControl (hence, the Controller) class, but I think it is too much hard-coding (and also, I don't like the method/attributes inherited from Thread to be visible from the ChatController class).

So, is it correct extending the Control class from Thread for managing the thread or should I consider to implement another class for tasking this problem (or even trying some other patterns)?

If you need some source, find it on pastebin.

  • This is a good question, but you'll quickly find that patterns are not the end all solution to every problem, nor even most problems.
    – Ampt
    Commented Oct 1, 2013 at 16:12
  • 1
    Extending Thread is almost always a bad idea. You probably want to implement Runnable. Commented Oct 1, 2013 at 19:31
  • MVC vs. threads isn't really your issue, here, but what about using a Mediator to tie the socket code to the MVC portion? Commented Oct 1, 2013 at 19:32

2 Answers 2


Since it seems you are limited to MVC (re: comment from professor), you may want to look at this from a slightly different direction. Consider a chat received and chat to be sent as "events" that the controller must process and dispatch. The controller can have two queues. One for processing received chats and one for sending them. The network code feeds into and out of these queues. That's at least how I would look at it because it makes the threading a little simpler to handle.

  • So, are you saying I could implement two classes inheriting from Thread which I'd use for read and write?
    – Acsor
    Commented Oct 1, 2013 at 16:42
  • As @David Ehrmann said, you generally do not want to extend Thread. Instead you should create classes that implement Runnable. Then feed them each to a thread. One runnable would handle the socket connections. It would receive data from a socket and place it on a queue on the controller. Another runnable (possibly handling the controller itself) would take the data off of the queue and update the model. Then just do the reverse for sending data.
    – babernathy
    Commented Oct 1, 2013 at 20:13
  • And what about managing the runnable classes? Don't I need as many Thread classes as the Runnable ones?
    – Acsor
    Commented Oct 2, 2013 at 13:08
  • Yes, you will need one Thread class per Runnable.
    – babernathy
    Commented Oct 2, 2013 at 13:31

A Similar Exercise

What I did for an exercise using MVC, Sockets, and multiple threads was to first develop what I called the "models". This exercise was called Echo Client/Server because all that the server did was echo what each client sent to the server, back to the client that sent up the message.

My exercise was a little simpler than a chat exercise, but the two exercises are very similar in nature.

My classes:

  1. The EchoServer class, the model for the server side with absolutely no user interface.
  2. The EchoServerDaemon class, just a class with a main() method to create an EchoServer object and start a thread for it, one view
  3. The EchoClient class, the model for the client side with absolutely not user interface
  4. The EchoClientConsole, a console view of the client's input/output
  5. The EchoUtils class which contains anything that the EchoServer model and the EchoClient model need, such as the default port number.

I could have added classes such as the following classes without much work because the model classes EchoServer and EchoClient were independent of their user-interfaces:

EchoServerConsole, a server with a console view EchoServerGUI, a server with a GUI view or EchoClientGUI, a client with a GUI view

  1. I got the model done first.
  2. Then, I got the views specified.
  3. I did the controllers last, connecting the model and the view.

I believe that having multiple threads for a server is pretty much mandantory.

On the server, I had a class with one thread which I called the ConnectionListener which is an inner class of EchoServer. The ConnectionListener mainly calls serverSocket.accept() and creates connections.

I also had a thread for each connection called ConnectionServicer. Each client connection was serviced by a separate ConnectionServicer thread so that the server as a whole could call read() and write() and if the thread blocked, nothing else would freeze.

I don't think that the client needs a separate thread unless you're doing something time-consuming such as downloading a large file.

If you want me to make my source-code available, let me know.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.