Writing orthogonal code is the main goal of several of the principles we are going to mention. But what does this term mean? The term itself has origins in the geometric world, where it means “lying in right angles.” Over time, however, this word has come to describe “things that are independent of one another.” This latter definition more accurately applies to software design.

As you look over the code in a typical software solution, you’ll find many different “categories” of code. You will typically have UI code (the primary subject of this book), business logic, data access, and other infrastructural concerns, such as logging and authentication. If you think over the previous list, you’ll realize that these items are orthogonal. What does logging have to do with UI code? What does user application authentication have to do with your choice of data persistence (SQL Server vs. flat file)? Nothing. But often, over the course of developing an application, these unrelated bits of code end up mixed together. It happens as a matter of convenience, but what many a developer doesn’t recognize is the pain that it will cause them later.

For example, consider this simple, common scenario: You are writing an application like the Contact Manager for your company. In the process of writing this program, you write code in each of the presenters to track errors by writing details to the application event log. This isn’t a big deal, because there are only two presenters. Your program gets popular and users begin to ask for more features, causing you to create additional presenters and views, as well as extend those already in existence. You consider factoring the logging code out into its own class, but decide not to take the time right now. Several months pass and your application is being used by nearly every employee in your company. Things were fine for the first few versions, but lately users have been complaining of frequent crashes. Your boss is concerned and would like you to get to the bottom of this quickly. He asks you to add email-based error logging to the system. You’re thinking this won’t be a big deal, but then you look at the code base and are reminded that the application now has more than 30 presenters with corresponding views, as well as a number of other classes that are doing logging. Right now, you are wishing that you had refactored to a more orthogonal solution several months ago when it first occurred to you. Now you have five hours of work to do instead of five minutes.

If you recognize the value of orthogonality, you’ll want to apply two related principles to your coding: the Single Responsibility Principle (SRP) and Separation of Concerns (SoC). An understanding of these concepts and an ability to practically apply them will go very far in helping you to achieve clean, maintainable code.

The Single Responsibility Principle states “there should never be more than one reason for a class to change.” Taking our earlier example, the presenters in our Contact Manager are exhibiting multiple responsibilities. This is because any given presenter will require code changes if either its presentation logic changes or the logging policy changes. SRP is violated because the class has at least two reasons to change rather than one. To fix this problem, and make our code more orthogonal, we would apply Separation of Concerns (SoC).

SoC embodies a “divide and conquer” approach to programming. Rather than having huge, complex classes, our system should be built from smaller, more focused components that work together. One way to apply SoC to our Contact Manager example would be to create a new class, possibly called Logger. This class could have several overloaded Log methods that enable logging of various types of information. We would then refactor our presenters to use an instance of the Logger rather than writing directly to the event log. In the case that the logging policy changes, all you have to do is change the Logger. Now the Logger has only one reason to change, and so do the presenters, satisfying SRP.

One of the obvious things wrong with the logging code scenario is the simple, needless repetition of code. One of the most fundamental programming principles, Don’t Repeat Yourself (DRY), says No! There are many ways to avoid repetitious code. You can factor out a helper method, derive a new base class, or apply SRP to factor out a completely new class. The key point is if you find yourself writing the same sort of code over and over again, there’s something wrong. You’re not producing DRY code.

As you seek to write more orthogonal code by applying the preceding principles, you’ll find some interesting challenges. It’s not always easy. Fortunately, you’re not stranded. Patterns are cataloged, tested solutions to common coding problems. Many of these patterns have already been implemented in .NET and WPF itself and can be used to improve your own code. If you have not studied design patterns or haven’t been thoroughly exposed to refactoring, we heartily suggest you take a look. Becoming familiar with these tried techniques will improve your code and your ability to quickly create solid, proven solutions to even the most difficult problems.

There are many categories of patterns. You will frequently hear about design patterns, enterprise architecture patterns, refactoring patterns, and several others. These categories are pretty loose, and some patterns can be placed in multiple categories. The most popular category is design patterns. Design patterns are ones that are more applicable to a developer’s everyday work. They address problems common to building object oriented systems.

When you begin to apply the preceding principles and utilize some of the documented patterns, your code will be transformed. More often than not, instead of having a few monolithic classes, you’ll end up with a lot of very small classes. Each of these classes will have a very specific purpose. To accomplish complex tasks, you will often end up with “manager” or “coordinator” classes that orchestrate the interactions between many smaller classes. These coordinating classes are dependent on the classes they use. Presenters are great examples of coordinating classes. To see a concrete example of this, look back at the Contact Manager application. Examine the ApplicationPresenter. The constructor signature is shown next:

