This is an object-oriented design question that is specific to Spring Boot. I’m extending a Spring Boot application that has an interface that is being extended and used inside another service. The interface uses dependency injection to choose the implementation. I don’t want to change that. I think the inheritance design is nice for Spring Boot, but the interface does not give me the necessary methods for my implementation. Do I am thinking the Decorator Pattern, and mixing in another interface. The interface to be extended is…

public interface DataStrategyService {

    DataRecord getEntityByPK(DataRecord dataRecord);

    DataRecord getEntityByBK(DataRecord dataRecord);

    void overwriteEntityByPK(DataRecord dataRecord);

    void saveEntity(DataRecord dataRecord);

}

There is an implementation already that works already and makes sense with that interface like so…

@Service
@ConditionalOnProperty(name="data.strategy", havingValue="DataBase")
public class DataBaseDataStrategyService implements DataStrategyService {
        DataRecord getEntityByPK(DataRecord dataRecord{
          //implementation stuff
        }

        DataRecord getEntityByBK(DataRecord dataRecord){
          //implementation stuff
        }

        void overwriteEntityByPK(DataRecord dataRecord){
          //implementation stuff
        }

        void saveEntity(DataRecord dataRecord){
          //implementation stuff
        }
}

But that interface, it doesn’t give me what I need for the implementation I’m doing, so Im going to mix in another Decorator like so…

@Component
@ConditionalOnProperty(name="data.strategy", havingValue="CASSANDRA")
public interface ColumnFamilyDataStrategyDecorator {
    Map<String, Object> insertEntity(DataRecord dataRecord);
    Map<String, Object> deleteEntity(DataRecord dataRecord);
}

And the concrete class that would be the class that would use the decorator is…

@Service
@ConditionalOnProperty(name="data.strategy", havingValue="CASSANDRA")
public class ColumnFamilyDataStrategyService implements DataStrategyService, ColumnFamilyDataStrategyDecorator {
  Map<String, Object> insertEntity(DataRecord dataRecord){
      //implementation
  }

  Map<String, Object> deleteEntity(DataRecord dataRecord){
      //implementation
  }

  DataRecord getEntityByPK(DataRecord dataRecord{
      throw new UnsupportedOperationException("ColumnFamilyDataStrategyService.getEntityByPK() currently not supported.");
  }

  DataRecord getEntityByBK(DataRecord dataRecord){
      throw new UnsupportedOperationException("ColumnFamilyDataStrategyService.getEntityByBK() currently not supported.");
  }

  void overwriteEntityByPK(DataRecord dataRecord){
      throw new UnsupportedOperationException("ColumnFamilyDataStrategyService.overwriteEntityByPK() currently not supported.");
  }

  void saveEntity(DataRecord dataRecord){
      throw new UnsupportedOperationException("ColumnFamilyDataStrategyService.saveEntity() currently not supported.");
  }
}

As you can see there some UnsupportedOperationExceptions being thrown. Looks a little messy. However, I don’t really want to use Adapter pattern with delegation because then I wouldn’t be able to use the Spring dependency inject as the author intended. But on other other hand, the exceptions look pretty messy. Any recommendations?

Also: My intention is to use ColumnFamilyDataStrategyDecorator to have some new methods that could work to replace the other interface’s methods. But, I don’t want to touch the calling code if possible. I don’t want to implement a design pattern if it is the wrong thing to do :). But this way, I can leave the calling code alone at least, as I do not own it. The thing is, the other interface’s methods are still needed for the DataBaseDataStrategyService implementation. DataBaseDataStrategyService is using DataStrategyService and will continue to do so. And the service that has a property of DataStrategyService, aka the calling code, which will also be calling ColumnFamilyDataStrategyService, I also don’t want to touch that calling code if I don’t have to. This decorator pattern I basically touch as little code as possible.