Women in Technology

Article:		Better, Faster, Lighter Programming in .NET and Java
Subject:		Your factory method screws up early binding!
Date:		2004-07-20 13:31:11
From:		jgehtland
Response to: Your factory method screws up early binding!
That's why we call it "planning for the unknown" and "allowing for extension". If you want to provide an extensible architecture, you can't be bound to what you know when you compile the code. If you stick with only what *you* know now, how can that be extended later by someone else? In addition, you get the binding that matters; the compiled image binds to the methods of the interface directly, without any of that late-binding IUnknown-iness from good old COM, so you don't suffer a performance problem. The only thing you have to do is wrap the call to the factory in a try/catch block in case the reflective lookup fails, and you ought to be double checking any "new" calls anyway. But, if you don't need future-proofing in your app, don't use the technique. Nothing fits all problems...

Showing messages 1 through 2 of 2.

• Your factory method screws up early binding!
  2004-08-08 03:30:55  riffraff [View]
  
  
  so you're saying that using a static language is overkill and unextensible and everybody should be using Ruby, Python and Perl ? :D
  
  Anyway talking about dynamic languages, I hope this will become true
• Your factory method screws up early binding!
  2004-09-07 14:05:05  scottellsworth [View]
  
  
  Not at all. Python, Ruby, and Perl are no more the best solution for every problem than Java is. (Personally, I find fewer problems for which they are the best solution, but that may be based on sampling.)
  
  Put another way, while a primarily static and compile bound language like Java may be the best tool for an overall project, it may well not be the best solution for some of the tasks in that project. At that point, you either look at Jython, or runtime-called Perl, or you use the dynamic capabilities in Java.
  
  Reflection is the primary Java dynamic tool, with classloaders as accomplices, and interfaces as the way you keep they dynamic parts for creeping into otherwise static code.
  
  Scott