2

I have a MessageHandler class which receives and validates messages before determining which components in the architecture they should be delegated to so they can be processed. This involves calling functions with different names and possibly different signatures on classes in different components.

What is the best way to implement the delegation?

The diagram below shows two possible approaches.

Option 1 - each component that must process messages exposes an interface, which is realised by a Facade. For each message, the MessageHandler calls the appropriate operation on the interface and the facade delegates it to the appropriate class internally.

Option 2 - for each message, the MessageHandler calls the appropriate operation directly in the relevant component.

Weighing up the advantages/disadvantages of each:

Option 2 means polluting the message handler with a handle of each class in every component that will process a message. It also makes it harder to test the message handler in isolation. Doesn't seem right.

Option 1 - seems like a better approach. The message handler depends on an interface rather than concrete classes, which also makes it easier to test.

I'm wondering if option 1 a good approach? Or is there a better way to achieve what I want?

enter image description here

Improve this question
4
  • If message_X contains 2 data fields and message_Y contains 3 data fields, who is responsible for getting those data fields out of the messages? Is that the MessageHandler or the class that actually processes the message?
    – Bart van Ingen Schenau
    Mar 4, 2015 at 14:31
  • @BartvanIngenSchenau That would be the message handler.
    – ksl
    Mar 4, 2015 at 15:37
  • I am not sure the interface is relevant here. You just need a match between the caller and the callee. An interface is one way to do it in a strongly typed language, but not necessarily the simplest way (classes are another way).
    – Frank Hileman
    Mar 4, 2015 at 16:12
  • Option 1 because of the separation of responsibilities. Those responsibilities being message aggregation and message dispatch.
    – mortalapeman
    Mar 4, 2015 at 16:57

2 Answers 2

Reset to default
1

I'm guessing the image represents both approaches at the same time.

I think approach 1 is the obvios winner and the beneficts of programming against interfaces are well documented.

I would ask, nonetheless:

  • Are you sure there's no commonality between the classes behind the facadem so all of them could implement the same interface?

If MessageHandler is able to do all its calls using an interface to the facade, how is that not every class behind the facade can't implement the same interface. It seems to me that they are not getting any more info from MessageHandler than that interface allows.

Improve this answer
12
  • Yes, the image shows both approaches.
    – ksl
    Mar 4, 2015 at 15:38
  • If all the classes behind the facade implemented the same interface, that would mean the message handler would need a handle to each one. Which is effectively what the other option is (just without the interface). Or am I missing something?
    – ksl
    Mar 4, 2015 at 15:40
  • What do you mean by "a handle"?
    – Tulains Córdova
    Mar 4, 2015 at 15:42
  • @user61852 I think he means an explicit reference to the instance of each potential message receiver. I agree that option 1 is the clear winner, but not because it is programming against an interface. The message handler gather messages, the façade (or dispatcher as I like to call this pattern) is responsible for knowing where messages need to go. It is the separation of responsibilities that is important in option 1.
    – mortalapeman
    Mar 4, 2015 at 16:55
  • @user61852 By handle I mean a reference or a pointer.
    – ksl
    Mar 4, 2015 at 16:59
1

An interface implemented by only one class gains you nothing in this situation. Will the interfaces ever be implemented by more than one class? If not, you have substituted a dependency for a concrete class, for a dependency on an interface implemented by one concrete class, which adds complexity and no advantage, unless the testing framework must use interfaces.

Improve this answer
2
  • Perhaps the interfaces won't ever be implemented by more than one class. But doesn't having an interface make testing easier?
    – ksl
    Mar 5, 2015 at 20:59
  • @ksl It depends on the testing framework, and what you consider a "unit" when you do unit testing.
    – Frank Hileman
    Mar 7, 2015 at 1:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.