Sorry that I didn't make myself clear enough.
I meant the static implementation class name 'Default' inside the interface.
Achim
James Carman schrieb:
Which convention are you saying isn't a best practice? Having the impl
subpackage stuff? That is a common approach that many folks take.
-----Original Message-----
From: Achim Hügen [mailto:[EMAIL PROTECTED]
Sent: Monday, July 31, 2006 10:14 AM
To: [email protected]
Subject: Re: New convention?
Sorry, but I prefer the strict separation of interface and implementation.
I don't see an advantage over a separate implementation class that follows
a naming convention.
This syntax is not a best practise I would encourage so IMHO it shouldn't
be standard.
Achim
Pablo Lalloni schrieb:
El Lunes, 31 de Julio de 2006 07:49, James Carman escribió:
Yes, *Impl in the same package might even be the first place it looks.
Then look for an *Impl in the impl subpackage. I normally use the latter
setup, but many folks do just put the implementation classes in the same
package as their interface. I'd like to make HiveMind very simple to
configure with minimal effort. That's why we offer the option to use
"convention over configuration."
In cases when there will be just a single impl or a "default" one for a
given
service we just make it a static inner class of the service interface.
public interface SomeService {
...
public static class Default implements SomeService {
...
}
}
So if the impl "search path" includes this idiom, it would be great for us
as
this is definitely the most frequent case here.
