On Tue, 07 Sep 2004 13:38:51 +0200, Achim Huegen <[EMAIL PROTECTED]> wrote:
> Maybe a case, where composition is better than inheritance.
> Although SDL is resting in peace, the support of both XML and SDL would
> result in :
> XmlModuleProvider, SdlModuleProvider, ClasspathXmlModuleProvider and
> ClasspathSdlModuleProvider.
>
> I would suggest a common ancestor that deals with resources and
> which expects a parser for resource processing. the parser parameter
> is optional and the XML Parser is used as default:
>
I see what you're saying. But isn't this maybe a case of YAGNI? I
didn't quite understand all the details of your idea either.
After trying out a few solutions this is what I've come up with
(boring bits left out):
class RegistryBuilder {
Registry constructRegistry(ModuleProvider provider, Locale locale) {...}
static Registry constructDefaultRegistry() {...}
}
interface ModuleProvider {
List getModuleDescriptors(ErrorHandler handler, RegistryAssembly
assembly) {...}
}
class ClasspathXmlModuleProvider implements ModuleProvider {
ClasspathXmlModuleProvider(ClassResolver resolver) {...}
}
class XmlModuleProvider implements ModuleProvider {
XmlModuleProvider(ClassResolver resolver, Resource resource) {...}
XmlModuleProvider(ClassResolver resolver, List resources) {...}
}
class AggregateModuleProvider implements ModuleProvider {
AggregateModuleProvider(List providers) {...}
}
Note that the constructRegistry() method only accepts a single
ModuleProvider (not a List). The idea is that using multiple
ModuleProviders should be a quite rare case, where the
AggregateModuleProvider can be used instead. If it just weren't such a
pain to construct a List with a single element in Java...
I'm thinking if it would make sense to replace the XmlModuleProvider
and ClasspathXmlModuleProvider with a single:
class XmlModuleProvider implements ModuleProvider {
XmlModuleProvider(ClassResolver resolver) {...}
XmlModuleProvider(ClassResolver resolver, Resource resource) {...}
XmlModuleProvider(ClassResolver resolver, List resources) {...}
}
Thoughts?
--knut
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
