GUI Design
I have some questions on GUI design. I'm making an Instant Messenger and, having finished the server, I am now working on the client. I've made many GUIs before -- I'm familiar with swing, awt, and swt --but I feel like my design of GUIs is bad. For this particular project I am using swing.
1) I am thinking about making my "text input" TextArea (the place where the client enters his or her text to be sent to the chat room) follow the Command pattern. I will make a class that subclasses TextArea and implements my Command interface. When an action is performed on it, I will cast the ActionEvent into a command and execute it. My motivation behind this is to use polymorphism instead of heavy control structures such as if-else's and switch statements. My question is whether there are better ways of doing this kind of event-handling. Should I use Actions instead of ActionEvents? Does Swing have better facilities for event handling?
2) I'm going to make a top-level frame class that serves as a controller of controllers. It will process all of the Commands and add all of the views to itself. Is this a good idea?
3) My top-level frame class that I mentioned in (2) will use a Builder/Factory (haven't decided which) to build model objects so that it is not dependent on the models' implementation. Is this a good idea, or is it more trouble than it's worth? Should I just have my controllers talk to models directly? (That is, they are aware of the model's implementation and thus tightly coupled with the model objects.)
4) I have some views that I find hard to separate from their controllers. The example that I am thinking of is my configuration window. It asks the user for the user's username, password, etc. This window will have to inform the model objects when the form is submitted as well as display the user's information from the user's previous session. Thus it acts as both a controller and a view. The one way I can think of separating these two responsibilities is by making the submit JButton follow the Command pattern. So the subclassed JButton will be the controller and the form display will be the view. Is this a good idea?
5) Should I use a visual editor? I've made many GUIs both using a visual editor and not using a visual editor. I specifically use the Eclipse Visual Editor. Do you think that visual editors produce code that hinders design?
Thanks in advance.
[2455 byte] By [
ktm5124a] at [2007-10-2 21:40:12]
1) why, if you extend TextArea and make it implement your command interface, do you expect to be able to cast ActionEvents to your command interface? it won't work. events are just that: they notify that something has happened. nothing more. I haven't used Swing for ages ( SWT :-/ ) so I don't know if it has anything useful in it for you, but how I implement this sort of thing without conditional logic is to have a lookup map of event-action, with an instance of an action class held against each event. the event arrives, I query the map for the action object and invoke it's 'doSomething' method
2) bad idea ( stop looking for ways to fit patterns into your problem btw! ). processing the commands isn't really a job for the UI, the UI thread is too busy checking what the user's doing, and relaying data to the user. giving it extra work to do runs the risk of making your app. run noticably ( by the users ) slower
3) again, you're asking UI code to perform work outside it's remit. constructing objects is a job for another layer. controllers can indeed talk directly to models. that doesn't necessarily make them coupled. if they're talking through an interface, then they are not aware of the implementation, regardless of how many patterns you squeeze into the code
4) despite what you might read, most people don't completely separate view and controller. even most of Smalltalk didn't! how are you planning to "make" the JButton "follow" the command pattern? it's a grimly bad idea, anyway - again making your UI work hard to do somebody elses job. remember that your UI code is running in a separate thread to the normal flow of control for a reason - to keep the UI smooth. giving it too much work will affect usability
5) it's up to you. I still haven't found a visual editor for Java worth using, and in particular the Eclipse one is rubbish, unless, of course, you don't mind having all your UI code in one big class! it's not to say that visual editors hinder good design, just that so far Java doesn't really have any decent ones that I know of
my advice, though, is to remember that design patterns aren't the be-all-and-end-all, by a long way. they're not magic dust you can sprinkle on code and make it all good. you're just looking for places in your code you can fit a pattern or 2 into, that's the wrong approach. if you find yourself twisting code to fit a pattern described in a book, that's an indicator that you don't need the pattern. whatever book(s) you're getting your patterns from are not some exhaustive list of every pattern known to man: discover some of your own, just take note of how, for instance, the GoF does things, in particular, concentrate on how they encapsulate changing functionality. that's the essence of it
My plan was to create a Message object whenever the user inputted text and hit enter out of the message that the user inputted. The message would send itself and then be garbage-collected. In order to do this, I will have to do on-the-spot construction. So should I create a new thread (rather than using my GUI thread) for event-handling and have the thread create the Message when the user hits enter? I've always had my GUI thread be my event-handler in all of my programs involving GUIs.
The reason why I thought of using the command pattern is because people always say that huge if-else blocks and switch statements in event handling is a sign of bad design. I wanted to use polymorphism to better my design, and the command pattern seemed fitting. I thought that the modular solution was to just to have each of my controller components do their own listening and event handling, e.g.:
submitButton.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent aEvt) {
...
}
});
or
class MessageController extends JButton implements ActionListener {
public void actionPerformed(ActionEvent aEvt) {
...
}
}
Well, I've been rambling, so I'll summarize:
1) Should I really create a new thread for event-handling separate from the GUI thread? Is the already-existing event-handling thread the same thread as the one that keeps the GUI running? If not, I see no point in making a new thread for event-handling. (By event-handling, I'm talking about constructing messages, users, etc. that send themselves and login themselves based on GUI events such as clicking the submit button, etc.)
2) I'm creating and forgetting Message objects all the time. Either my GUI thread or my (if implemented) event-handling thread will have to do this. So you're saying my event-handling thread should be doing this, assuming that I need my own event-handling thread in the first place?
3) How else can I use polymorphism in my event-handling? Should I have my individual components do their own event-listening and subsequent event-handling or should I lump all of the event-listening and event-handling into one class?
