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

Groups > comp.lang.java.programmer > #22029 > unrolled thread

Design Patterns

Back to article view | Back to comp.lang.java.programmer

Contents

  Design Patterns dougmmika@gmail.com - 2013-02-02 16:17 -0800
    Re: Design Patterns Arne Vajhøj <arne@vajhoej.dk> - 2013-02-02 19:39 -0500
      Re: Design Patterns Marcel Müller <news.5.maazl@spamgourmet.org> - 2013-02-03 18:52 +0100
        Re: Design Patterns Lew <lewbloch@gmail.com> - 2013-02-03 14:23 -0800
        Re: Design Patterns Arne Vajhøj <arne@vajhoej.dk> - 2013-02-08 23:57 -0500
          Re: Design Patterns Lew <lewbloch@gmail.com> - 2013-02-09 11:10 -0800
            Re: Design Patterns Arne Vajhøj <arne@vajhoej.dk> - 2013-02-09 19:36 -0500
              Re: Design Patterns Lew <lewbloch@gmail.com> - 2013-02-09 23:44 -0800
                Re: Design Patterns Lew <lewbloch@gmail.com> - 2013-02-09 23:47 -0800
                  Re: Design Patterns "John B. Matthews" <nospam@nospam.invalid> - 2013-02-10 12:28 -0500
                Re: Design Patterns Arne Vajhøj <arne@vajhoej.dk> - 2013-02-10 13:35 -0500
                Re: Design Patterns Arne Vajhøj <arne@vajhoej.dk> - 2013-02-10 13:36 -0500
                  Re: Design Patterns Lew <lewbloch@gmail.com> - 2013-02-10 23:12 -0800
            Re: Design Patterns "John B. Matthews" <nospam@nospam.invalid> - 2013-02-09 19:45 -0500
    Re: Design Patterns Arne Vajhøj <arne@vajhoej.dk> - 2013-02-02 20:17 -0500
    Re: Design Patterns Doug Mika <dougmmika@gmail.com> - 2013-02-02 19:43 -0800
      Re: Design Patterns markspace <markspace@nospam.nospam> - 2013-02-02 20:54 -0800
        Re: Design Patterns Doug Mika <dougmmika@gmail.com> - 2013-02-02 21:11 -0800
          Re: Design Patterns markspace <markspace@nospam.nospam> - 2013-02-03 08:24 -0800
            Re: Design Patterns Arne Vajhøj <arne@vajhoej.dk> - 2013-02-08 23:41 -0500
      Re: Design Patterns Lew <lewbloch@gmail.com> - 2013-02-02 21:57 -0800
    Re: Design Patterns Roedy Green <see_website@mindprod.com.invalid> - 2013-02-03 06:38 -0800
    Re: Design Patterns Joerg Meier <joergmmeier@arcor.de> - 2013-02-04 17:06 +0100
      Re: Design Patterns Lew <lewbloch@gmail.com> - 2013-02-04 12:38 -0800
      Re: Design Patterns Arne Vajhøj <arne@vajhoej.dk> - 2013-02-04 21:31 -0500
        Re: Design Patterns Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2013-02-04 21:03 -0800
          Re: Design Patterns Lew <lewbloch@gmail.com> - 2013-02-04 21:25 -0800
            Re: Design Patterns Arne Vajhøj <arne@vajhoej.dk> - 2013-02-05 19:54 -0500
              Re: Design Patterns Lew <lewbloch@gmail.com> - 2013-02-05 17:51 -0800
                Re: Design Patterns Arne Vajhøj <arne@vajhoej.dk> - 2013-02-05 20:54 -0500
          Re: Design Patterns lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-02-05 09:43 +0000
            Re: Design Patterns Lew <lewbloch@gmail.com> - 2013-02-05 13:03 -0800
              Re: Design Patterns Arne Vajhøj <arne@vajhoej.dk> - 2013-02-05 20:09 -0500
            Re: Design Patterns markspace <markspace@nospam.nospam> - 2013-02-05 13:56 -0800
              Re: Design Patterns markspace <markspace@nospam.nospam> - 2013-02-05 14:30 -0800
              Re: Design Patterns Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2013-02-05 14:33 -0800
              Re: Design Patterns lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-02-06 09:03 +0000
            Re: Design Patterns Arne Vajhøj <arne@vajhoej.dk> - 2013-02-05 20:07 -0500
        Re: Design Patterns Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-02-05 09:10 -0500
          Re: Design Patterns Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-02-05 13:20 -0500
            Re: Design Patterns Lew <lewbloch@gmail.com> - 2013-02-05 13:10 -0800
            Re: Design Patterns Arne Vajhøj <arne@vajhoej.dk> - 2013-02-05 20:11 -0500
        Re: Design Patterns Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-02-05 09:53 -0800
          Re: Design Patterns Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-02-05 20:17 -0400
          Re: Design Patterns Arne Vajhøj <arne@vajhoej.dk> - 2013-02-05 19:50 -0500
        Re: Design Patterns Arne Vajhøj <arne@vajhoej.dk> - 2013-02-05 20:34 -0500
          Re: Design Patterns Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-02-06 08:40 -0800
            Re: Design Patterns Arne Vajhøj <arne@vajhoej.dk> - 2013-02-08 23:38 -0500
      Re: Design Patterns Arne Vajhøj <arne@vajhoej.dk> - 2013-02-04 21:41 -0500

