Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #10074

Re: Baseline GUI Architecture

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>

Show all headers | View raw


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 | NextNext in thread | Find similar | Unroll thread


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