This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I'm using the same Dialog (actually JFrame) for getting the configurations for all modes: stand-alone mode, network-client mode, and server mode.
For each mode, I hide some fields (the unused fields) and show others.
For example: -In the stand-alone mode, I show the "file-location" field, and hide the "port" field and the "server IP" field. - In the server mode, I show the "file-location" field and the "port" field, and hide the "server IP" field.
Is this a bad design?
Would it be better to implement two dialogs, one for the client modes, and one for the server mode, so that changes for one side will not affect the other?
In my gui design, I have a common gui abstract class, which defines many common facilities for the subclasses. for example client gui extends this common gui and do the presentation specific for the client. Among the child classes, there are local dialog and rmi dialog, while the JFrame itself and other fields are defined in the common gui. I think this follows spirits of OOD, if not good enough. For the user inputs of either rmi, local, or server, I only need two fields: host, and port in the common gui.
Just read more about your posting. I think the client, server dialogs by themselves are different objects, so they deserve their own entity (class). That is I have local and rmi dialog. However, for the server with limited functionalities, I combined its dialog with its main window. [ December 19, 2004: Message edited by: Andy Zhu ]