Page 1 of 3  [1] 2 3  Next page →

#22029 — Design Patterns

Hi to all

I'm writing an application and I have the following problem.  When I write EventListeners I write them in seperate classes (and seperate files) for reasons of clearity.  But these event listeners I want to modify other classes that aren't  defined in the EventListeners.  They already exist in the main program.  The problem I have is how best to get these eventlisteners to know of these classes (which are also in seperate files)?  Up to know I have used Singletons (I made the classes the event listeners were to modify global) but this seems ugly.  How are java applications written to let the eventlisteners see the classes they are to modify (sometimes these classes are seperate application components in seperate files)?

I hope this makes sense
Doug

[toc] | [next] | [standalone]

#22030

On 2/2/2013 7:17 PM, dougmmika@gmail.com wrote:
> I'm writing an application and I have the following problem.  When I
> write EventListeners I write them in seperate classes (and seperate
> files) for reasons of clearity.  But these event listeners I want to
> modify other classes that aren't  defined in the EventListeners.
> They already exist in the main program.  The problem I have is how
> best to get these eventlisteners to know of these classes (which are
> also in seperate files)?  Up to know I have used Singletons (I made
> the classes the event listeners were to modify global) but this seems
> ugly.  How are java applications written to let the eventlisteners
> see the classes they are to modify (sometimes these classes are
> seperate application components in seperate files)?

If you don't use the nested anonymous classes, then you will need
to send the refs you need over in the constructor.

Do not use singletons for this.

Arne

[toc] | [prev] | [next] | [standalone]

#22049

On 03.02.13 01.39, Arne Vajhøj wrote:
> If you don't use the nested anonymous classes, then you will need
                        ^^^^^^^^^^^^^^^^
> to send the refs you need over in the constructor.

AFAIK nested is sufficient.


Marcel

[toc] | [prev] | [next] | [standalone]

#22061

Marcel Müller wrote:
> Arne Vajhøj wrote:
>> If you don't use the nested anonymous classes, then you will need
>                         ^^^^^^^^^^^^^^^^
>> to send the refs you need over in the constructor.
> 
> AFAIK nested is sufficient.

So is extrinsic. Whether the class is top-level, nested or inner is a choice,
any of which is valid and each of which induces idioms to handle them.

Top-level types and static nested event-listener classes share the need to 
receive everything from the client, i.e., the widget, explicitly. That 
means constructor and method calls, including perhaps getters and setters, 
which are a bugbear for some.

Inner types have the danger and advantage of direct insight into the innards 
of the enclosing instance. This makes anonymous classes handy little parasites, 
special-purpose little listeners that know only of the button or edit box 
off which they feed.

Most people prefer them, if they do, for the intimacy and locality of 
reference to the thingies they help. 

OP, this was mentioned upthread, but your frame of reference for Java 
programming is off kilter. You don't have "classes (which are also in 
seperate [sic] files)". Once in the JVM, classes and all the other 
artifacts of a program live in computerland as types and objects and 
attributes and behaviors. 

The separate-file perspective applies to source code, but not conceptually 
to classes and such.

Also, you don't really "want to modify other classes" usually. You want to 
inform objects (instances) of state changes and requests for state changes 
and invocations of services and so on.

So the perspective is of objects that have types and all that having a type 
implies, not of files and classes.

This helps clear thinking. Now you have this idea of an instance of an 
event listener type that listens for event instances that emanate from 
a GUI widget instance.

"Emanate?" you ask. Fair question. Emanation, communication, messaging, 
invocation, prayer - whatever you call it, instances communicate with each 
other in Java through constructors and methods, or via manipulation of 
an instance's state that's accessible to the instance doing the messing 
around.

