We had a review of some client-side code today, as it had started to smell a little "off".

As always, the indication I use when quickly reviewing a design is - how easy is this to unit test?


The problem

Logic all over the place.  Massive "if" statements.  More spaghetti than an episode of the Sopranos.

For our web app, we have a number of "tools"; when the user clicks one, it puts the application into that particular tool mode, which means that any subsequent mouse events have to check which mode we are currently in, and take the appropriate action.  Not only that, but we have introduced a vector view layer (SVG) so we have some tools that update the image layer, some that update the vector layer, and some that update both.

The solution

Stick to established patterns.  When dealing with UI, everything boils down to MVC in the end.


 

What we've done here is separate out each tool into an "Interactor" class.  The View provides the abstraction of each view type, and also the UI events.  The Controller provides the glue to stick everything together.

In Summary:

• The View knows about the different view types, and knows about UI events.
• The View Types know how to render themselves, but are still pretty "dumb".
  
• The Controller knows about UI events, and things called Interactors, but it doesn't know what Interactors are or what they actually do.
• The Interactors know exactly what is going on, they interact directly with the view type and the server.
  

This solution certainly isn't "pure" by any means - there is no M!  And I am in no doubt that we could refine this further. 

But the main thing is we have separated everything out into distinct, logical components that have a defined and related set of responsibilities.

What's more this design is geared for unit testing.  We can test the Interactors independently of the views (by dependency injection, which we will do later) and then add another layer of tests integrating the Controller, and so on.