Sharing POJO between different handlers

Question

I am trying to automate Business Process which can be characterized as a pipeline with distinct stages.

Pipeline can be perceived as A->B->C, where A,B,C are distinct Business Steps that work on some common POJO.

For example, lets consider this Business process:

Business needs to identify whether a Book can be sold in Indian Subcontinent.

Step 1. Ensure that the Book has a specific Publisher P

Step 2. Fetch all editions of Book. The book can only be sold if the edition is > 2.0

Step 3. Make sure that the Price is < 5k. If not check with the Publisher.

This is a simple Pipeline with 3 steps. These steps are different from each other and should be designed for easy re-usability. For example, if tomorrow I need to work on a similar logic for US, I should be able to use Step 1, but for a different publisher.

I have an Interface like this:-

interface Step {
  // T pojo might vary based on which business problem is being solved.
  // But the variation will be very slight. For example, different Business
  // involving Books will typically work on multiple POJO's each having attributes of Books (with slight variations) 
  <T> void process(T pojo) throws Exception;
}

For simplicity, let's say we have 2 distict Business Process in Indian Subcontinent & in US. We might have following POJOs.

class IndianBooks {
  String publisher;
  int price;
  String importer; // this one is not present next POJO
  ...
}

class USBooks {
  String publisher;
  int price;
  String printedAt; //this one is different from IndianBooks
  ...
}

Each Pipeline step would implement this Step Interface For example.

class FilterByPublisher implements Step {
//lets say FilterByPublisher  is invoked by Business 1, which deals with Indian Subcontinent
// `process` method should be able to operate on IndianBooks POJO
// if invoked by Pipeline2 which opearates on US Books this method should be 
// able to handle USBooks POJO

  void process(T pojo) {
    1. needs to access publisher attribute of T
    ...
 }
}

I have thought of the following way:

1. using instanceof within the process() method to check the type of the POJO and then operate on it, then set the other attribute. Note that this change should be reflected in sub-sequent Stages

But somehow I feel that this is not a scalable way since everytime a new Pipeline comes into the scene, I will need to update this method.

Any inputs on how I can effectively solve this?

Update: - After looking at the comment from @Jules, I looked at Visitor Pattern & thought of following approach.

I could keep the Step Interface generic. Create an abstract FilterByPublisher class which handles filtering logic. Create 2 Concrete Filter Classes (to be used by different Business Processes) which just handle the input & pass on to the abstract FilterByPublisher class.

abstract class FilterByPublisher {
  void filter(String publisher) {
    ..
 }
}

class FilterByPublisher_IndianBusiness extends FilterByPublisher implements Step {
 @Override
 public <T> void process(T pojo) {
   String publisher = ((IndianBooks)pojo).getPublisher(); // typecast
   filter(publisher);
  }
}

Any other alternatives are welcome.

Answer 1

Your design / domain model is plain wrong, if you have to deal with instanceof. This is a clear usecase OOP was invented for, resp. Polymorphism. treating a bunch of different objects as a family of objects. There are two ways to solve your problem:

1) Define a common base for Indian Books and USBooks. This makes sense, when both are indeed Books.

2) Define an interface which provides the necessary information for filtering

As a next Step, you should refactor the filtering to a strategy pattern, so that you are able to dynamically swap filter criteria.

Answer 2

It could be made rather generic using reflection and a factory that uses a Map. The map connects classes, which hold functionality for processing one or more book types, to those book types.

The various steps in the A->B->C process are given a name, and a factory is created with that given name. Using the step name and the book class passed to the factory the correct step class is fetched using the map/table.

When one wants to add functionality one creates the class that holds that functionality. Then update the map/table so as to map that functionality to one or more book classes and steps. When new functionality is added the only change to existing code is to update the map. Even then the map aught to be externalized through jpa, or a spring injection, etc. Then there are no code changes, only new class additions. If externalizing, then the class name might be used instead of the class object for indexing the mapping.

Interfaces:

public interface Book {

}

public interface Step {
    public void execute(Book book);
}

The factory (getters and setters omitted for brevity):

public class StepFactory {

    private static final Map<String, Map<Class<Book>, Class<Step>>> map = new HashMap<>();
    // add items to the map

    private String stepName;

    public StepFactory(String stepName) {
        this.stepName = stepName;
    }

    public Step getStep(Book book) {

        Map<Class<Book>, Class<Step>> stepMap = map.get(stepName);
        if (stepMap == null) {
            // do whatever else needs to be done here
            return null;
        }

        Class<Step> stepClass = stepMap.get(book.getClass());
        if (stepClass == null) {
            // do whatever else needs to be done here
            return null;
        }

        try {
            Step step = stepClass.newInstance();
            return step;

        } catch (InstantiationException | IllegalAccessException e) {
                e.printStackTrace();
                // do whatever else needs to be done here
                return null;
        }

    }
}

Somewhere else:

StepFactory stepFactory = new StepFactory("step A");
Step step = stepFactory.getStep(book);
step.execute(book);

The classes implementing the functionality still cast the book to the particular Book implementation they require. But such is expected to succeed based on proper mapping.