Which brings us back to anonymous classes, and inner classes generally. 

Inner class *instances* have direct access to all the state of their 
enclosing *instances*.

So it's handy when a color-changing event is caught and the event listener 
instance can just update the color of its enclosing instance. *

Non-inner-class instances have to go the regular route to communicate with 
the client instance.

Anonymous classes, named inner classes, static nested classes or top-level 
classes - instances of each kind communicate according to the access they have.

:::

*
But messed up if the listener takes a really long time to do so while 
tying up the EDT.

No, not Eastern Daylight Time. 

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#22244

On 2/3/2013 12:52 PM, Marcel Müller wrote:
> On 03.02.13 01.39, Arne Vajhøj wrote:
>> If you don't use the nested anonymous classes, then you will need
>                         ^^^^^^^^^^^^^^^^
>> to send the refs you need over in the constructor.
>
> AFAIK nested is sufficient.

A plain nested class does not have access to the local
variables.

If that is not needed then fine.

If that is needed then it has to be either a local
or anonymous class.

And local classes are very rare in the real world.

Arne

[toc] | [prev] | [next] | [standalone]

#22254

Arne Vajhøj wrote:
> A plain nested class does not have access to the local
> variables.
> 
> If that is not needed then fine.
> 
> If that is needed then it has to be either a local
> or anonymous class.

Nitpick: or inner class.

> And local classes are very rare in the real world.

Sort of. Named local classes are indeed rare. Anonymous local classes 
are rather common.

 public List<File> getFiles()
 {
   final FileFilter filter = new FileFilter() 
   {
     @Override boolean accept(File f) { return f.isDirectory(); }
   };
   // instance of an anonymous local class implementing FileFilter
   ...  
 }

This is good Java idiom because the 'FileFilter' instance is GCable when 
done. It hasn't got state so its cost is virtually nil. So the local class 
feature gives you good control of a program's memory requirements.

In less educated programmers' code I've seen such implementors scoped at 
instance or even (gasp) static member level. And then people wonder at the 
heap requirements.

Java has a funky and nuanced type structure. If you take advantage of 
the nuances you get a lot in return.

It helps to use JLS (Java Language Specification) terminology in its 
exact, narrowest framing. Really. Some call all nested classes "inner" 
classes. Nope. And anonymous classes can be member or local types. It's 
all about scope and context.

The JLS has a detailed treatment, and somewhere out there floats a 
brilliant infographic going back to 1.2-ish days, but here's a brief
taxonomy.

 top level * {public, package},
 nested {static, inner {member, local}} * {any access}

This is off the top of my head, so any corrections welcomed.

There's a lovely corner case involving

 public class Containing
 {
   private void doSomething() {...}

   public class Within extends Containing
   {
     // @Override // ?
     public void doSomething() 
     { 
       Containing.this.doSomething();
       // super.doSomething(); // ?
       ...
     }
   }
 }

[toc] | [prev] | [next] | [standalone]

#22259

On 2/9/2013 2:10 PM, Lew wrote:
> Arne Vajhøj wrote:
>> A plain nested class does not have access to the local
>> variables.
>>
>> If that is not needed then fine.
>>
>> If that is needed then it has to be either a local
>> or anonymous class.
>
> Nitpick: or inner class.

A general inner class does not - only local and anonymous classes
has.

>> And local classes are very rare in the real world.
>
> Sort of. Named local classes are indeed rare. Anonymous local classes
> are rather common.

I don't call them "named local class" and "anonymous local class"
just "local class" and "anonymous class".

But that is just terminology.

Arne

[toc] | [prev] | [next] | [standalone]

#22262

Arne Vajhøj wrote:
> Lew wrote:
>> Arne Vajhøj wrote:
>>> A plain nested class does not have access to the local
>>> variables.
>>>
>>> If that is not needed then fine.
>>>
>>> If that is needed then it has to be either a local
>>> or anonymous class.
>>
>> Nitpick: or inner class.
>
> A general inner class does not - only local and anonymous classes
> has.

That is untrue.

From the JLS:
"The scope of a declaration of a member m declared in or inherited by a class 
type C (§8.1.6) is the entire body of C, including any nested type 
declarations."

"It is a compile-time error if a static class contains a usage of a non-static 
member of an enclosing class."

So all inner classes, being non-static, have access to all members of their 
enclosing type.

Try it.

