• Post Reply Bookmark Topic Watch Topic
  • New Topic

Should you code with the GUI in mind?  RSS feed

 
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I want to write a programme which might have 40 or so classes.

The problem is I have pretty good idea of the classes and what they should do but am not solid Swing wise so am considering putting the GUI aside for now.

Can I just write the code and ignore the GUI and then work on the GUI later?

Perhaps more specifically my question is how professionals deal with this problem? Is it easy to create a GUI for code that otherwise works or should one code with the GUI in mind?

Many thanks.
 
Bartender
Posts: 3648
16
Firefox Browser Java Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well it depends what your app do. Say it is a client/server app. The client is the GUI and server is the business logic then you don't need to bother with the GUI until you work on it.

If it is basically a GUI app then knowing how each component interact with what will be important. Under such cases then yes you do need to mind the GUI.

IMHO doing GUI or Swing classes, I tend to have each component in its own class eg MenuBar, XXXAction, XXXPanel. Such that messing up in 1 thing won't break the app.

Don't know what your 40 or so classes are or how they are packaged.
 
Rancher
Posts: 2762
32
Eclipse IDE Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you are making any program that is medium to large sized, you should design first and program second. You should design with "use cases" in mind. and when you are doing the design you figure out what the components will be and what the interactions between the components will be. "GUI" will be one of several components, and hopefully if you have done your design well, then on paper, you will be able to see how your GUI is going to interact with the user and the service layer. Now, at this point, you can choose to implement a component at a time. You have defined the interfaces between components during design, and only when your interfaces are well defined should you start coding to those interfaces.

So, tl; dr answer to your question:- Yes, not only should you code with GUI in mind, you should code with everything in mind:- GUI, database, hardware resources, etc etc; and the best way to do it is to design first, code second.
 
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Primrose Smith wrote:Can I just write the code and ignore the GUI and then work on the GUI later?

At the risk of sounding like I disagree with my esteemed colleagues (I don't, BTW): Yes.

Or, more specifically, what you should do is to separate, as much as is humanly possible, your GUI - or input/output - logic from your application logic.

The best analogy I can think of is a chess game. The logic involved in playing the game (the board, pieces, how they move, threats, checks, etc.) has been around for a thousand years - long before the advent of computers and screens and buttons and mice. The GUI is simply how you display the state of the game and accept input about where to move the next piece. You should therefore be able to write a ChessGame class that can run with a GUI, or a terminal (character display and keyboard), or indeed a client browser that isn't even on the same machine.

The best advice I can give you is that your application should almost never include classes that begin with a 'J' (JPanel, JComponent and the like).

However, as Jayesh said, that doesn't mean that you shouldn't think long and hard about what your GUI is going to look like. Just maybe not yet.

HIH

Winston
 
Marshal
Posts: 56600
172
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Winston Gutkowski wrote: . . . At the risk of sounding like I disagree with my esteemed colleagues (I don't, BTW): . . .
Because they are both right.
You should design your classes with a public interface. Then you can use that public interface to put a GUI atop it.
 
Author and ninkuma
Marshal
Posts: 66307
152
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Think this way: if your business logic is properly sequestered behind an API, it should be able to be used with a Swing front end, a web front end, or a command line front end. If that can't happen, you've let the UI seep into the business logic, or vice versa.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bear Bibeault wrote:Think this way: if your business logic is properly sequestered behind an API, it should be able to be used with a Swing front end, a web front end, or a command line front end. If that can't happen, you've let the UI seep into the business logic, or vice versa.

I totally agree with what you say but, playing the Devil's Advocate, is there not something to be said for at least looking at the visual side early on?

I ask because my background is classic business apps - lots of reports, lots of data, lots of structure and procedure and admin - and I've never had to deal with something like developing a video game.
And I wonder if the guys that like the visual stuff might not be very useful in telling you what can (or, maybe more importantly, what can't, or shouldn't) be done at the design stage.

One of the best apps I ever wrote was when I had a good "visual" guy (girl, actually) working for me. I supplied the M and the C, and she supplied the V; and we'd meet every few days to dovetail what we'd written. Unfortunately, she was a fair bit junior to me, so my "vision" usually won out. I now wonder if it might not have been better to let her into the design process a bit earlier, because she was very good.

Winston
 
Rancher
Posts: 989
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bear Bibeault wrote:Think this way: if your business logic is properly sequestered behind an API, it should be able to be used with a Swing front end, a web front end, or a command line front end. If that can't happen, you've let the UI seep into the business logic, or vice versa.

This. Read up on the Business Delegate pattern for an example of how to do it. You should also design where you will have SwingWorkers before you start coding. It's very important to get the service calls interaction right without freezing the EDT and understanding that and designing for it early is a good way of avoiding headaches later.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!