Troelsen's Tutorials: The Decorator Pattern & Extension Methods

Troelsen's Tutorials: The Decorator Pattern & Extension Methods

Microsoft TechEd North America 2010 - Home

Give the gift of technical education, and save US$300 on the full Tech·Ed conference fee.

Microsoft TechEd North America 2010 - Home

Now Available: patterns & practices Application Architecture Book

via J.D. Meier's Blog de J.D. Meier le 05/11/09

The Microsoft Application Architecture Guide, 2nd edition, is now available on Amazon and should be available on the shelf at your local bookstores soon.  The PDF was downloaded ~180,000 times.  This is the Microsoft platform playbook for application architecture.  You can think of it as a set of blueprints, and as your personal mentor for building common types of applications on the Microsoft platform:  mobile, RIA, services, and Web applications.

The backbone of the guide is an information model for the application architecture space.  It's a durable and evolvable map to give you a firm foundation of principles, patterns, and practices that you can overlay the latest technologies.  It's your "tome of know-how."  While it's not a step-by-step for building specific applications, it is a pragmatic guide for designing your architecture, with quality attributes, key software principles, common patterns, and architectural styles in mind.  It's holistic and focused on the key engineering decisions where you face your highest risks and most important choices.

Key Features of the Book
The book has several compelling features for slicing and dicing the application architecture body of knowledge:    

• Canonical Frame.  This describes at a meta-level, the tiers and layers that an architect should consider. Each tier/layer will be described in terms of its focus, function, capabilities, common design patterns and technologies.
• Application Types.  These are canonical application archetypes to illustrate common application types: Mobile, Rich Client, RIA, Services, and Web applications.  Each archetype is described in terms of the target scenarios, technologies, patterns and infrastructure it contains. Each archetype is mapped to the canonical app frame. They are illustrative of common application types and not comprehensive or definitive.
• Quality attributes.  This is a set of qualities and capabilities that shape your application architecture: performance, security, scalability, manageability, deployment, communication, etc.
• Cross-cutting concerns.  This is a common set of categories for hot spots for key engineering decisions: Authentication, Authorization, Caching, Communication, Configuration Management, Exception Management, Logging and Instrumentation, State Management, and Validation.
• Step-by-Step Design Approach.
• Principles, patterns, and practices.   Using the application types, canonical frame, and cross-cutting concerns as backdrops, the guide provides an overlay of relevant principles, patterns, and practices.
• Technologies and capabilities.  The guide provides an overview and description of the Microsoft custom application development platform and the main technologies and capabilities within it.

Contents at a Glance
The full Microsoft Application Architecture Guide is available for free on MSDN in HTML.  This is the contents of the guide at a glance:

• Foreword by S. Somasegar
• Foreword by Scott Guthrie
• Preface by David Hill

Chapters

• Chapter 1: What is Software Architecture?
• Chapter 2: Key Principles of Software Architecture
• Chapter 3: Architectural Patterns and Styles
• Chapter 4: A Technique for Architecture and Design
• Chapter 5: Layered Application Guidelines
• Chapter 6: Presentation Layer Guidelines
• Chapter 7: Business Layer Guidelines
• Chapter 8: Data Layer Guidelines
• Chapter 9: Service Layer Guidelines
• Chapter 10: Component Guidelines
• Chapter 11: Designing Presentation Components
• Chapter 12: Designing Business Components
• Chapter 13: Designing Business Entities
• Chapter 14: Designing Workflow Components
• Chapter 15: Designing Data Components
• Chapter 16: Quality Attributes
• Chapter 17: Crosscutting Concerns
• Chapter 18: Communication and Messaging
• Chapter 19: Physical Tiers and Deployment
• Chapter 20: Choosing an Application Type
• Chapter 21: Designing Web Applications
• Chapter 22: Designing Rich Client Applications
• Chapter 23: Designing Rich Internet Applications
• Chapter 24: Designing Mobile Applications
• Chapter 25: Designing Service Applications
• Chapter 26: Designing Hosted and Cloud Services
• Chapter 27: Designing Office Business Applications
• Chapter 28: Designing SharePoint LOB Applications

