Yesterday I was part of a lot of conversations about building composite desktop applications. The people in attendance are building a myriad array of large desktop clients and they’re facing some substantial challenges. Offhand, I remember hearing:
- The desire to reuse business logic between user interfaces
- Wanting to share UI workflow between different screens
- The ability to have multiple teams working in parallel on different elements of the same application
- Extensibility was a big deal
- Keeping business logic out of the UI screens
- Keeping data access out of the UI screens. Yes, even in the year 2008, this still happens.
- Preventing ourselves from getting too tightly bound to a particular presentation technology. This is a hot button topic for me because I’ve decided to forgo WPF for the first couple releases, but it’s obvious that we’ll go that way at some point in about a year.
- Consistency in design
- Object with more than one responsibility
A lot of these challenges can be addressed by the design patterns that I’ve been writing about in the “Build your own CAB.” I’m obviously a big fan of Design Patterns, but throughout the day I’ve been struck by how most of these problems are really solved by applying the fundamentals of software design. If you had never, ever heard of the Model View Presenter patterns, but followed the core OOP design fundamentals like separating concerns, you’d be generally be fine. I’ve seen some comprehensive lists lately of what a developer needs to know, and what to study. The lists were intimidating, and that might be wrong. We need to stress design fundamentals first before we even think of trying to explain Dependency Injection or Model View Presenter patterns.
Let’s look at the list again and connect it to :
- The desire to reuse business logic between user interfaces. The business logic is a concern all by itself. It should be in a totally different set of classes that have no connection to the UI at all. Problem solved.
- Wanting to share UI workflow between different screens. Recognize that there’s some duplication in the system. If you see a basic workflow reoccurring, find a way to pull out the part of the workflows that are consistent. Don’t repeat yourself. One of the best pieces of design advice I’ve ever read is that one of the best things you can do to improve a design is to simply remove duplication. The simple act of isolating commonality will push you in the direction of better cohesion and coupling property.
- The ability to have multiple teams working in parallel on different elements of the same application. This is a little more complicated, but still within the realm of design fundamentals. The best way to pull this off is to make each screen (model/view/presenter and whatever the presenter needs) have as little coupling to the rest of the application as possible. One way or another the presenter and view need to know as little as possible about the application shell and vice versa. The Open/Closed Principle comes into play here. You want to be able to extend the application (Open for extension) by writing all new code in the new screen by the other teams, with little modification to the application shell code (closed for modification).
- Extensibility was a big deal. See above.
- Keeping business logic out of the UI screens. Separation of concerns
- Keeping data access out of the UI screens. Separation of concerns
- Preventing ourselves from getting too tightly bound to a particular presentation technology. The way to beat this is to slice the view as thin as possible. You separate the behavioral logic of the screen away from the actual view. Follow Jeremy’s First Law of TDD: Isolate the Ugly.
- Consistency in design. This is as much or more about teamwork and soft issues like collective ownership. I say this is mostly a people problem.
- Object with more than one responsibility. Single Responsibility Principle. One class, one responsibility.