public ApplicationPresenter(Shell view, ContactRepository contactRepository)

Notice that the presenter is dependent on both a Shell view and a ContactRepository. It cannot function without these other components, yet it doesn’t take the responsibility of creating them. This is called Inversion of Control, often abbreviated IoC. The control of dependency creation is inverted because the presenter has given up its right to create the components it depends on. It is relying on some outside source to hand it the pieces it needs to work. These dependencies are then injected into the class via the constructor. This is known as Dependency Injection, or DI, and it adds a great deal of flexibility and extensibility to your software design. Some argue that code isn’t truly object oriented unless its dependencies are inverted.

Ya Aren’t Gonna Need It, or YAGNI, is one of the simplest principles to understand, but very rarely followed. Simply put, YAGNI says that you should code only what you know you need right now, nothing more. Scores of programmers get carried away trying to think of every possible future need, and they go out of their way to work those things in before they have been demonstrated as necessary. This often causes overly complex code and a host of unused features. If you follow the principles discussed earlier, you end up writing code that is more flexible and easy to maintain and extend. When you do need to add new features, it will be a much easier task.

You shouldn’t be surprised to hear that the architects of WPF used many of the techniques we’ve been discussing. So, understanding them will both help you develop your own software better and understand more deeply how WPF is put together and functions. Let’s look at a few of the many examples:

Code organization is very important. You should have a meaningful overall structure to your solution. When it comes to a WPF project, you should think carefully about how you want to organize the various types of classes and resources. We have tried to demonstrate an appropriate WPF project structure of various levels of complexity over the course of this book. In general, if you are using an MVP pattern, you want to group your classes in folders/namespaces that indicate their role. If your project is large enough, the model classes will often be broken out into a separate assembly. You should also keep user controls and custom controls in a special namespace. These can also be put in their own assembly if you find yourself needing to use your custom controls across multiple projects. Generally, you will want to have a dedicated location for resources. Many real-world applications require some embedded graphics or other files. You may want to subdivide the resources folder if you find yourself with a large number of resources. Don’t forget to add your XAML resource dictionaries here as well. Again, if the project is complex enough, you may want to break out your resource dictionaries based on the type of resource and merge them at runtime. Regardless of the organizational strategy you choose, you want your code base to be easily navigable. If you are looking for the EditContactPresenter or the gradientBackgroundBrush, you don’t want to have to think to know where to find it. Strive to make the organization as intuitive as possible.

It should be obvious by now that we favor the use of an MVP pattern for all but the most trivial of applications. One of the reasons is that it is one of the best examples of SRP/SoC. Designing your UI with this pattern in mind leads to a result that is much easier to maintain and extend than the alternatives. Also, if you want to use the principles of IoC/DI, it might be difficult if all your code is in a code-behind file. It requires a lot of extra work to figure out how to inject dependencies into classes whose construction you cannot control (instances that are created through XAML). These patterns work better with a presenter, where you have complete control over the classes, base classes, and constructors.

With WPF as your toolset, you are virtually unlimited with regard to the types of UI you can create. Literally, almost anything you can imagine can be done. Nevertheless, this tremendous power and flexibility make it very easy to go wrong in your design decisions. Remember, the goal of a user interface is to help users get their jobs done quickly and painlessly. You want them to have increased productivity and actually enjoy what they are doing. Sticking with established UI patterns seen in popular software will help you to get a start in the right direction. Whenever you are building a user interface, you should be in constant communication with your users. In this way, they can give you feedback about the UI decisions you are making. If they are utterly bewildered by your design choices and can’t relatively quickly figure out how to do what they need to do, you might want to reconsider the direction you are heading in. Here’s one bit of advice we’ve found to be true in designing user interfaces: less is more.

Over the course of the book, we’ve taken a variety of approaches to handling UI layout. We hope that by now you are fairly comfortable with how to approach this issue. We’d like to restate a few earlier recommendations that may have more meaning to you now:

Traditional application resources, as well as those stored in a ResourceDictionary, are an important aspect of using WPF successfully. Here are a few bits of advice:

Styles are one of the most powerful features of WPF. When used properly, they can greatly decrease repetitive XAML and improve the overall maintainability of the system. Here are a few thoughts:

WPF’s templating mechanism is perhaps its most innovative feature. Being able to reuse control behavior while changing the look of the control is a great example of SRP/SoC and is a boon for developers. Here are a few thoughts on how to work wisely with templates:

Most of our recommendations about naming and formatting are useful in creating maintainable code. It is not our intent to wax on over this subject. There are entire documents devoted to coding conventions.