Appendices

• Appendix A: The Microsoft Application Platform
• Appendix B: Presentation Technology Matrix
• Appendix C: Data Access Technology Matrix
• Appendix D: Integration Technology Matrix
• Appendix E: Workflow Technology Matrix
• Appendix F: patterns & practices Enterprise Library
• Appendix G: patterns & practices Pattern Catalog

The Team
Here is the team that brought you the guide:

• Core Dev Team: J.D. Meier, Alex Homer, David Hill, Jason Taylor, Prashant Bansode, Lonnie Wall, Rob Boucher Jr, Akshay Bogawat
• Test Team - Rohit Sharma, Praveen Rangarajan, Kashinath TR, Vijaya Jankiraman
• Edit Team - Dennis Rea
• External Contributors/Reviewers - Adwait Ullal; Andy Eunson; Brian Sletten; Christian Weyer; David Guimbellot; David Ing; David Weller; Derek Greer; Eduardo Jezierski; Evan Hoff; Gajapathi Kannan; Jeremy D. Miller; John Kordyback; Keith Pleas; Kent Corley; Mark Baker; Paul Ballard; Peter Oehlert; Norman Headlam; Ryan Plant; Sam Gentile; Sidney G Pinney; Ted Neward; Udi Dahan
• Microsoft Contributors / Reviewers - Ade Miller; Amit Chopra; Anna Liu; Anoop Gupta; Bob Brumfield; Brad Abrams; Brian Cawelti; Bhushan Nene; Burley Kawasaki; Carl Perry; Chris Keyser; Chris Tavares; Clint Edmonson; Dan Reagan; David Hill; Denny Dayton; Diego Dagum; Dmitri Martynov; Dmitri Ossipov; Don Smith; Dragos Manolescu; Elisa Flasko; Eric Fleck; Erwin van der Valk; Faisal Mohamood; Francis Cheung; Gary Lewis; Glenn Block; Gregory Leake; Ian Ellison-Taylor; Ilia Fortunov; J.R. Arredondo; John deVadoss; Joseph Hofstader; Koby Avital; Loke Uei Tan; Luke Nyswonger; Manish Prabhu; Meghan Perez; Mehran Nikoo; Michael Puleio; Mike Francis; Mike Walker; Mubarak Elamin; Nick Malik; Nobuyuki Akama; Ofer Ashkenazi; Pablo Castro; Pat Helland; Phil Haack; Rabi Satter; Reed Robison; Rob Tiffany; Ryno Rijnsburger; Scott Hanselman; Seema Ramchandani; Serena Yeoh; Simon Calvert; Srinath Vasireddy; Tom Hollander; Wojtek Kozaczynski

Application Architecture Knowledge Base
The guide was developed in conjunction with our Application Architecture Guide v2.0 Knowledge Base Project. The knowledge base project was used to inform and steer the guide during its development. The Application Architecture Knowledge Base includes a large amount of material that expands on specific topics in the main guide. It also includes draft material from the main guide that is targeted and packaged for more specific audiences, such as the Pocket Guide series.

• Overview Slides
• Train the Trainer (Video)
• Pocket Guides
• Videos
• Slides
• Figures (Visios)

Key Links at a Glance
Here are the key links at a glance:

• Microsoft Application Architecture Guide (MSDN)
• Microsoft Application Architecture Guide (Amazon)
• Application Architecture Knowledge Base

10/GUI: Fascinating Multitouch User Interface Design

If you want to see what the next generation of UI might look like, take a look at this concept.

Link: 10/GUI via Gizmodo

Using Decorator (or Wrapper) Design Patterns to add Validation to an object

Context

