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


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

Re: Design Patterns

Newsgroups comp.lang.java.programmer
Date 2013-02-03 14:23 -0800
References <3c0d69c3-591d-4d99-8c13-30a0fd1684b3@googlegroups.com> <510db1c3$0$282$14726298@news.sunsite.dk> <510ea3f6$0$9502$9b4e6d93@newsspool1.arcor-online.net>
Message-ID <3411752f-a133-4c14-80e0-76f6f4b455c8@googlegroups.com> (permalink)
Subject Re: Design Patterns
From Lew <lewbloch@gmail.com>

Show all headers | View raw


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

Back to comp.lang.java.programmer | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

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

csiph-web