You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Felix Knecht <fe...@otego.com> on 2010/11/22 14:45:22 UTC
Code review - constants in interface
Hi devs
We do have several interfaces [1] just being used as constants holder
(and even more, not all of them are declared as static fields) which
isn't the most preferable construct:
"The constant interface pattern is a poor use of interfaces. That a
class uses some constants internally is an implementation detail.
Implementing a constant interface causes this implementation detail to
leak into the class's exported API. It is of no consequence to the users
of a class that the class implements a constant interface. In fact, it
may even confuse them. Worse, it represents a commitment: if in a future
release the class is modified so that it no longer needs to use the
constants, it still must implement the interface to ensure binary
compatibility. If a nonfinal class implements a constant interface, all
of its subclasses will have their namespaces polluted by the constants
in the interface." [2]
Is there any need to have them declared in an interface or is it just a
poor use?
If there's no need we they could be implemented e.g. as enum or as
static class an them static import could be used.
WDOT?
Regards
Felix
[1] e.g.
org.apache.directory.server.constants.ApacheSchemaConstants
org.apache.directory.server.constants.CoreSchemaConstants (even nowhere
referenced in the code)
org.apache.directory.server.constants.ServerDNConstants
org.apache.directory.server.constants.SystemSchemaConstants (even
nowhere referenced in the code)
[2] Joshua Bloch, "Effective Java (2nd Edition)"
Re: Code review - constants in interface
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
On 22 nov. 2010, at 23:16, Felix Knecht wrote:
> On 11/22/2010 10:15 PM, Felix Knecht wrote:
>> On 11/22/2010 04:03 PM, Pierre-Arnaud Marcelot wrote:
>>> +1,
>>>
>>> This refactoring will also need to take place in Studio where we have
>>> a few interfaces like this too (almost one per plugin).
>>
>> I'll do this.
>
> Done.
Many thanks Felix!
Re: Code review - constants in interface
Posted by Felix Knecht <fe...@apache.org>.
On 11/22/2010 10:15 PM, Felix Knecht wrote:
> On 11/22/2010 04:03 PM, Pierre-Arnaud Marcelot wrote:
>> +1,
>>
>> This refactoring will also need to take place in Studio where we have
>> a few interfaces like this too (almost one per plugin).
>
> I'll do this.
Done.
Re: Code review - constants in interface
Posted by Felix Knecht <fe...@apache.org>.
On 11/22/2010 04:03 PM, Pierre-Arnaud Marcelot wrote:
> +1,
>
> This refactoring will also need to take place in Studio where we have a few interfaces like this too (almost one per plugin).
I'll do this.
>
> Regards,
> Pierre-Arnaud
>
>
> On 22 nov. 2010, at 15:58, Stefan Seelmann wrote:
>
>> On Mon, Nov 22, 2010 at 2:50 PM, Guillaume Nodet<gn...@gmail.com> wrote:
>>> AFAIK, the best pattern for that is to use a final with a private
>>> constructor and declare public static final fields in it.
>>>
>>> public class Constants {
>>> private Constants() {
>>> // non-instantiable class
>>> }
>>>
>>> public static final String TYPE = "type";
>>> }
>>
>> Sounds good. One additional improvement would be to declare the class
>> as final, just to avoid that other classes inherit from it.
>>
>> Kind Regards,
>> Stefan
>
Re: Code review - constants in interface
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
+1,
This refactoring will also need to take place in Studio where we have a few interfaces like this too (almost one per plugin).
Regards,
Pierre-Arnaud
On 22 nov. 2010, at 15:58, Stefan Seelmann wrote:
> On Mon, Nov 22, 2010 at 2:50 PM, Guillaume Nodet <gn...@gmail.com> wrote:
>> AFAIK, the best pattern for that is to use a final with a private
>> constructor and declare public static final fields in it.
>>
>> public class Constants {
>> private Constants() {
>> // non-instantiable class
>> }
>>
>> public static final String TYPE = "type";
>> }
>
> Sounds good. One additional improvement would be to declare the class
> as final, just to avoid that other classes inherit from it.
>
> Kind Regards,
> Stefan
Re: Code review - constants in interface
Posted by fe...@gdls.com.
Emmanuel Lécharny <el...@apache.org> wrote on 11/22/2010 11:52:18 AM:
> On 11/22/10 5:42 PM, Guillaume Nodet wrote:
> > For classes that are designed to export constants, there should be no
> > constructor at all, so even if you're right in theory, i don't think
> > that really apply here (as you're not supposed to add any constructor
> > to that class).
> But if the class is not declared as final, and has no constructor, then
> it can be extended...
Indeed. Any class with no declared constructor has a default,
no-parameters constructor implicitly created by the compiler and can be
extended unless the class is declared "final".
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
This is an e-mail from General Dynamics Land Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated.
Re: Code review - constants in interface
Posted by Emmanuel Lécharny <el...@apache.org>.
On 11/22/10 5:42 PM, Guillaume Nodet wrote:
> For classes that are designed to export constants, there should be no
> constructor at all, so even if you're right in theory, i don't think
> that really apply here (as you're not supposed to add any constructor
> to that class).
But if the class is not declared as final, and has no constructor, then
it can be extended...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Code review - constants in interface
Posted by Guillaume Nodet <gn...@gmail.com>.
For classes that are designed to export constants, there should be no
constructor at all, so even if you're right in theory, i don't think
that really apply here (as you're not supposed to add any constructor
to that class).
On Mon, Nov 22, 2010 at 17:35, Emmanuel Lecharny <el...@gmail.com> wrote:
> On 11/22/10 5:09 PM, Hammond, Steven wrote:
>>
>> Maybe I am off, but I thought other classes already cannot inherit from
>> it, because it has a private constructor.
>
> It does. But it's not convenient. That forces you to declare *all* the
> constructor private. If you miss one of them, then the class can be
> extended. Using 'final' as a qualifier for the class does protect the full
> class completely, even if the class evolve (AFAIU)
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Code review - constants in interface
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 11/22/10 5:09 PM, Hammond, Steven wrote:
> Maybe I am off, but I thought other classes already cannot inherit from it, because it has a private constructor.
It does. But it's not convenient. That forces you to declare *all* the
constructor private. If you miss one of them, then the class can be
extended. Using 'final' as a qualifier for the class does protect the
full class completely, even if the class evolve (AFAIU)
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Code review - constants in interface
Posted by Stefan Seelmann <se...@apache.org>.
On Mon, Nov 22, 2010 at 5:09 PM, Hammond, Steven
<St...@polycom.com> wrote:
> Maybe I am off, but I thought other classes already cannot inherit from it, because it has a private constructor.
Oh, yes, you are right, thanks for the hint. Seems I have to give back
my Java diploma ;-)
> -----Original Message-----
> From: mail@stefan-seelmann.de [mailto:mail@stefan-seelmann.de] On Behalf Of Stefan Seelmann
> Sent: Monday, November 22, 2010 7:58 AM
> To: Apache Directory Developers List
> Subject: Re: Code review - constants in interface
>
> On Mon, Nov 22, 2010 at 2:50 PM, Guillaume Nodet <gn...@gmail.com> wrote:
>> AFAIK, the best pattern for that is to use a final with a private
>> constructor and declare public static final fields in it.
>>
>> public class Constants {
>> private Constants() {
>> // non-instantiable class
>> }
>>
>> public static final String TYPE = "type";
>> }
>
> Sounds good. One additional improvement would be to declare the class
> as final, just to avoid that other classes inherit from it.
>
> Kind Regards,
> Stefan
>
RE: Code review - constants in interface
Posted by "Hammond, Steven" <St...@Polycom.com>.
Maybe I am off, but I thought other classes already cannot inherit from it, because it has a private constructor.
-----Original Message-----
From: mail@stefan-seelmann.de [mailto:mail@stefan-seelmann.de] On Behalf Of Stefan Seelmann
Sent: Monday, November 22, 2010 7:58 AM
To: Apache Directory Developers List
Subject: Re: Code review - constants in interface
On Mon, Nov 22, 2010 at 2:50 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> AFAIK, the best pattern for that is to use a final with a private
> constructor and declare public static final fields in it.
>
> public class Constants {
> private Constants() {
> // non-instantiable class
> }
>
> public static final String TYPE = "type";
> }
Sounds good. One additional improvement would be to declare the class
as final, just to avoid that other classes inherit from it.
Kind Regards,
Stefan
Re: Code review - constants in interface
Posted by Stefan Seelmann <se...@apache.org>.
On Mon, Nov 22, 2010 at 2:50 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> AFAIK, the best pattern for that is to use a final with a private
> constructor and declare public static final fields in it.
>
> public class Constants {
> private Constants() {
> // non-instantiable class
> }
>
> public static final String TYPE = "type";
> }
Sounds good. One additional improvement would be to declare the class
as final, just to avoid that other classes inherit from it.
Kind Regards,
Stefan
Re: Code review - constants in interface
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 11/22/10 2:50 PM, Guillaume Nodet wrote:
> AFAIK, the best pattern for that is to use a final with a private
> constructor and declare public static final fields in it.
>
> public class Constants {
> private Constants() {
> // non-instantiable class
> }
>
> public static final String TYPE = "type";
> }
>
> This avoids all the problems as it forces the user to import the
> constants (and not inheriting the interface).
Probably a good idea. Instead of using an Interface, using a class with
public static final is ok.
Note that Joshua Bloch mention the use of Interface being *implemented*.
We don't do that.
Here, it's really just to define some constants, as Java was initially
designed without such a data structure. They added the 'enum' later, but
it's just not enough. Using class with public static final or not
implemented Interface fulfill the same need : to have constats available
all over he code easily.
I would loved having a 'const' qualifier for classes/interfaces, or even
a const type (class, interface, enum and const would have been perfect),
but they didn't added it - even though the 'const' keyword is reserved
for future usage (those idiots never used it, so you have a way too many
semantic for the 'final' keyword, even in method parameters where the
const keyword would have been way more explicit).
You wonder why SUN has been bought by Oracle ? They were just non
consistent enough ...
So, it's up to you : keep the interfaces as they are, or change them to
Class with a private constructor, and declare all the fields as public
static final just fits me.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Code review - constants in interface
Posted by Guillaume Nodet <gn...@gmail.com>.
AFAIK, the best pattern for that is to use a final with a private
constructor and declare public static final fields in it.
public class Constants {
private Constants() {
// non-instantiable class
}
public static final String TYPE = "type";
}
This avoids all the problems as it forces the user to import the
constants (and not inheriting the interface).
Just my 2 cents.
On Mon, Nov 22, 2010 at 14:45, Felix Knecht <fe...@otego.com> wrote:
> Hi devs
>
> We do have several interfaces [1] just being used as constants holder (and
> even more, not all of them are declared as static fields) which isn't the
> most preferable construct:
>
> "The constant interface pattern is a poor use of interfaces. That a class
> uses some constants internally is an implementation detail. Implementing a
> constant interface causes this implementation detail to leak into the
> class's exported API. It is of no consequence to the users of a class that
> the class implements a constant interface. In fact, it may even confuse
> them. Worse, it represents a commitment: if in a future release the class is
> modified so that it no longer needs to use the constants, it still must
> implement the interface to ensure binary compatibility. If a nonfinal class
> implements a constant interface, all of its subclasses will have their
> namespaces polluted by the constants in the interface." [2]
>
> Is there any need to have them declared in an interface or is it just a poor
> use?
> If there's no need we they could be implemented e.g. as enum or as static
> class an them static import could be used.
>
> WDOT?
>
> Regards
> Felix
>
> [1] e.g.
> org.apache.directory.server.constants.ApacheSchemaConstants
> org.apache.directory.server.constants.CoreSchemaConstants (even nowhere
> referenced in the code)
> org.apache.directory.server.constants.ServerDNConstants
> org.apache.directory.server.constants.SystemSchemaConstants (even nowhere
> referenced in the code)
>
> [2] Joshua Bloch, "Effective Java (2nd Edition)"
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com