Gary Gregory wrote:
-----Original Message----- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Saturday, December 27, 2003 09:07 To: Jakarta Commons Developers List Subject: [uid]llang] Adding refactored [lang] identifiers to [uid]
I am about ready to commit a more or less "rfbar" (refactored beyond all recognition) version of the [lang] Identifier stuff into [uid]. Before I commit anything, I want to get some feedback on the design and naming choices. Here is what I have in mind (and code, more or less ;)
1. Keep the [lang] IdentifierFactory interface, but rename it "IdentifierSequence." This is partly because I don't want to deal with names ending in "FactoryFactory" (see below), partly because I see these things as sequence generators, not class factories.
I do not have much of a problem with an IdentifierFactoryFactory but I am
not fond of IdentifierSequence because of the implied semantics of what a
sequence is, which might not be appropriate for some ids.
Well, to me what these identifier-generator thingies do is produce sequences of identifiers, similarly to the way that a random number generator generates a pseudo-random sequence of numbers. That's why I chose "Sequence" over "Factory." I also thought seriously about leaving off the suffix entirely -- i.e. doing like Random does and just calling the base interface "Identifier," but I was afraid that that would not capture the sequence-generating behaviour.
(Perhaps JAXP kind of class names would work, food for thought: IdentifierBuilder and IdentifierBuilderFactory. (Reference: http://java.sun.com/j2se/1.4.2/docs/api/javax/xml/parsers/package-summary.ht ml) Of course, "builder" is not really appropriate in this case but offers a good starting point.)
I like the "Builder" name. Probably better than "Sequence".
A gang-of-four synonym for "Abstract Factory" is "Kit", so you could have an
IdentifierKit producing IdentifierFactory's.
IdentifierFactory idFactory = IdentifierKit.newUniqueLongFactory(...);
I kinda like that one.
2. Change the Long and String subinterfaces to abstract classes named "AbstractLongIdentifierSequence", "AbstractStringIdentifierSequence." This is so they can include some default behavior. I also added methods (with default implementations) to return the maximum and minimum lengths (resp. values) of generated identifiers, as this is a common request from users (wanting to know how long the ids can be).
3. Define an abstract IdentifierSequenceFactory class to enable pluggable IdentifierSequence implementations of various kinds (including all of those in [lang] and uuids as well). This class has a static newInstance() method that uses [discovery] to locate a concrete factory, defaulting to DefaultIdentifierSequenceFactory, which creates instances of the IdentifierSequences provided with [uid]. The setup here is more or less copied from the distribution framework in [math] (thanks, Brent!).
I am cautiously, timidly, waiving a tiny little red flag ;-) This seems quite complicated for a first cut. Would an application really need this kind of decoupling and pluggability? The answer I "sometimes" I suppose.
Wave away. That's why I posted before committing anything :-)
We should make sure that we can run code and examples /without/ any config files or [discovery] jars being of around or logging taking place. Perhaps a separate IdentifierKit class could be created to hold all of this fancy stuff ;-) The IdentifierKit would remain the basic guy... I am just looking for a simpler picture/code path for simple cases :-)
The [discover] jar would be necessary, but no config would be required, since things would default. I think that the behaviour that you are ascribing to IdentifierKit is what the refactored IdentifierUtils would provide. Could be we could combine these; but I wanted to keep the static stuff out of the "Kit" and to support declarative specification of identifier implementations. With some more/better thinking, this could probably all be done in the "Kit." Remember that it will be better for users if we provide (access to) singletons, since many/most identifier generators are stateful.
4. Create packages called "sequential," "random," and "uuid" to house the IdentifierSequence implementations and farm out the inner class implementations from [lang]'s IdentifierUtils into these packages. I see all but the "StringSessionIdentifier" from [lang] as "sequential", the former being "random." I also envision a "secure" package down the road to house "secure random" and signed/verifiable identifiers.
This is why I am not fond of the "Sequence" in the class name, .sequential and .random sound opposite but would both implement something "Sequence"? That does not sound quite right to my ears, IMHO, that is.
You have now convinced me that "Sequence" has to go ;)
Perhaps a better name for .sequencial would be .list, or .sequence, I am not sure.
By "sequential" I meant identifiers that go in some sort of predictable sequence (like [lang]'s StringNumeric, StringAlphanumeric, and Long identifiers). I don't think that "list" captures that.
5. Hack away all but the static methods and "handy singleton storage" from [lang]'s IdentifierUtils and keep this as a convenience class.
We should see what the code pile ends up looking like, it does not sound like such a class should any longer be needed.
Except that it provides static singleton instances for the "Builders" (or whatever we decide to call them :)
6. Create a test framework for uid implementations.
One question that I have regards supporting pluggable strategies within the (as yet unwritten) uuid implementation. I want to make sure that the structure above will support this in a natural way. One approach would be to add parameters that code strategy choices to IdentifierSequenceFactory's uuidSequence method (similar to the way e.g. "wrap" works in IdentifierUtils' factory methods). Another way would be to have DefaultIdentifierSequenceFactory delegate to a proper uuid sequence factory. I guess the framework will support either approach, so this decision does not have to be made immediately; but I would appreciate any thoughts/concerns that others have on this.
Hmm... I am concerned about what sounds like two levels of plugability. We should wait and see what it all looks like ;-) I see the main level of pluggability at the IdentifierKit level, you can ask it for different kinds of Id Factories. Are you saying that for UUID Factories, there is yet another level of plugability, seems quite a load! ;-) I think we need to look at example client code to get a better idea. That will make this discussion easier I think by flushing/fleshing out design from client code patterns. Let's get something working and then see if refactorings come out naturally.
I think that I agree with you. It's probably better to keep to one level.
Comments? Suggestions? Volunteers?
(A) IdentifierKit producing IdentifierFactory's The more I "talk" (write) about these classes, the less comfortable I am with Id "Sequences" producing Id Factory's.
Agreed.
I propose an IdentifierKit producing IdentifierFactory's, where an IdentifierFactory produces Ids.
Or "IdentifierFactory" producing "IdentifierBuilders."
(B) Id vs. Identifier Using "Id" instead of "Identifier" in names. IdKit producing IdFactory's. There is nothing lost when using "Id", it is a very common abbreviation.
I prefer the whole word.
(C) The project/package name [uid] vs. [id] The project/package name is [uid] but we always talk in terms of "Identifers" and it does not feel like "Unique" is always in mind. Perhaps I am not used to the project yet but a sign is that we are considering a .uuid subpackage name, which seems very odd when you look at it this way: o.a.c.uid.uuid. Uh? ;-)
Yes. I could go either way on this one. I generally do have uniqueness in mind when thinking about the "Builders," though it will almost never be "guaranteed."
Which is why I'd like to propose [id] instead of [uid]: o.a.c.id.uuid, etc. This leaves the room for all sorts of future factories, producing more or less unique Ids depending on the context.
Thanks for reading this far!
And thank *you* for reading this far!
I will make the naming changes suggested above (holding off on the uid -> id change for now) and commit (unless you or others feel strongly about killing the abstract factory in 3. immediately) with some tests that illustrate client code and we can take it from there. Thanks again for the feedback.
Phil
Gary
I have all but 5. and 6. implemented now. I will likely finish these today. I will commit something (so we have something concrete to talk about) tomorrow or Mon. incorporating whatever feedback I get between now and then.
Phil
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
