Geeks With Blogs

News Google

Nick Harrison Blog<Nick>.Next()

Passive View and Cyclomatic Complexity

We have previously talked about cyclomatic complexity and set forth the goal of keeping the complexity for our methods down below 10.   We have also talked about the goal of systematically refactoring any methods that we find to lower complexities whenever we make code changes.  These are good and admirable goals for business logic.

But what about Passive View?   Passive View is a slight variation on the Model View Presenter pattern designed to drive home the fact that the view should do very little processing.   The view should be passive.  Quiet literally the only code found in the view should be the implementation of the properties and the event handlers for the UI components.  The properties should do the absolute minimal to interact with the user, and the event handlers should simply forward calls on to the presenter.

I cannot stress this enough, there should be no actual logic in the view.

The driving force behind the Passive View pattern is to simplify testing.   Since it is harder to test the UI and the UI does not lend itself to automated testing, we want to move as much logic as possible to locations that are easier to test, class libraries.   Testing aside, logic housed in class libraries is more reusable and can be shared across multiple UIs.   In fact, the automated tests simply become a new UI.

All that being said, any method in the UI should have a cyclomatic complexity of 1!

Yep!   You heard me correctly.  One!   If you find yourself writing a method, event handler or property in the UI with a complexity greater than one, stop and ask yourself why whatever logic you are implemented is in the UI.   Chances are you will find that there is functionality that should be moved to the Presenter or a shared UI component.

I challenge everyone to identify UI code with a complexity greater than 1 that cannot be moved out of the View.   Note that I said out of the View and not out of the UI layer.   There are times when true UI processing may require some logical processing, but these are not so specialized that they cannot be removed from the View.

 

 
Posted on Saturday, September 20, 2008 10:04 PM | Back to top


Comments on this post: Passive View and Cyclomatic Complexity

# re: Passive View and Cyclomatic Complexity
Requesting Gravatar...
I am on my second round of using the passive view design pattern. I like the fact that I can easily use different front ends to implement the code. I have had to maintain to many lines of code where all the ui code, business logic was contained in the code behind. I have dealt with functions in code behind that access data several times and deal with all kinds of branching logic. For me using this design pattern is more simple to code. I haven't run any thing like ndepends against it but I probably should. It took me a while how to figure code model view presenter because everyone describes it a little differently but I just think of it as ui layer-captures displays info, presenter-mediator/intrepreter between the UI an data access layer(model). My UI only talks to the presenter and the presenter passes on info from model. To me this is a very practical design pattern.
Left by technodrone on Sep 21, 2008 9:57 PM

comments powered by Disqus

Copyright © Nick Harrison | Powered by: GeeksWithBlogs.net