> -----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. (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.) 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. 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 :-) > > 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. Perhaps a better name for .sequencial would be .list, or .sequence, I am not sure. > > 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. > 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. > > 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. I propose an IdentifierKit producing IdentifierFactory's, where an IdentifierFactory produces Ids. (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. (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? ;-) 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! 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]
