Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #10074
| From | markspace <-@.> |
|---|---|
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: Baseline GUI Architecture |
| Date | 2011-11-19 15:27 -0800 |
| Organization | A noiseless patient Spider |
| Message-ID | <ja9e0e$v1e$1@dont-email.me> (permalink) |
| References | <36dd636c-d9eb-4f75-8610-40ff6dbe3991@n35g2000yqf.googlegroups.com> <GUI-architecture-20111119232944@ram.dialup.fu-berlin.de> |
On 11/19/2011 2:32 PM, Stefan Ram wrote: > Newsgroups: comp.lang.java.help,comp.lang.java.programmer > Followup-To: comp.lang.java.programmer > > Davej<galt_57@hotmail.com> writes: >> Ok, I've written command line code that way, but surely you don't >> begin a desktop GUI project with nothing but an empty Main class. What >> do you start with? Is there a standardized prototype? Thanks. > > I have an approach, that seems natural to me, but then also > has some problems: This seems like normal object orient analysis and design to me. You don't have to call those concepts appjects, calling them objects would be a perfectly workable term. I'll also add that for Java, there's some consensus that the NetBeans platform makes a good start for larger application. (For small ones, roll-your-own seems the preferred approach.) > This is straightforward, but there also is a problem: I would like to > add commands for the sub-component to the main application menu. So I > need to define how a components menu is merged into an application's > menu. I need to specify interfaces for this. I believe a Mediator pattern could help here. Mediator simplifies interaction between objects, and also loosens coupling. The basic idea imo is to make an object that injected into each large subsystem or "appject" in your application, which that system or appject then uses to communicate with the rest of the app. I call this Mediator object an ApplicationContext. It provides services such as access to the GUI, persistence, command line properties/configuration, etc. whatever the app needs. It's all in one place and it's injected so testing is now much easier. I think this works better than using static factory methods, which get embedded into your code and can represent undesirable "global" objects. The ApplicationContext can get unwieldy and turn into a God Object if you're not careful; keep it's interaction at a high level and push all of the functionality into the services that it just hands around to different objects.
Back to comp.lang.java.programmer | Previous | Next — Next in thread | Find similar | Unroll thread
Re: Baseline GUI Architecture markspace <-@.> - 2011-11-19 15:27 -0800
Re: Baseline GUI Architecture Steve Sobol <sjsobol@JustThe.net> - 2011-11-19 15:35 -0800
Re: Baseline GUI Architecture markspace <-@.> - 2011-11-19 15:58 -0800
Re: Baseline GUI Architecture Arne Vajhøj <arne@vajhoej.dk> - 2011-11-19 21:18 -0500
csiph-web