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:)