Thank you all for your time to reply to my post.
Scott Shipp wrote:Hmm...that just sounds...interesting...what is the use case for such a thing? Why do you have 150 classes implementing the same interface? Are you sure that this wouldn't make sense done some other simpler way? Are the 150 different implementations really 150 different bits of logic?
I forgot to mention that there are abstract classes that stand between the "module" classes and the interface. Most of those "module" classes are just configuring the settings used by the abstract class they extend.
In more detail:
Those 150 "module" classes represent websites with which my program must interact.
About 100 of those websites are running on a small set of software (around 10 scripts). For this reason, I have created abstract classes that implement interaction logic with those scripts.
Most of those websites aren't using the scripts in their default config - they often use custom code, plugins, and various configurations on software and server side. For this reason, the script implementations are abstract classes that are extended by the "module" classes - any changes in the default behavior of the script are either configured or implemented in the "module" classes. In example, basic configuration is done by calling the abstract class constructor and/or other configuration related methods. Custom code or server specific modifications are handled by overriding methods (like
login method).
This organization allows me to easily handle all of the 150 websites. When one gets updated, I can easily navigate to the class that represents given website and change what is needed. So far this system proved to be working nicely.
Ron, thank you very much for the detailed description of the process, and Rob for the idea with ServiceLoader. Your posts gave me a new idea how I can temporarily handle this situation (due to an incoming deadline). For now, I will store the class names in the database. When the classes are needed, I will simply query the database and create new instances using the class names.
Nevertheless, I will have to implement "scanning" of the classes in the package anyway. It will be needed to implement ofter features that are planned for the next iteration on the beginning of 2016. I will come here back with details how I implemented it. Suggestions of Ron and Rob will be definitely very helpful in implementing that. Thank you again for your responses, I really appreciate that.