Myself and a fellow student have been discussing whether or not we should separate the GUI (Swing) from the client logic (TCP socket) in our program altogether. She's the die-hard proponent for separate classes for everything among us two, and in general I agree with her ideas that one should always try to separate the GUI from the logic but I also think theres a point of diminishing returns beyond which it causes more trouble than it's worth to try to force a separation. What are your thoughts on this and how do you usually go about designing your client class?
Our approach atm. is pretty straightforward. If we want to send something to the server we simply enter it into a JTextField, press a send-button and the SendButtonListener writes the content to the server using PrintWriter like this:
Is there a better (more OO-friendly) way of doing this kind of thing? Because I can't imagine how that would be done without the code becoming more confusing to read.
(P.S. I know I haven't given much information of the actual application to go on, but I was hoping to make this more of a general question about how far you should take the idea of separating the gui from the logic.)
Kristofer Hindersson wrote:Because I can't imagine how that would be done without the code becoming more confusing to read.
As a start you can put your networking code in a separate class called Client. Hasn't your GUI code become shorter and more comprehendable..?
Is this more confusing than your version..?
but I also think theres a point of diminishing returns beyond which it causes more trouble than it's worth to try to force a separation.
As your application grows, separation of concerns becomes more and more important. Maybe you don't see the gains in a small "toy project", but in a large application with over 100k LoC large classes that try to handle everything from network/disk IO to presentation logic are the coder's nightmare!
OCJP 6 (93%)
subject: Separate GUI from client in a client-server application?