> But if you need to apply some more logic in order to create the instance > either LoggerReflectionUtils::createObject() (as a general mechanism) or a > specific implementation that deals with only LoggerAppender-specific stuff > in LoggerAppender::factory() is valid options. Currently both > implementations looks the same, but typically in this case you would like to > limit which classes can be instantiated (only instanceof LoggerAppender) > which is logic that resides in a LoggerAppender::factory() method.
I understand what you mean now. But LoggerAppender does only provide a general mechanism, not a limitated mechanism which just allows LoggerAppenders to be created. Its public, everybody can use this method to create objects of any kind. IMHO we should either we limit this method to what you described or leave it as general method, but then move it to a general class. Otherwise we have this code duplicated at least 5 times or so and of course have to test it 5 times. Even when we check for types, its worth considering getting this method out from this class - I am thinking on Spring example, where I learned that object creation is not necessary the concern of the class itself but of an external creator. Its similar with singletons. All the implementations are exactly the same, just creating an object, putting it into an instance-array and returning if it already exists. There is nothing specific. Sometimes I even feel that creation of multiple objects shouldn't be dissallowed, like in LoggerHierarchy. Even log4j doesn't use this class a singleton (at least this is not coming out from the javadocs) Cheers, Christian
