Csharp Patterns

--- Design Patterns: Solidify Your C# Application Architecture with Design Patterns http://msdn.microsoft.com/msdnmag/issues/01/07/patterns/

Patterns include:

SingletonPattern:
ObserverPattern:
The AbstractFactoryPattern:
Asynchronous Programming Design Pattern:
Design Patterns Used by Reflection Classes:
.NET Event Handling using the TemplateMethodPattern:
Implementing the PrototypePattern:
BuilderPattern:
Design Patterns in C#: The DecoratorPattern:
BridgePattern in C#:
AdapterPattern in C#:
MementoPattern in C#: "Object Serialization with the Memento Pattern"
The Dispose Design Pattern
Design Patterns Snippets in C Sharp
UML & Design Principles for C#

Resources

Many of the patterns above are detailed in the following:

--- A quick summary of the DisposePattern?:

An object that manages resources that need to be explicitly released implements the IDisposable interface, which has a single method, called Dispose, which is implemented something like this:

 protected virtual void Dispose(bool disposing) {
if(!this.disposed) {
if(disposing) {
ReleaseManagedResources?();
}
ReleaseUnmanagedResources?();
}
this.disposed = true;         
 }

From Microsoft's SDK docs:

''Dispose(bool disposing) executes in two distinct scenarios. If disposing equals true, the method has been called directly or indirectly by a user's code. Managed and unmanaged resources can be disposed.

If disposing equals false, the method has been called by the runtime from inside the finalizer and you should not reference other objects. Only unmanaged resources can be disposed.''

So, in the context of something like a database connection, there might be a public Close() method which calls the protected Dispose(true) method, and a Finalize() (or 'destructor') method - called by the runtime during GC - which calls Dispose(false).

And one other factor of the pattern recommended by JeffreyRichter? in Applied Microsoft .Net Programming: If called explicitly, the Dispose method should call GC.SuppressFinalize?(this). Since the Dispose method has freed unmanaged resources, there is no longer need for the garbage collector to call the class's destructor. Because garbage collection is more efficient on non-Finalizable types, the explicitly called IDisposable.Dispose method should suppress the no-longer needed destructor.

In C#, client code manages disposable objects with the "using" keyword. This:

 using (SomeObject? o = new SomeObject?())
 {
    o.DoSomething?();
 }

is equivalent to this:

 SomeObject? o = new SomeObject?();
 try
 {
    o.DoSomething?();
 }
 finally
 {
    o.Dispose();
 }

CeeSharp makes the Singleton pattern pretty easy:

 sealed class Singleton {
    private Singleton() {}
    public static readonly Singleton Instance = new Singleton();
 }

I found MSDN's explanation of asynchronous programming to be confusing, so I wrote my own notes and example: http://kristopherjohnson.net/kj/AsynchronousDelegate. --KrisJohnson

--- Enterprise Solution Patterns Using Microsoft .NET (.pdf Download)

Microsoft have put together a book, available in PDF format at:
It's one of those self-extracting executables but unzip on linux extracted the pdf without any problems.
Large parts of it seem to be language specific rehashes of patterns in Fowler's PatternsOfEnterpriseApplicationArchitecture and the GoF book but that's not necessarily a bad thing.
On the other hand their singleton example uses DoubleCheckedLocking. Does anyone know if that actually works in C# or do the issues why DoubleCheckedLockingIsBroken in Java also apply here?

--AdewaleOshineye

Yes, DoubleCheckedLockingIsBroken in C#. For the nitty gritty, google for "chris brumme" and "memory barriers". --CharlesReilly?

Books:

DesignPatternsCsharp (book)
DotnetDesignPatternsFramework?

CategoryDotNet