Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Robert Klemme <shortcutter@googlemail.com>
Newsgroups: comp.lang.java.programmer
Subject: Re: Class.forName().newInstance() vs new
Date: Sun, 12 Jun 2011 14:05:58 +0200
Lines: 37
Message-ID: <95jod7FbdbU1@mid.individual.net>
References: <it07on$ilc$1@speranza.aioe.org> <95ho4qFd7cU1@mid.individual.net> <dKudnSwyLLvWM27QnZ2dnUVZ_o2dnZ2d@earthlink.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: individual.net ilRin7x8nL88VyG8vNaNaAAxKYjOjGftFSBiLe9Tok5Y0wIIQ=
Cancel-Lock: sha1:l0IVIXItCKOK4lsQkvKFGATlw+U=
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10
In-Reply-To: <dKudnSwyLLvWM27QnZ2dnUVZ_o2dnZ2d@earthlink.com>
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:5233

On 06/11/2011 08:04 PM, Patricia Shanahan wrote:
> On 6/11/2011 10:49 AM, Robert Klemme wrote:
>> On 11.06.2011 19:13, Abu Yahya wrote:
> ...
>>> else { // handle unrecognized
>>> Class<?> k = Class.forName(dbMgrClassName);
>>> db = (DB) k.newInstance();
>>> }
> ...
>> Doing if else cascades is certainly the worst thing - not so much
>> because of the performance but because of the deficiency that you need
>> to touch the code every time you want to add a new class. With the other
>> two approaches you do not have to do that.
> ...
>
> As coded, the forName code was left in as a fall-through handler, so it
> new classes can be handled without touching the code. Of course, that
> also means it has all the complications of both the if-else approach and
> the forName approach.

Thanks for hinting at this detail, Patricia!  Performance of this piece 
of code can vary dramatically with configured class / handler name. 
That adds a level of complication which might make tracking issues 
harder ("It was so fast in our lab, now on production it's awfully slow.").

Also I find the inconsistency about what needs to be configured 
irritating: the string can either be a logical name of a handler *or* a 
class name - and you cannot even distinguish them easily (handler names 
presented so far are also valid class names).  IMHO for this it would be 
better to have two different properties with clear defined precedence 
for logical handler name property.  That would also make it explicit 
that there are two mechanisms involved.  Even though, I still prefer one 
of the two uniform approaches (class name, factory class name).

Kind regards

	robert