Registering listeners into services

I have just finished what it could be one of my last developments in my current client, the false new business comparator. One screen which based on a renewal proposal and fnb proposal compares them and return a lost of the fields which are different. The design is an FnbComparator class which acts as the core  of this screen. This class has a fnbcomparator service which does job of getting the info from the db an compare it returning a list of differences.  The fnbComparator has a Compariaosn translator which transforms the service reaponses into calls to a listener, which is implementes by the displayer. The main class remains like this:
Displayer = new FnbComparatorDisplayer()

New FnbComparator(displayer,new FnbComparatorService(), new FnbComparatorTranslator(displayer)
Displayer and comparator have each other references to allow call backs.

Responsibilities remain like this:
FnbComparator displayer: allows the user to enter info and it triggers the behavior on the comparator main class.
FnbComparator: its the class which supports the screen behavior. Expose methods accordingly to the fields shown in the displayer. It does the validation and send messages back to a listener (the displayer in this case) with whether or not that operation succeed. 
There might be another way to look at his responsibilities; This class expose and interface which allows to set the correct information to compare two prp, and them expose the method compare. Each of this methods produces output messages to a class listener.  However notice how the interface its dictated by the neccesity of the screen:
Setfnb(fnb fnb)
Setrenewal(renewal renewal)
Setfnbbyprposalno(string prpno)
Compare()
Notice those methods support the selection of a renewal, selection of a fnb and the manual entering of the fnb number from the ui. So he is really acting as screen listener.
Comparator service
  In order to provide the screen support, the FnbComparator needs something that does the comparison, is clear this responsibility.
Notice an interesting thing this service returns a response to itscaller (FnbComparator) who is in charge of handling the response. He does it by using a response translator which allows yo hide the internals from the respond and it sends accordingly output messages (compared, unknownerror, different vehicles...) That means the respond error code system can change and we only have to change this class. It exchanges the error codes for output messages. That job is done  in the book 'growing objects orientated systems" by registering the translator within the chat (my comparator service).  This allows the FnbComparator remain ignorant from the fact that he needs a "servicerespondtranslator" combined with the service. Its not obvious that you need this translator to do that. It would be if the service ask for it.
This design of registering listeners seems emerging when we do outside in development. If youll start thinking from the inside out...
It seems useful when calling a service which can have multiple outputs. This way you can have one class which manages this outputs and converts them into messages creating a nice interface.
Other approach will the caller getting the response. This might bbe more the casa when the call returns more of a concrete answer, like a calculation, which then its used by the caller to calculate something else that you can assert on the final calculation.
However im this scenario the next step will be to enable or disable the buttons.  Which is not the responsabilty of the caller. So you'll have to create too many classes for this test.
One approach will be pass the displayer as a listener and asserts that the displayer calls some util action. Class. With an interface very specific like 'disable button compare'.  In this case given a service call you could test almost till the last step of the ui logic. As much fine grained are method in the ui as more logic you can test leaving only without testing the line of code which sets CSS class or calls the disabled. Method on the button
Bottom line is that testing state in ui is difficult and that's why we look for this mesage approach.