0

Let me ask you, as this bothers me for quite a while but appears to be subjectively the best solution for my problem, if reflective discovery of an inner class for API purposes is that bad idea?

First, let me explain what I mean by saying "reflective discovery" and all that stuff.

I am sketching an API for a Java database system, that'll be centered around block-based entities (don't ask me what that means - that's a long story), and those entities can be read and returned to the Java code as objects subclassed from the Entity class.

I have an Entity.Factory class, that, by means of fluent interfaces, takes a Class<? extends Entity> argument and then, uses an instance of Section.Builder, Property.Builder, or whatever builder the entity has, to put it into the back-end storage.

The idea about registering all entity types and their builders just doesn't appeal to me, so I thought that the closest solution to the problem that'd suffice my design needs would be to discover, using reflection, all inner classes of Entity classes and find one that's called Builder.

Looking for some expert insight :) And if I missed some important design details (which could happen as I tried to make this question as concise as possible), just tell me and I'll add them.

  • 1
    Reflection in user-level code is typically a code smell: try to avoid it. – user22815 Aug 21 '14 at 23:31
1

Maybe you are looking at the problem the wrong way.

You shouldn't start from a subclass of Entity and find the associated Builder by reflection. Instead, you should start from an instance of a Builder and let it build the Entity you want.

I don't know how you use your factory. But for example, instead of calling factory.create(Section.class) you could call factory.create(new Section.Builder()). Would that make sense?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.