Matthew Swift wrote:
On 12/01/10 14:29, Emmanuel Lecharny wrote:
Even if you decide that caching is not required then that's no reason to
develop an API which prevents you from implementing one in future. Using
a normal constructor prevents the use of a cache (or forces you to use
the pimpl idiom). If you extend the API later by adding a valueOf method
then no existing applications will be able to take advantage of the perf
improvement unless they are modified to use the new static factory method.
Matthew, you mentioned good reasons for factory methdods. I think it is
not a big deal to add a one or two factory methods.
The base constructor we can have are probably something like:
DN()
DN(String dnStr)
DN( RDN... rdns)
DN( RDN rdn, DN parent)
+1, and additional
DN(DN localName, DN parent)
And let's add simple methods to get the parent of an DN. Every time I
use JNDI I have to write a test to see the result of
ldapName.getPrefix( ldapName.size() - 1 )
Also, I strongly believe that DNs and RDNs and AVAs should be immutable
objects (as well as any other low level API type). What do you think?
Yes, I agree.
Also, on the subject of AVAs - we have the AVA type as an inner class in
RDN. I'm not particularly happy with this this, but less happy with it
being a standalone class since AVAs are only used in RDNs and may
introduce confusion elsewhere. For example, filters also use attribute
value assertions but these are not the same type of object as an AVA
even if they have the same name. For example, AVAs (in RDNs) do not
allow attribute options or matching rules to be specified.
What do you think? Inner class or standalone?
It could be an inner class, but should be visible and constructable from
outside. The use case I see is to create an DN or RDN by specifying the
attribute types and values, without having to deal with escaped
characters. We need such functionality in Directory Studio, when
defining the RDN of an entry or when renaming an entry. The user for
example just types "a+b" into the value field, we construct a new
AVA("cn", "a+b") and the AVA implementation should handle the escaping
to "cn=a\+b".
Kind Regards,
Stefan
