Inverting control so service layer calls gui

[Don Kiddick]

There is a trade object, it is currently saved to a file system. The details (filename, location) are filled in a dialog (swt). I'm introducing tests for this logic and I'm introducing a service layer. There will be a TradeService interface which will have methods to persist the trade.

  
interface TradeService {
  void persist(Trade trade);
}

When I'm running my unit tests, I will be subbing in a TransientTradeService which keeps a handle of trades in a HashMap. In production, we will use FileTradeService which actually saves stuff to disc.

Thing is, the FileTradeService needs the extra details mentioned. How to handle this? My solution was to invert control to the TradeService - essentially by passing in the current widget which will allow TradeService implementations which need more details from the user to be able to ask for them from the user.

 
interface TradeService {
  void persist(Trade trade, org.eclipse.swt.widgets.Control control);
} 

and

class FileTradeService {
  public void persist(Trade trade, Control control) {
    File file = openSaveDialog(control);
    writeToFile(file, trade);
  }
}  

On one hand seems neat, but also seems odd by service layer having a dependency on the ui. Is this something to be worried about? If so, any other solutions?

thanks, Don

[Stan James]

You have an interface for your various implementations of the service. That is the contract for clients. A client that works with one implementation should work with any of them. It's not fair for one implementation to pile on more requirements: oh, the client must also provide a dialog to get a filename.

Perhaps what you called "extra details" are not really extra, but always required by the interface and all implementations of the service. Your transient service can use these details to build a key for the hashmap. Your file system service can use them to read and write files.

Changing directions back to the optional dialog ... I'm not as comfy with this one ...

The service layer could own an interface for a DetailProvider, and maybe a default implementation that returns suitable hard-coded default values. The UI layer could optionally implement a DetailProvider that shows a modal dialog and register its implementation with the service. When the service wants details it calls the registered DetailProvider. Maybe you get a pop-up, maybe you don't. Now your dependencies run the right way but the flow is ... odd.

[Don Kiddick]

Thanks that helps.