>>> And local classes are very rare in the real world.
> 
>> Sort of. Named local classes are indeed rare. Anonymous local classes
>> are rather common.
> 
> I don't call them "named local class" and "anonymous local class"
> just "local class" and "anonymous class".

Well, that's just fine for you all by yourself, then.

> But that is just terminology.

You say that as though terminology were anything less than crucial.

Look, this is Java. Use the Java terms, OK?

And as a service to everyone else trying to understand Java, do try not to 
promote non-standard usage. You will only confuse people.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#22263

Lew wrote:
> And as a service to everyone else trying to understand Java, do try not to 
> promote non-standard usage. You will only confuse people.

My bad, you are right and I am wrong.

From the JLS:
"A local class is a nested class (§8) that is not a member of any class and that has a name (§6.2, §6.7)."

[toc] | [prev] | [next] | [standalone]

#22264

In article <b0630d76-a32e-4dd9-943e-9e1c6b823dc8@googlegroups.com>,
 Lew <lewbloch@gmail.com> wrote:

> Lew wrote:
> > And as a service to everyone else trying to understand Java, do 
> > try not to promote non-standard usage. You will only confuse 
> > people.
> 
> My bad, you are right and I am wrong.
> 
> From the JLS:
> "A local class is a nested class (§8) that is not a member of any 
> class and that has a name (§6.2, §6.7)."

This helpful colloquy prompted me to search for an example that 
contrasts local and anonymous inner classes:

<http://code.google.com/p/learning-tij3/source/browse/trunk/src/ch08/LocalInnerClass.java?r=42>

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

[toc] | [prev] | [next] | [standalone]

#22265

On 2/10/2013 2:44 AM, Lew wrote:
> Arne Vajhøj wrote:
>> Lew wrote:
>>> Arne Vajhøj wrote:
>>>> A plain nested class does not have access to the local
>>>> variables.
>>>>
>>>> If that is not needed then fine.
>>>>
>>>> If that is needed then it has to be either a local
>>>> or anonymous class.
>>>
>>> Nitpick: or inner class.
>>
>> A general inner class does not - only local and anonymous classes
>> has.
>
> That is untrue.
>
>  From the JLS:
> "The scope of a declaration of a member m declared in or inherited by a class
> type C (§8.1.6) is the entire body of C, including any nested type
> declarations."
>
> "It is a compile-time error if a static class contains a usage of a non-static
> member of an enclosing class."
>
> So all inner classes, being non-static, have access to all members of their
> enclosing type.
>
> Try it.

Why?

Local variable are not members!

Arne

[toc] | [prev] | [next] | [standalone]

#22266

On 2/10/2013 2:44 AM, Lew wrote:
> Arne Vajhøj wrote:
>> Lew wrote:
>>> Arne Vajhøj wrote:
>>>> And local classes are very rare in the real world.
>>
>>> Sort of. Named local classes are indeed rare. Anonymous local classes
>>> are rather common.
>>
>> I don't call them "named local class" and "anonymous local class"
>> just "local class" and "anonymous class".
>
> Well, that's just fine for you all by yourself, then.
>
>> But that is just terminology.
>
> You say that as though terminology were anything less than crucial.
>
> Look, this is Java. Use the Java terms, OK?
>
> And as a service to everyone else trying to understand Java, do try not to
> promote non-standard usage. You will only confuse people.

That is good advice.

I suggest you take it.

As I am using the terminology used by JLS.

Arne

[toc] | [prev] | [next] | [standalone]

#22269

Arne Vajhøj wrote:
> Lew wrote:
>> And as a service to everyone else trying to understand Java, do try not to
>> promote non-standard usage. You will only confuse people.
> 
> That is good advice.
> 
> I suggest you take it.
>
> As I am using the terminology used by JLS.

Indeed you are. As I admitted and corrected already.

I shall endeavor to do better.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#22260

In article <6eb80ab4-30fb-4137-b7e0-1dcca2ca7fbc@googlegroups.com>,
 Lew <lewbloch@gmail.com> wrote:

[...]

> The JLS has a detailed treatment, and somewhere out there floats 
> a brilliant infographic going back to 1.2-ish days, but here's a 
> brief taxonomy.

Fore reference, this 2007 vintage diagram,

<https://blogs.oracle.com/darcy/entry/nested_inner_member_and_top>

is cited in the the related tutorial:

<http://docs.oracle.com/javase/tutorial/java/javaOO/nested.html>

[...]

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

[toc] | [prev] | [next] | [standalone]

