Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Fixed
-
lifecycle-0.2.0
-
None
Description
We already started discussing about it in the ML, but let's track progresses on JIRA.
I detected few areas of approaching the lifecycle design:
- IIUC, we want to manage a series of annotations which identify the sequence of staging steps in the lifecycle, so IMHO the AbstractLifeCycleModule constructor with just one annotation has to disappear; it would be nice to have a varargs array, which would simplify the signature - and the usage from our users - but it would generate an annoying warning to our users; IMHO it is still acceptable, but in case we don't find an agreement here, Iterable should be the best way to pass the annotations sequence to the module.
- ListBuilder: as already discussed, this sound too generic: I'd propose something like AnnotationsLifecycleSequenceBuilder (maybe it is too verbose
) but I'd opt for something that gives a precise idea, not a generic one;
- Again on the list builder, as we discussed, IMHO the wrapped data structure should be a LinkedHashSet: it preserves the sequence and makes efficient the check for duplicates - if the list has a duplicate, I bet the lifecycle event would be handled twice;
- Builder pattern: the way to get the builder is IMHO a little too verbose: Builder.newBuilder() is not a pattern that makes me particularly happy, I'd rather opt for inner class builder such as new ConcreteClass.Builder() which is used in the AsyncHttpClient - WDYT?
I can even make a proposal, in order to show you better my ideas, and attach a patch to discuss together