Design patterns using anonymous inner classes

S

Scott Simpson

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?
 
T

Tony Morris

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
 
R

Robert Klemme

Tony said:
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
 
A

Alan Krueger

Robert said:
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.
 
S

Stefan Ram

Tony Morris said:
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.
 
S

Stefan Ram

Tony Morris said:
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.
 
T

Tony Morris

Stefan Ram said:
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.

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

Tony Morris

Stefan Ram said:
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.

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.
 
S

Stefan Ram

Tony Morris said:
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/XOCONCEPTXSPERSONXSYSTEFANXGYRAMXOTERMINOLOGX79ZXSPROGRAMMING

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

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top