#22032

On 2/2/2013 7:42 PM, Stefan Ram wrote:
>    You might look up Swing code from Oracles Java examples
>    and tutorials and see how those things are solved there.

If it is good enough for Oravle, then it should be good enough
for OP.

>    You might read the book Applying UML and Patterns by Craig
>    Larman.

That is a very good book.

But much broader than this discussion.

Arne

[toc] | [prev] | [next] | [standalone]

#22035

What I mean is the following:
I have a file MainWindow.java class 
I have a file MenuBar.java class which instantiates a MenuWindow.java 
MenuWindow.java is to make changes to MainWindow.java object.

MainWindow.java and MenuBar.java are instantiated in Program.java
How can events in MenuWindow.java cause changes in MainWindow.java
ie. what's the cleanest way to do this?

I know this is explained in a lacklustre way, but I hope it gets the point across.  Any free resources on the web would be appreciated.


On Saturday, February 2, 2013 6:42:21 PM UTC-6, Stefan Ram wrote:
> dougmmika@gmail.com writes:
> 
> >When I write EventListeners I write them in seperate classes
> 
> >(and seperate files) for reasons of clearity.
> 
> 
> 
>   This expresses the underlying assumption that writing them
> 
>   in separate classes and files is more clear. I am not so
> 
>   sure about this!
> 
> 
> 
> >But these event listeners I want to modify other classes that
> 
> >aren't defined in the EventListeners.
> 
> 
> 
>   In Java SE, you usually do not modify classes at runtime.
> 
> 
> 
> >The problem I have is how best to get these eventlisteners to
> 
> >know of these classes (which are also in seperate files)?
> 
> 
> 
>   Well, by »class«, I assume, you mean reference values 
> 
>   (vulgo: objects).
> 
> 
> 
>   Usually, this results from the OOD, for example:
> 
> 
> 
>     - you can give static or non-static idenfiers or getter
> 
>       methods public visibility (which you do not seem to like)
> 
> 
> 
>     - you can pass the references when creating the instances
> 
>       (as arguments of the instance creating expressions)
> 
> 
> 
>     - you can insert them later via setters or
> 
>       dependency injection
> 
> 
> 
>     - or you an write the event listeners as inner
> 
>       classes of the classes they need to access
> 
>       (which you also do not seem to like, but which
> 
>       I like)
> 
> 
> 
>   You might look up Swing code from Oracles Java examples
> 
>   and tutorials and see how those things are solved there.
> 
> 
> 
>   You might read the book Applying UML and Patterns by Craig
> 
>   Larman.

[toc] | [prev] | [next] | [standalone]

#22036

On 2/2/2013 7:43 PM, Doug Mika wrote:
> MainWindow.java and MenuBar.java are instantiated in Program.java
> How can events in MenuWindow.java cause changes in MainWindow.java
> ie. what's the cleanest way to do this?

The thing is, this is called "programming."  There's a very large number 
of ways to do this, and they all are valid, given various design 
assumptions.

Static variables, "globals" as I think you mentioned, are OK if the 
program is small and not going to be maintained (i.e., a small school 
assignment).  More robust methods all make some assumption as to rates 
of code change, presence of frameworks, team size, total costs of 
ownership, etc.

Your immediate problem could be solved by using constructors, and just 
hiding and showing various windows, rather than destroying them and 
re-creating them.

   public static void main( String... args ) {
     // startup
     ...
     createAndShowGui();
     ...
   }

   private void createAndShowGui() {
     SwingUtilities.invokeLater( new Runnable() {
        MainWindow mw = new MainWindow();
        MenuBar mb = new MenuBar();
        MenuWindow menuw = new MenuWindow( mw );
        mw.pack();
        mw.setVisible( true );
     }; );
   }

Now MenuWindow has a reference to mw so it can manipulate mw. But I 
can't think of at least three other ways to do this, and they all have 
advantages and short-comings, so you have to decide what is best for 
your programs.

[toc] | [prev] | [next] | [standalone]

#22037

So passing MainWindow to MenuWindow is one possible solution.  But what are the other three.  No, this is not to be a school assignmennt, I'm looking for a clean and proper way to do this.

