directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Some inconsistencies in the DN class
Date Sun, 13 Feb 2011 11:23:44 GMT
Hi guys,

as I was writing some doco for the LDAP-API, I checked the DN class and 
found some inconsistencies in the methods. For instance, we have various 
constructors, that can be split in two sets :
- the Schema Aware DN constructors
- the Schema Agnostic DN constructors

1) Schema Aware constructors :
Dn(Dn, SchemaManager)
Dn(SchemaManager, String...)
Dn(String, SchemaManager)

1) Schema Agnostic constructors :
*Dn(String, String, byte[])*  --> This constructor is only used by the 
deserialization method
Dn(String, String, byte[], List<Rdn>)

As we can see, in the first set, we don't have the SchemaManager 
parameter put always at the same position in the arguments list. I would 
suggest that the Dn(Dn, SchemaManager) and Dn(String, SchemaManager) 
constructors be replaced by
Dn(SchemaManager, Dn) and Dn(SchemaManager, String).

That raise a second issue : the Dn(SchemaManager, String...) and 
Dn(SchemaManager, String) constructors will collide, but there is no 
reason to have both. I suggest keeping only the Dn(SchemaManager, 
String...) method.

For the exact same reason, I would remove the DN(String) constructor to 
favor the DN(String...) one.

The Dn(String, String, byte[], List<Rdn>) constructor is only used 
inside the server, and I don't think we really need it. I suggest to 
remove it.

The package protected constructor Dn(String, String, byte[]) is also an 
issue. There is no reason to expose it to the end user.

Last, not least, in order to have some symmetry between both classes of 
constructor, I'd like to suggest we create a schema aware constructor :
Dn(SchemaManager, Rdn...)
and to transform the Dn(Rdn) constructor to Dn(Rdn...).

Thoughts ?

Emmanuel L├ęcharny

View raw message