SOLID and the user interface?

Question

I try to follow the SOLID principles. But every time it comes to user interfaces I find that there's an inherent friction between the clunky screenful of hybrid, aggregated data the customer requires and the nice principles of single-responsibility.

Now it is possible to divide and conquer the various bits and pieces of a typical user interface into single-responsibility classes, but then you run into all sorts of interesting constructional issues because the so-called "separate" pieces of gui actually often turn out to be different views of the same shared state, or at least partial views of overlapping state.

I often end up mashing together fairly clunky controller classes for my views that are not very SOLID-like, but it's fairly inconsistent coding practice, and it bothers me a bit. It just seems like the complexity of splitting it up isn't worth it.

So how do you deal with it ?

Answer 1

Have you looked into presentation patterns (uncomplete writings by Martin Fowler)? I tend to use Presentation Model for complex views and Autonomous View for trivial views. Presentation Model gives you a flexible setup and you can easily test these classes.

Answer 2

I think you're pretty much right. The view of the data might need to be a "clunky screenful of hybrid, aggregated data" if that's what good user experience dictates for your application. For UI, the usability of the UI is more important than trying to stick to coding design principles. Design principles for code shouldn't dictate the way a user interface looks or works. Then you just end up with rigid forms and views that make sense for the code. Do what makes sense for the user.

That being said an MVC/MVP pattern like mentioned above could still help. Separate the view from the presenter. That way you can still insulate your view and keep the SRP for the view. Your presenter is the one that would have to violate SRP and would have multiple reasons for change.