On Saturday, February 2, 2013 10:54:07 PM UTC-6, markspace wrote:
> On 2/2/2013 7:43 PM, Doug Mika wrote:
> 
> > MainWindow.java and MenuBar.java are instantiated in Program.java
> 
> > How can events in MenuWindow.java cause changes in MainWindow.java
> 
> > ie. what's the cleanest way to do this?
> 
> 
> 
> The thing is, this is called "programming."  There's a very large number 
> 
> of ways to do this, and they all are valid, given various design 
> 
> assumptions.
> 
> 
> 
> Static variables, "globals" as I think you mentioned, are OK if the 
> 
> program is small and not going to be maintained (i.e., a small school 
> 
> assignment).  More robust methods all make some assumption as to rates 
> 
> of code change, presence of frameworks, team size, total costs of 
> 
> ownership, etc.
> 
> 
> 
> Your immediate problem could be solved by using constructors, and just 
> 
> hiding and showing various windows, rather than destroying them and 
> 
> re-creating them.
> 
> 
> 
>    public static void main( String... args ) {
> 
>      // startup
> 
>      ...
> 
>      createAndShowGui();
> 
>      ...
> 
>    }
> 
> 
> 
>    private void createAndShowGui() {
> 
>      SwingUtilities.invokeLater( new Runnable() {
> 
>         MainWindow mw = new MainWindow();
> 
>         MenuBar mb = new MenuBar();
> 
>         MenuWindow menuw = new MenuWindow( mw );
> 
>         mw.pack();
> 
>         mw.setVisible( true );
> 
>      }; );
> 
>    }
> 
> 
> 
> Now MenuWindow has a reference to mw so it can manipulate mw. But I 
> 
> can't think of at least three other ways to do this, and they all have 
> 
> advantages and short-comings, so you have to decide what is best for 
> 
> your programs.

[toc] | [prev] | [next] | [standalone]

#22046

On 2/2/2013 9:11 PM, Doug Mika wrote:
> So passing MainWindow to MenuWindow is one possible solution.  But
> what are the other three.  No, this is not to be a school
> assignmennt, I'm looking for a clean and proper way to do this.
>

Here's two patterns I see in JEE programming a lot.

1. Global context.  All of your important objects are put into a global 
context object and then are accessible.  In JEE this is similar to a 
Map: you put in objects identified by strings and retrieve them the same 
way.

   globalContext.put( "my window", object );
   thing = globalContext.get( "my window" );

In a less general framework, I'd divide this into major sections (GUI, 
business logic, config, maybe logging, persistence, etc.) and possibly 
provide some specialized logic for each.

The global context should passed into objects somehow, similar to the 
ctor we discussed earlier.

2. Factories.  You can also just have a factory object, which is 
ultimately a static method.

    thing = GuiFactory.getWindow( "main window" );
    - or -
    thing = GuiFactory.getMainWindow();

In larger frameworks it's common for the static method to fetch another 
factory, which then does the work of making objects for you.  Obviously, 
you have to load the main window into the factory at some point.

Personally I think factories are harder to work with, as they making 
testing more difficult.


In a modern app, you also have to consider synchronization, especially 
if your app has special threading requirements, like Swing GUI code. 
This applies to both the factory and the global context.

[toc] | [prev] | [next] | [standalone]

#22243

On 2/3/2013 11:24 AM, markspace wrote:
> On 2/2/2013 9:11 PM, Doug Mika wrote:
>> So passing MainWindow to MenuWindow is one possible solution.  But
>> what are the other three.  No, this is not to be a school
>> assignmennt, I'm looking for a clean and proper way to do this.
>>
>
> Here's two patterns I see in JEE programming a lot.
>
> 1. Global context.  All of your important objects are put into a global
> context object and then are accessible.  In JEE this is similar to a
> Map: you put in objects identified by strings and retrieve them the same
> way.
>
>    globalContext.put( "my window", object );
>    thing = globalContext.get( "my window" );
>
> In a less general framework, I'd divide this into major sections (GUI,
> business logic, config, maybe logging, persistence, etc.) and possibly
> provide some specialized logic for each.
>
> The global context should passed into objects somehow, similar to the
> ctor we discussed earlier.

It is common.

But I would hesitate using it for OP's problem.

> 2. Factories.  You can also just have a factory object, which is
> ultimately a static method.
>
>     thing = GuiFactory.getWindow( "main window" );
>     - or -
>     thing = GuiFactory.getMainWindow();
>
> In larger frameworks it's common for the static method to fetch another
> factory, which then does the work of making objects for you.  Obviously,
> you have to load the main window into the factory at some point.

That is used all the time everywhere.

> Personally I think factories are harder to work with, as they making
> testing more difficult.

Typical factories are considered more test friendly than new.

Arne

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web