The SettingsService is a powerful multi-purpose tool. However, genericity always comes at the price of abstraction. Assume, there is some business logic which is based on a domain specific interface Address:

          
public interface Address {
  String getName();
  String getCity();
}

public class Messages {
  public static String getHelloMessage(Address address) {
    return "Hello " +
            address.getName() +
            ", are you living in " +
            address.getCity() + "?";
  }
}
        

If your actual address data is provided by the SettingsService, it must be adapted to the address interface.

          
class SettingsBackedAddress implements Address {
  // [...] constructor and fields for service and provider bean
  public String getName() {
    return settingsService.setting("name", String.class, bean);
  }
  public String getCity() {
    return settingsService.setting("city", String.class, bean);
  }
}
        

Cumbersome, isn't it? Especially, if the interfaces are larger or not yet final. Fortunately, you don't need to implement such interfaces manually, but SettingsService.createProxy does the job for you:

          
class MyCode {
  private SettingsService settingsService;

  void doSomething(BusinessBean beanWithSettings) {
    Address address = settingsService.createProxy(Address.class, beanWithSettings);
    String message = Messages.getHelloMessage(address);
  }
}
        

Internally the default settings service intercepts the call to getName() and getCity(). The operation getCity() is translated to settingsService.setting("city", String.class, bean). Note: The property name "city" will be derived from the operation getCity() in the interface. Be aware of this dependency when choosing names for your settings properties and for the operations of your business objects if you want to use the proxy mechanism.