In a project that I am working on; we have a Factory Class that creates 190 different beans. We add about 5 new beans a week to this Factory Class. Is there a hard limit on the number of methods you can place on a class? I'm worried that if or when we create 255 methods, we might have a problem and have to split it up into two factories.
According to Ernest Friedman-Hill from another post: There are some limits imposed by the class file format. There can be no more than 64K fields in a class, for example, nor more than 64K methods in a class. A single method can have no more than 64K local variables, nor more than 255 arguments.
The statement below is true.<br />-------------------------------<br />The statement above is false.
To my knowledge there isn't a limit... but damn there has to be a better way.
This seems like it might be good place for some carefully placed reflection.
have a createBean(String) method. Pass in the name of the class (or better yet have a static variable in the class for the name). Use reflection to create the bean. Cast it to a common interface. Call an init method. Return the new bean.
Then you don't have to change any code to create new beans you just implement the common interface and the factory doesn't have to know about all the different beans.
Maybe this wouldn't work for your situation, but there has to be a better way. Adding all those methods to a factory class is ridiculous.
What Steven says is indeed the best way to go. It's also highly flexible. I'd change it a tad though, to the system I use:
- create a ResourceBundle mapping classnames to descriptive entries - read this in your factory class (static initialiser block is best for performance) - have all classes to be constructed implement a common interface (if possible)
Joined: Nov 03, 2003
Interesting ideas to enhance our "super" factory. The issue with using the "pass in a string" and the "external list of class names" method is that each of the factory methods takes in different initialization parameters. There is no one interface I can apply that will cover all of the different initialization possibilities.
However, reflection and Java 5 (The Var Args fetaure) does give me the tools to possibly implement the "pass in a string of the class name" idea. I can then use the var args to forward the initialization parameters (at least I think this is possible, I have not prototyped this idea of course yet). On the other hand, this eliminates compile time errors if I call a factory with the incorrect arguments leading to hard to find errors. (This is a huge project with over 900 classes).
I wish I could think of a way to break it down. The best idea I can come up with at the moment is to break them down into 10 or 15 (or more) categories of factories.
Luckily, the IDE that I use has great refactoring support.
If each of those 10 - 15 categories of factories correspond to a common interface that the created objects can implement, then you can still use the above ideas. That will reduce your code from 900 factory methods to only a dozen or so.