Win a copy of Rust Web Development this week in the Other Languages forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Ron McLeod
  • Liutauras Vilda
  • Jeanne Boyarsky
Sheriffs:
  • Junilu Lacar
  • Rob Spoor
  • Paul Clapham
Saloon Keepers:
  • Tim Holloway
  • Tim Moores
  • Jesse Silverman
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Piet Souris
  • Frits Walraven

Separate GUI from client in a client-server application?

 
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.)

/Kris
 
Bartender
Posts: 1638
IntelliJ IDE MySQL Database Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This topic suits more for our OO forum where we also discuss system design. Moving ...
 
Ranch Hand
Posts: 276
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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!
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic