Webmasters Gallery

There has been a bit of a code war going on or at least a some what heated debate on code quality and programming principles.

I’m not going to rehash everything but I will sum up the two sides and throw my opinion into the ring. Why does my opinion matter? I’m not so sure that it does but you can be the judge of that. What I do think is different about my opinion than the opinions that I have heard/read so far is that I can’t place myself in either camp. I am not a coding cowboy that just cares that “it works” and I am not a bureaucratic standards Nazi either. I’ll talk a bit more about why I am ducking for cover in no man’s land in this battle of opinions.

The Coding Cowboys Say

Jeff Atwood and Joel Spolsky sure hit a sore spot when they suggested that learning programming principles just wasn’t worth it and just getting it done was more important.

Jeff likened principles and guidelines to the Ferengi and their 285 Rules of Acquisition saying that every situation in programming cannot be governed by a set of rules and there isn’t a one size fits all pattern to solve everything.

Joel refers to the SOLID principles as “extremely bureaucratic programming that came from the mind of somebody that has not written a lot of code.”

The Craftsmen Say

Jeff and Joel’s comments sparked a lot of rebuttals from the ALT.Net community. It is understandable since those comments attack the very foundation of TDD and DDD. I am not going to bore you with a list of everyone that chimed in but I want to highlight a post that I think sums up this position in a clear and nice way.

Justin Etheredge made a great post is response to the criticisms. I have been reading Justin’s blog for a while and I like the way he views software. He likens software development to carpentry and woodworking, both are a learned craft. You don’t get good a carpentry by throwing things together and ignoring building codes. Patterns and principles are like building codes.

My View On The Whole Thing

I was a bit surprised at first to hear Jeff and Joel’s comments because they are some smart guys that have produced some successful software. I highly doubt, regardless of how it came across, they intended to imply that you should ignore all guidelines and just string together your code. Unfortunately, the comments of their posts make it all too clear that this is exactly the way a lot of programmers took it. What’s worse is bad programmers will use this as a defense for their resistance to improving their skills.

Like I said, currently I am somewhere in no man’s land. For too long I had the mindset that would take Jeff and Joel’s comments and use them as an excuse to ignore patterns and principles. From the beginning of my education in software development, no importance was placed on “good design.” My college training only focuses on teaching the syntax and considering that “knowing” the language.

After a few years of living in denial, I had to accept that their was far more for me to learn and I began my journey out of the cowboy coding camp and started striving to develop software in a TDD manner. I still have a lot to learn but facts cannot be ignored. Since making an effort to improve my craft I have seen a significant drop in the amount of bugs found in new software I am producing and the bugs that are found are smaller and much similar to solve. So that is my take on the whole thing and I hope that this at least peaks someone’s interest to dig a little deeper in regard to becoming a craftsmen and taking pride in the code they produce.

Today I am back with another design pattern. In this post we’ll be exploring the Facade pattern.

What Is The Facade Pattern

The facade pattern is a higher level interface that simplifies and brings together multiple interfaces of a subsystem. What this means is if you want to do something but that requires interacting with multiple subsystems you can create a facade that same only a few methods that handle all the interaction with the subsystem.

Our Application Requirements

In our city dog registration application lets assume there are a few things that need to be done when a new dog is registered. First the new dog and it’s owners must be entered into the system. Next the registration fee must be processed. Finally, we want the system to send the owners the welcome email.

This is a very simple example but this action requires 3 separate systems to do something in order to complete this one task of registering a new dog.

Using The Facade Pattern

For the sake of simplicity and not cluttering this post with too much code, I am not going to provide code for the sub systems, just the facade.

public class RegistrationManager : IRegister {
    private IAccountingService _accounting;
    private IMessageService _messaging;
    private IRepository = _repository;

    public RegistrationManager(IAccountService accounting, IMessagingService messaging, IRepository repository) {
        _accounting = accounting;
        _messaging = messaging;
        _repository = repository;
    }

    public void RegisterDog(IDog dog) {
        _repository.AddDog(dog);
        _accounting.ProcessPayment(dog.PaymentOrder);
        _messaging.SendWelcome(dog.Owners.Find(x => x.PrimaryContact))
    }
}

As you can see this is a very simple example but it illustrates the concept of the pattern. We have taken 3 tasks, each belonging to a different sub system, and combined them into 1 task in a facade class, in this case the RegistrationManager class.

The RegisterDog method adds the new dog to the repository, sends the payment order to the accounting system, and sends a welcome message to the dogs owners that are flagged as primary contacts.

Summing It Up

I hope this post helps you understand the Facade pattern and I hope you are continuing to learn and have fun with this series.

Be sure to grab the RSS feed or follow me on Twitter to stay up to date and not miss any posts.

The C# Design Patterns Series

Part 1 – An Overview

Part 2 – The Decorator Pattern

Part 3 – The Abstract Factory Pattern

Part 4 – The Observer Pattern

Part 5 – The Facade Pattern

What Is The Facade Pattern

The facade pattern is a higher level interface that simplifies and brings together multiple interfaces of a subsystem. What this means is if you want to do something but that requires interacting with multiple subsystems you can create a facade that same only a few methods that handle all the interaction with the subsystem.

Our Application Requirements

In our city dog registration application lets assume there are a few things that need to be done when a new dog is registered. First the new dog and it’s owners must be entered into the system. Next the registration fee must be processed. Finally, we want the system to send the owners the welcome email.

This is a very simple example but this action requires 3 separate systems to do something in order to complete this one task of registering a new dog.

Using The Facade Pattern

For the sake of simplicity and not cluttering this post with too much code, I am not going to provide code for the sub systems, just the facade.

public class RegistrationManager : IRegister {
    private IAccountingService _accounting;
    private IMessageService _messaging;
    private IRepository = _repository;

    public RegistrationManager(IAccountService accounting, IMessagingService messaging, IRepository repository) {
        _accounting = accounting;
        _messaging = messaging;
        _repository = repository;
    }

    public void RegisterDog(IDog dog) {
        _repository.AddDog(dog);
        _accounting.ProcessPayment(dog.PaymentOrder);
        _messaging.SendWelcome(dog.Owners.Find(x => x.PrimaryContact))
    }
}

As you can see this is a very simple example but it illustrates the concept of the pattern. We have taken 3 tasks, each belonging to a different sub system, and combined them into 1 task in a facade class, in this case the RegistrationManager class.

The RegisterDog method adds the new dog to the repository, sends the payment order to the accounting system, and sends a welcome message to the dogs owners that are flagged as primary contacts.

Summing It Up

I hope this post helps you understand the Facade pattern and I hope you are continuing to learn and have fun with this series.

Be sure to grab the RSS feed or follow me on Twitter to stay up to date and not miss any posts.

The C# Design Patterns Series

Part 1 – An Overview

Part 2 – The Decorator Pattern

Part 3 – The Abstract Factory Pattern

Part 4 – The Observer Pattern

Part 5 – The Facade Pattern

2 Responses to “C# Design Patterns – The Facade Pattern”

1. HardCode Says:

   March 10th, 2009 at 9:27 am

   I just starting to use this pattern with the same goals in mind. It’s good to see it here, confirming my suspicions of how the facade works. Thanks.

2. BigJim Says:

   March 10th, 2009 at 4:50 pm

   Hey, thanks much for this excellent series. I look forward to future posts on the various patterns. One thing that is confusing to me, I get this pattern and the “command” pattern mixed up. So when you get to the command pattern, maybe you could contrast it with the facade and explain which tasks each is best suited for.

   But thanks again!