Question

So, let’s start with some background [modified to make more concrete[. I have realised I can replace the following:

abstract class MessageHandler {
  public void handleMessage(Message m) {
    validateMessage(m);
    processMessage(m);
  }

  protected void validateMessage(Message m) {
    // Default validation logic
  }

  protected abstract void processMessage(Message m);
}

class FakeMessageHandler extends MessageHandler {
  proteced void processMessage(Message m) {}
}

with the next block of code:

interface IMessageProcessor {
  public void processMessage(Message m);
}

class FakeMessageProcessor implements IMessageProcessor {
  public void processMessage(Message m) {}
}

class MessageHandler {
  private IMessageProcessor processor;
  public MessageHandler(IMessageProcessor processor) {
    this.processor = processor;
  }

  public void handleMessage(Message message) {
    validateMessage(message);
    processor.processMessage(message);
  }

  protected void validateMessage(Message message) {
    // Default validation logic.
  }
}

That is, I can replace the abstract method with an injected interface to allow for easier testing. Now let’s say that the design stipulates that people can optionally override the methods:

class FakeMessageHandler extends MessageHandler {
  protected void validateMessage(Message m) {}
  protected void processMessage(Message m) {}
}

The injected interface now cannot be used as there is only 1 abstract method in MessageHandler. Yet, I can’t force the injected interface to contain method validateMessage(Message message) as the original point of using the abstract class was to define a default implementation of this method.

Is there some sort of elegant pattern to convert this into composition for the purposes of dependency injection and easier testing?

Answer 1

Here’s my take on this:

Instead of extending the MessageHandler, I have a single MessageHandler-class, that is a composition of IMessageProcessor and IMessageValidator:

Hope I got the UML-diagram right, it’s been a while…

Anyway, let’s take a look at the MessageHandler:

class MessageHandler
{
    private IMessageProcessor processor;
    private IMessageValidator validator;

    public MessageHandler(IMessageProcessor processor)
    {
        this.processor = processor;

        //Use the given processor as validator, if it implements the IMessageValidator-interface
        if(IMessageValidator.class.isAssignableFrom(processor.getClass()))
        {
            this.validator = (IMessageValidator)processor;
        }   
    }

    public void setMessageValidator(IMessageValidator validator)
    {
        this.validator = validator;
    }

    public void handleMessage(Message message)
    {
        validateMessage(message);
        processor.processMessage(message);
        System.out.println("Message " + message + " handled by MessageHandler");
    }

    protected void validateMessage(Message message)
    {
        if(validator != null)
        {
            validator.validateMessage(message);
        }
        else
        {
            System.out.println("No IMessageValidator-implementation set, using default validation for message " + message);
        }
    }
}

The MessageHandler has two private members, IMessageProcessor and IMessageValidator (It is a composition of a processor and a validator). Validator can be left unset, in which case the default-validation logic will kick in when handling a message.

In this example, if the passed-in processor also implements the IMessageValidator-interface,it will be used as the validator. This is probably what you wanted, because you can use the same constructor to build MessageHandlers using the default validation or custom-validation logic, depending if the passed in object implements only IMessageProcessor or both IMessageProcessor and IMessageValidator (for convenience, I have extended a third interface, IValidatingMessageProcessor from these interfaces). If the validator-logic is implemented separately (only implements IMessageValidator), it can be set using the setValidator-method.

There’s no need to extend MessageHandler, as you can implement both the processing and validation -logic outside of the handler, either separately or in a single class that implements both processing and validation.

Here are the classes I’ve used, hope this helps:

Zip-package in MediaFire

Text-form:

Message.java:

public class Message 
{
    private int number;

    public Message(int number)
    {
        this.number = number;
    }

    public String toString()
    {
        return "Msg " + number;
    }
}

IMessageProcessor.java:

interface IMessageProcessor 
{
  public void processMessage(Message m);
}

IMessageValidator.java:

public interface IMessageValidator 
{
    public void validateMessage(Message m);
}

IValidatingMessageProcessor.java:

public interface IValidatingMessageProcessor extends IMessageProcessor, IMessageValidator
{
}

FakeMessageProcessor.java:

public class FakeMessageProcessor implements IMessageProcessor
{
    public void processMessage(Message m)
    {
        System.out.println("Using FakeMessageProcessor to process message " + m);
    }
}

FakeMessageValidator.java:

public class FakeMessageValidator implements IMessageValidator
{
    public void validateMessage(Message m)
    {
        System.out.println("Using FakeMessageValidator to validate message " + m);      
    }
}

FakeMessageProcessorAndValidator.java:

public class FakeMessageProcessorAndValidator implements IValidatingMessageProcessor
{
    public void validateMessage(Message m)
    {
        System.out.println("Using FakeMessageProcessorAndValidator for validating message " + m);
    }

    public void processMessage(Message m)
    {
        System.out.println("Using FakeMessageProcessorAndValidator for processing message " + m);       
    }
}

Simple testing main for the above classes (just outputs stuff):

public class MessageTest
{   
    public static void main(String[] args)
    {
        //Using processor implementing only IMessageProcessor, MessageHandler will use default validation
        IMessageProcessor processor = new FakeMessageProcessor();
        MessageHandler handler = new MessageHandler(processor);

        handler.handleMessage(new Message(1));

        //Setting separate validator to existing MessageHandler-instance
        handler.setMessageValidator(new FakeMessageValidator());

        handler.handleMessage(new Message(2));

        //Using processor implementing both IMessageProcessor and IMessageValidator
        processor = new FakeMessageProcessorAndValidator();
        handler = new MessageHandler(processor);

        handler.handleMessage(new Message(3));
    }
}

output:

No IMessageValidator-implementation set, using default validation for message Msg 1
Using FakeMessageProcessor to process message Msg 1
Message Msg 1 handled by MessageHandler
Using FakeMessageValidator to validate message Msg 2
Using FakeMessageProcessor to process message Msg 2
Message Msg 2 handled by MessageHandler
Using FakeMessageProcessorAndValidator for validating message Msg 3
Using FakeMessageProcessorAndValidator for processing message Msg 3
Message Msg 3 handled by MessageHandler