In most cases when someone write about the Decorator pattern it is usually related to UI stuff. The most common example is adding “decoration” to a control, for example a scroll bar. But in my humble opinion, this is not the most useful usage of Decorator. The purpose this pattern is:

“Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to sub classing for extending functionality”

Gang of Four

If you think about it, Validation is a responsibility and so it can be added by this pattern. Of course we can add the validation to the class itself or in its base class, but how would you reuse this validation across many unrelated objects and what if you object must derive from another base class?

Solution

The solution is the Decorator pattern. With this pattern we can add new responsibility to an object without changing its internals.

For simplicity purpose we will take a simple sample that anyone can understand but the concept shown here can apply to much more complex object.

Four our sample we will take a bank account. On this account we should be able to to money deposit and withdraw. The class diagram on the right illustrate this design.

Let’s start by defining our IAccount interface

namespace Model
{
   public interface IAccount {
       string AccountNumber { get; }
       decimal Balance { get; }
       bool Active { get; }
       void Deposit(decimal amount);
       void Withdraw(decimal amount);
       void Close();
   }
}

This simple interface will be the central abstraction of the system. The goal is to never depends on concrete class and this interface in enough to add a lot of functionality around an account.

Now here the interface implementation as an Account:

using System.Diagnostics;

namespace Model
{
   [DebuggerDisplay("Account = {_accountNumber}, Balance = {_balance}")]
   public class Account : IAccount
   {
       public string AccountNumber { get; private set; }
       public decimal Balance { get; private set; }
       public bool Active { get; set; }

       internal Account(string accountNumber, decimal balance)
       {
           AccountNumber = accountNumber;
           Balance = balance;
           Active = true;
       }

       public void Deposit(decimal amount)
       {
           if (OnBeforeDeposit())
               Balance += amount;
           OnAfterDeposit();
       }

       protected virtual bool OnBeforeDeposit()
       {
           return true;
       }

       protected virtual void OnAfterDeposit() { }

       public void Withdraw(decimal amount)
       {
           if (OnBeforeWithdraw())
               Balance -= amount;
           OnAfterWithdraw();
       }

       protected virtual bool OnBeforeWithdraw()
       {
           return true;
       }

       protected virtual void OnAfterWithdraw() { }

       public void Close()
       {
           if (OnBeforeClose())
               Active = false;
           OnAfterClose();
       }

       protected virtual bool OnBeforeClose()
       {
           return true;
       }

       protected virtual void OnAfterClose() { }
   }
}

If you expand the previous block of code you will see that the implementation of IAccount is only doing business stuff. There is no other responsibility in this class than the one that is meant for. We can clearly see “Template Method” design pattern here. All “OnSomething()” method are protected and any derided class can add implementation around the process. All “Before” method can cancel the process if the return value is false. This allow extension classes to add some specific behaviour.

But one of the main thing missing in this class is “validation”. We will use the decorator pattern to do that. A decorator class is a class thst implement all the member of an abstraction and forward all the calls to an internal instance of a real implementation that abstraction. In our case the abstraction is “IAccount” so we have to make a decorator that implement that interface.

namespace Model.Decorator
{
   public abstract class AccountDecorator : IAccount
   {
       private readonly IAccount _account;

       protected IAccount Account
       {
           get { return _account; }
       }

       protected AccountDecorator(IAccount account)
       {
           _account = account;
       }

       public string AccountNumber
       {
           get { return Account.AccountNumber; }
       }

       public decimal Balance
       {
           get { return Account.Balance; }
       }

       public bool Active
       {
           get { return Account.Active; }
       }

       public virtual void Deposit(decimal amount)
       {
           Account.Deposit(amount);
       }

       public virtual void Withdraw(decimal amount)
       {
           Account.Withdraw(amount);
       }

       public virtual void Close()
       {
           Account.Close();
       }
   }
}

As you can see the constructor of the decorator takes an instance of “IAccount”. All method forward their call to that instance. This base class simplifies the process of creating concrete decorator by allowing other decorator to implement some but not all members of the interface.

