Re: Design Patterns
Marcel M=FCller wrote:
Arne Vajh=F8j 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 choic=
e,
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 innard=
s
of the enclosing instance. This makes anonymous classes handy little parasi=
tes,
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 h=
ave.
:::
*
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