Design pattern to handle settings in subclasses?

I have a small hierarchy of classes that all implement a common interface.

Each of the concrete class needs to receive a settings structure containing for instance only public fields. The problem is that the setting structure

• has a part common to all classes
• has another part that vary from one concrete class to another

I was wondering if you had in your mind any elegant design to handle this. I would like to build something like:

BaseFunc doer = new ConcreteImplementation1();

with ConcreteImpleme开发者_JAVA技巧ntation1 implements BaseFunc. And have something like

doer.setSettings(settings)

but have the ''settings'' object having a concrete implementation that would be suitable to ConcreteImplementation1.

How would you do that?

---

This may be a named design pattern, if it is, I don't know the name. Declare an abstract class that implements the desired interface. The abstract class constructor should take an instance of your settings object from which it will extract the global settings. Derive one or more classes from the abstract class. The derived class constructor should take an instance of your settings object, pass it to the parent class constructor, then extract any local settings.

Below is an example:

class AbstractThing implements DesiredInterface
{
    private String globalSettingValue1;
    private String globalSettingValue2;

    protected AbstractThing(Settings settings)
    {
        globalSettingValue1 = settings.getGlobalSettingsValue1();
        globalSettingValue2 = settings.getGlobalSettingsValue2();
    }

    protected String getGlobalSettingValue1()
    {
        return globalSettingValue1;
    }

    protected String getGlobalSettingValue2()
    {
        return globalSettingValue2;
    }
}

class DerivedThing extends AbstractThing
{
    private String derivedThingSettingValue1;
    private String derivedThingSettingValue2;

    public DerivedThing(Settings settings)
    {
        super(settings);
        derivedThingSettingValue1 = settings.getDerivedThingSettingsValue1();
        derivedThingSettingValue2 = settings.getDerivedThingSettingsValue2();
    }
}

---

Have a matching hierarchy of settings objects, use Factory to create the settings that match a specific class.

---

Sounds like you need a pretty standard Visitor pattern.

To put it simple, suppose, that all your properties are stored as key-value pairs in maps. And you have 3 classes in your hierarchy: A, B, C. They all implement some common interface CI.

Then you need to create a property holder like this:

public class PropertyHolder {

    public Map<String, String> getCommonProperties () { ... }

    public Map<String, String> getSpecialPropertiesFor (CI a) { return EMPTY_MAP; }

    public Map<String, String> getSpecialPropertiesFor (A a) { ... }

    public Map<String, String> getSpecialPropertiesFor (B b) { ... }

    ...
}

All your classes should implement 1 method getSpecialProperties which is declared in the interface CI. The implementation as simple as:

public Map<String, String> getSpecialProperties (PropertyHolder holder) {
   return holder.getSpecialPropertiesFor (this);
}

---

I went down this route once. It worked, but after decided it wasn't worth it.

You can define a base class MyBean or something, and it has its own mergeSettings method. Every class you want to use this framework can extend MyBean, and provide its own implementation for mergeSettings which calls the superclasses mergeSettings. That way the common fields can be on the super class. If you want to get really fancy you can define and interface and abstract class to really make it pretty. And while your at it, maybe you could use reflection. anyway, mergeSettings would take a Map where the key is the property name. Each class would have its constants to related to the keys.

 class MyBean extends AbstractMyBean ... {
       public static final String FIELD1 = 'field1'

       private String field1

       public mergeSettings(Map<String, Object> incoming) {
            this.field1 = incoming.get(FIELD1);
            // and so on, also do validation here....maybe put it on the abstract class
       }


 } 

Its a lot of work for setters though...

---

I started toying with a new pattern that I called "type-safe object map". It's like a Java Map but the values have type. That allows you to define the keys that each class wants to read and get the values in a type safe way (with no run-time cost!)

See my blog for details.

The nice thing about this is that it's still a map, so you can easily implement inheritance, notification, etc.

---

You could use Generics to define what kind of settings this instance need. Something like this:

public abstract class MySuperClass<T extends MySettingsGenericType>{
    public MySuperClass(T settings){
         //get your generic params here
    }

}

public class MyEspecificClass extends MySuperClass<T extends MySettingsForThisType>{
    public MySuperClass(T settings){
         super(settings);
         //Get your espefic params here.
    }

}

//and you could use this
BaseFunc doer = new ConcreteImplementation1(ConcreteSettingsFor1);

//I dont compile this code and write in a rush. Sorry if have some error...