Monday, March 26, 2012

Use the Facade Pattern to avoid code duplication and to simplify source code navigation

I'm a big fan of having small concrete classes that does one thing. This allows for easy testing and easy maintenance. However in larger codebases this can also give us a challenge. Due to the large number of classes it can be hard to get an overview of all the available operations and this might lead to code duplication.
Luckily we have design patterns for the most common problems, and a nice pattern to use in this scenario is the Facade Pattern. By creating a facade class per feature/module we can make all the public operations available through a single class, then this will help us to get a better overview of the codebase and help us to avoid code duplication:

What is important to notice is that whenever a class needs to go outside its boundary then the Facade class for the requested feature must be called. For instance if the CustomerUpdater class needs to get the customer then this should be done through the CustomerFacade and not through the CustomerFetcher class, and if it needs to get the employee assigned to the customer then this should be done through the EmployeeFacade.

Monday, March 19, 2012

FluentData is out on NuGet!

FluentData has now been added to NuGet. This makes it very easy to use FluentData in any new or existing project and also to stay up to date on new versions.

Check it out through the NuGet package explorer in Visual Studio by searching for FluentData or go to

Saturday, March 3, 2012

C# regions are code smells

If you find yourself adding #regions to your code to make it easier to read and understand then this is a sign of a class that have gotten too big. Personally I prefer classes to be around 1 screen in height, and anything above this is less optimal and should be refactored.

How can you refactor away from using regions? There are 2 ways:
1) Split the class into many partial classes. This will make the class easier to read but not necessarily easier to understand or maintain.
2) Split the class into many smaller classes. The Single Responsibility Principle is important here, if the class only does one thing then it will be smaller, easier to read, understand and maintain.

Should you refactor to partial classes or smaller classes?
Try to refactor to smaller classes, and where this is not possible such as in public APIs or facade classes then refactor to partial classes.