How should i object model class blueprints and concrete classes?

This is not a question about what is a class or what is an object.

I am trying to identify a design pattern, for reuse.

I have a class blue print which consists of a Map keyed with the field name and a value of properties of the field. This map values describe the fields of a particular class.

class FieldDescriptor {
    public FieldDescriptor(String name, int length, boolean isKey) {
    ....
    }
    ...
}

class ConcreteClass {
    final public static Map<String, FieldDescriptor> fields;

    static {
        Map<String, FieldDescriptor> myFields = new HashMap<String, FieldDescriptor>();
        myFields.put("PERSON_CODE", new FieldDescriptor("PERSON_CODE", 10, true);
        myFields.put("FUN_FUN_FUN", new FieldDescriptor("FUN_FUN_FUN", 6, false);
        myFields.put("JEDI_POWER_RATING", new FieldDescriptor("JED开发者_如何转开发I_POWER_RATING", 9000, true);
        fields = Collections.unmodifiableMap(myFields);
    }

    private String personCode;
    private String funFunFun;
    private String jediPowerRating;

    public void setPersonCode(String personCode) {
        this.personCode = transformField(fields.get("PERSON_CODE"), personCode);
    }
    ...
}

The whole reason for the maddness is the transformField call on the setters. It is central to why I have created the map.

However I would like to abstract this away from my class as I would like to build more classes this way and be able to refer to the map generically or via an interface.

I feel strongly that the Map should be encapsulated in a seperate class! However, how will instanciation of the ConcreteClass occur?

Can anyone identify a suitable design pattern?

---

I am not sure if i do understand your question. But if my understanding is correct, I would probably leverage reflection and an instance of the object, rather than introducing a custom Class called FieldDescriptor. Then again I do not know your complete use case, So I might be wrong.

So this is my solution briefly:

Each class will have to have a default static field called defaultInstance. defaultInstance would be of the same type as the Class itself. If I were using a framework like spring, I will try to leverage a framework callback method, to populate the defaultInstance (to me concise, if the lifecycle of the object is managed). The idea is to have an external Component responsible for providing each class with its defaultInstance. (Dynamic Injection ??).

Once the class needs access to value stored in default instance, It could use Reflection API or a wrapper like Apache BeanUtils to get Individual Field Name and value.

I see that you have a boolean field called isKey. If you need this information at runtime, you can use custom annotation to indicate some fields as Key and use isAnnotation Present to implement your branch logic.

So at the end of it call, you just need to have an attribute called defaultInstance in each class. Have a single component, that is responsible for populating this object. ( to make it configurable, you can store information in a property file or db like sqllite). Use Dynamic Injection or AOP if you could (so that its nonintrusive) and use Apache BeanUtils or Reflection API directly to get the information. (even this logic should be abstracted as a separate component).

---

It looks like the only reason you want all the extra complexity of field definitions is so you can relate your fields with their associated column attributes in the database table. You should not have to write this yourself - use a persistence framework like Spring or Hibernate to do the job for you. They use reflection internally, and help keep your data transfer objects (DTOs) clean and easy to maintain.