Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / January 2006

Tip: Looking for answers? Try searching our database.

Design patterns using anonymous inner classes

Thread view: 
Scott Simpson - 11 Jan 2006 06:23 GMT
I've been reading a document that states:

1. In Java a nested class can be declared in any block including methods.
2. The ability to create nested classes in methods in Java may seem
unnecessary but combined with anonymous inner classes can provide a
means of creating power design patterns.

Does anybody know which design patterns this author is referring to?
Lexical closures perhaps?
Tony Morris - 11 Jan 2006 06:32 GMT
Most likely the creation of a local piece of code, often referred to as a
delegate, callback or closure in other language contexts.
This permits the developer to pass 'pieces of code' to be called back on by
some implementation - typically to determine some strategy.
I hold the stance that design patterns as we know them have only a
superficial and contrived existence, so I won't elaborate any further for
fear of stone throwing by the critical mass :)

Almost certainly not what the author is referring to, and extremely
unorthodox, is ContractualJ ( http://contractualj.com/ ) where all
contract/interface implementations are implemented as anonymous classes.

Note that an anonymous class is implicitly an inner class.
http://jqa.tmorris.net/GetQAndA.action?qids=67&showAnswers=true

Signature

Tony Morris
http://tmorris.net/

> I've been reading a document that states:
>
[quoted text clipped - 5 lines]
> Does anybody know which design patterns this author is referring to?
> Lexical closures perhaps?
Robert Klemme - 11 Jan 2006 11:17 GMT
> Most likely the creation of a local piece of code, often referred to
> as a delegate, callback or closure in other language contexts.
> This permits the developer to pass 'pieces of code' to be called back
> on by some implementation - typically to determine some strategy.

One of the most common uses of anonymous classes are adapters for UI
events in Swing / AWT.  There the anonymous class implements an event
listener interface and reacts on evens in some way.

Kind regards

   robert
Alan Krueger - 11 Jan 2006 13:51 GMT
> One of the most common uses of anonymous classes are adapters for UI
> events in Swing / AWT.  There the anonymous class implements an event
> listener interface and reacts on evens in some way.

This is one of the few places where I prefer C#'s approach, using delegates.
Stefan Ram - 13 Jan 2006 02:33 GMT
>Almost certainly not what the author is referring to, and
>extremely unorthodox, is ContractualJ
>(http://contractualj.com/ ) where all contract/interface
>implementations are implemented as anonymous classes.
 
 For example, in BoxingShortable, the method "getShortable()"
 always returns the same instance x, which then, in turn,
 offers me an operation "get(short s)" to get a Short instance
 from a short value.

 This seems to be a Singleton object instead of a class with
 static methods.

 This seems to be done, because in Java, only instance-methods
 can implement interfaces, but not static methods.

 Otherwise, a static "get(short s)" method would have done.  Or
 are the even more reasons for this kind of implementation?

 It looks as if the whole source file is quite a large overhead
 and indirection for an operation that comes done to a method
 like "Short get(final short s){return s;}", which looks as if
 it would do nothing at all, but is using an autoboxing-
 conversion for its actual duty.

 In the end, there are about 86 lines to wrap this, plus at
 least one additional interface to describe it and test methods
 to test it and coverage tools to measure the coverage, and
 documentation and annotations for it all. All this overhead
 for effectively a single boxing conversion.

 I am not bringing up these questions to dispraise
 ContractualJ, I think I can learn by reading its source code.
Tony Morris - 13 Jan 2006 03:11 GMT
> >Almost certainly not what the author is referring to, and
> >extremely unorthodox, is ContractualJ
[quoted text clipped - 29 lines]
>   I am not bringing up these questions to dispraise
>   ContractualJ, I think I can learn by reading its source code.

I agree - 86 lines is far too long - welcome to Java :)
The stance is that primitive types are a language defect. On this premise,
one must devise an optimal workaround.
You can pass around a Shortable and not ever care about how "a short is
converted to a java.lang.Short" to some contract that requires that
strategy.
For example, BoxShortable is one of many implementations - you could create
a LRU cache if for some reason it was beneficial - or perhaps some other
strategy. The point is, clients of that contract needn't ever (and in fact,
are not able to) care about it - The shortable contract is the appropriate
abstraction for the strategy of the optimal workaround.
In any case, the remainder of the 86 lines are a result of the optimal
workaround within the confines of the rules that ContractualJ has imposed
unto itself.
The reasons for these rules are omitted, only because they are lengthy to
document - and my world only has 24 hours in a day :)

Signature

Tony Morris
http://tmorris.net/

Stefan Ram - 13 Jan 2006 03:10 GMT
>Almost certainly not what the author is referring to, and
>extremely unorthodox, is ContractualJ (
>http://contractualj.com/ ) where all contract/interface
>implementations are implemented as anonymous classes.

 Regarding the rules on

http://contractualj.com/,

 I understand many of them and even use some of the myself, but
 what about:

     "All operations are defined on an interface, including
     private operations. Private methods are not permitted."

 So private operations are allowed, but private methods are
 not: I know the meaning of "private method" from the JLS, but
 what is a "private operation"?

 Also: Could it help to split the rules in two parts?
 Those which are DBC-related and those which are not?
 Avoiding "break;" might be good style, but has it
 directly to do with DBC?

 A rationale document for all these rules would be interesting
 to read.
Tony Morris - 13 Jan 2006 03:16 GMT
> >Almost certainly not what the author is referring to, and
> >extremely unorthodox, is ContractualJ (
[quoted text clipped - 22 lines]
>   A rationale document for all these rules would be interesting
>   to read.

You raise some very interesting points - and I agree that I have more work
to do on both of them.
Specifically, I need to define exactly what a "private operation" is, and I
need to define why "break" is related to DBC - or abandon that relationship
altogether.

On the point of private operations, I guess I will have to make the
distinction. Where one would normally (but erroneously under this context)
use a private method, one should instead use a private interface declaration
and private implementation. An "operation" is merely an abstraction from an
interface method - within a Java context. The reason I use these
abstractions is because I am developing a programming language that also has
the notion of "operations", therefore, I can talk about language theory
without referring to any particular language with other people.

Sorry for the confusion.

Signature

Tony Morris
http://tmorris.net/

Stefan Ram - 13 Jan 2006 03:35 GMT
>The reason I use these abstractions is because I am developing
>a programming language that also has the notion of
>"operations", therefore, I can talk about language theory
>without referring to any particular language with other people.

 Thanks for your explanations! I am trying to develope
 a programming terminology myself [1] and my own notions
 of "operations" and "methods" are somewhat similar.

 To me, an "operation" is what a client sees from the /outside/
 of an object, that is, a part of the interface the object is
 exposing. An operation consists of both its formal
 specification (its signature and return type) and its
 semantics (its behavior, possibly specified in natural
 language).

 To me, a "method" is a specific way to implement an operation
 and can only be seen from the inside of an object. A method
 specifies a complex operation in terms of elementary
 operations offered by the underlying architecture or machine.

 [1]
http://purl.net/stefan_ram/garnoo/XOCONCEPTXSPERSONXSYSTEFANXGYRAMXOTERMINOLOGX7
9ZXSPROGRAMMING


 (This is only a first draft of my terminology. It is
 written using a semantic net language developed by me
 and then converted to HTML-pages:)


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.