Now is the time to start implementing our validation class structure. For that purpose we will create a base validation class that will be responsible of applying the validation the IAccount instance.

using System.Collections.Generic;
using Model.Decorator;

namespace Model.Validator
{
   public abstract class AccountValidatorBase : AccountDecorator
   {
       protected abstract IEnumerable<IValidation> GetValidations(decimal amount);

       protected AccountValidatorBase(IAccount account) : base(account) {}

       protected void Validate(decimal amount)
       {
           foreach (var validation in GetValidations(amount))
               if (!validation.IsValid)
                   throw validation.Exception;
       }
   }
}

This simple base class define a “GetValidations” method that all derived class must override to add a list of validation to perform on method call.

Now to implement the “Deposit” validation we have to create this class:

using System.Collections.Generic;
using Model.Validation;

namespace Model.Validator
{
   public class AccountDepositValidator : AccountValidatorBase
   {
       public AccountDepositValidator(IAccount account) : base(account) {}

       protected override IEnumerable<IValidation> GetValidations(decimal amount)
       {
           return new List<IValidation>
           {
               new AmountGreaterThanZeroValidation(amount),
               new AmountShouldHaveOnlyTwoDecimals(amount),
               new AccountMustBeActiveValidation(Account),
               new DepositAmountNotExceedMaxValidation(Account, amount)
           };
       }

       public override void Deposit(decimal amount)
       {
           Validate(amount);
           Account.Deposit(amount);
       }
   }
}

This class is responsible for creating all validation instances. The “Deposit” method is overridden to call the base “Validate” method before doing the actual deposit.

To implement those validation we need to define the “IValidation” interface.

using System;

namespace Model.Validator
{
   public interface IValidation
   {
       bool IsValid { get; }
       Exception Exception { get; }
   }
}

Here is a sample implementation:

using System;
using Model.Validator;

namespace Model.Validation
{
   public class AmountGreaterThanZeroValidation : IValidation
   {
       public AmountGreaterThanZeroValidation(decimal amount)
       {
           Amount = amount;
       }

       public decimal Amount { get; set; }

       public bool IsValid
       {
           get { return Amount > 0; }
       }

       public Exception Exception
       {
           get { return new ArgumentOutOfRangeException("amount", Amount, "Deposit amount should be greater than 0."); }
       }
   }
}

All other validations used in “AccountDepositValidator” can be described the same way.

The last step is to create an actual “IAccount” that will implement all this stuff. To do that we will need a Bank class. A bank is responsible of creating account. It will also be responsible of decorating it with all necessary decorators.

using System;
using System.Collections.Generic;
using Model.Logging;
using Model.Validator;

namespace Model
{
   public static class Bank
   {
       static readonly SortedDictionary<string, IAccount> _accounts = new SortedDictionary<string, IAccount>();
       private static int _accountSequence = 1;

       public static IAccount CreateAccount(decimal balance)
       {
           string accountNumber = String.Format("A{0:0000}", _accountSequence++);
           IAccount account = new Account(accountNumber, balance);
           account = new AccountDepositValidator(account);
           _accounts[account.AccountNumber] = account;
           return account;
       }
   }
}

To illustrate this process in action here is a sequence diagram:

1. Call Bank.CreateAccount.
2. The Bank instantiate an Account class.
3. The Bank create an AccountDepositValidator and wrap Account with it
4. The Bank return an instance of IAccount.
5. Deposit is called on IAccount which is an instance of AccountDepositValidator
6. AccountDepositValidator call Validate
7. AccountDepositValidator call GetValidations to retrieve the list of validation to evaluate
8. An AmountGreaterThaZeroValidation is created
9. IsValid returns true
10. AccountDepositValidator call base Deposit method
11. Balance value is updated

Next

With all this in place the only thing left to do is to implement all the other validators for all method of “IAccount”.