Design Pattern Reference

Here are some of the best articles on design patterns on the internet. Once you review the examples and discussions, its best to do some comparisons next.

1. Facade.
2. Flyweight
3. Adapter
4. Chain of Responsibility
5. Singleton
6. Observer
7. Composite
8. Command
9. Strategy
10. Proxy.
11. Decorator
12. Broker
13. Builder
14. Dependency Injection
15. State
16. Bridge
17. Interface
18. Prototype

Interesting comparisons to do:

Facade, Adapter: Facade works on an entire subsystem (multiple classes) to make suability simpler and Adapter generally does not target simplicity as much as mapping one set of calls to another.
Proxy, Decorator: Proxy pattern binds the class being proxied with the proxy class at compile time. Decorator does this at runtime. Decorator typically intends to add or remove functionality while Proxy typically exposes full functionality. In most cases, proxy always uses lazy instantiation for the class which is being proxied and decorator will typically instantiate the containing class in the constructor.
Chain of Responsibility, Decorator: Think linked lists v/s wrappers. Linked lists can kill the flow at any time w/o visiting all elements. In addition wrappers implement both pre and post processors.
Decorator, Inheritance: If each operation implemented by a decorator is instead implemented as a sub class, you will have to create multiple combination sub-classes for each combination which can be produced using a decorator sequence. Think m+n v/s m 'times' n for the total number of classes.
Strategy, Dependency Injection: DI is a refinement of Strategy pattern.
Strategy, Command: Strategy pattern can be used when implementations change for a task amongst different classes (which implement the same interface). Command on the other hand is much simpler. It makes sense when the caller does not want to get involved in the details of how a handler implements a certain command.

UML Refresher

Here is a quick UML refresher for class diagrams.

1. Inheritance is indicated by a solid line with a closed, unfilled arrowhead pointing at the super class
2. A dotted line with a closed, unfilled arrow means implementation of the interface it is pointing to
3. A bi-directional association is indicated by a solid line between the two classes. At either end of the line, you place a role name and a multiplicity value.
4. A uni-directional association is drawn as a solid line with an open arrowhead pointing to the known class.  In a uni-directional association, two classes are related, but only one class knows that the relationship exists.
5. A basic aggregation relationship indicates that one class is a part of another class. In an aggregation relationship, the child class instance can outlive its parent class. To represent an aggregation relationship, you draw a solid line from the parent class to the part class, and draw an unfilled diamond shape on the parent class's association end.
6. A composition aggregation relationship is just another form of the aggregation relationship, but the child class's instance lifecycle is dependent on the parent class's instance lifecycle. The composition relationship is drawn like the aggregation relationship, but this time the diamond shape is filled.
7. Attributes/operations visibility: +/public, #/protected, -/private, ~/package.

Reference

Mapping IIS worker processes to pools

Once in a while you have to diagnose memory or performance issues with .NET applications. The first indication comes from the Windows task manager which may indicate a process hogging the CPU/memory or users may complain of excessive slowness. In my particular case, I recently examined an IIS6 worker process which was spinning at 20% and using 1GB of memory on a 32 bit Windows 2003 Server. Combine with user complaints that the system was extremely slow and unresponsive, it was something to look into. The investigation is still ongoing, but I am documenting the steps taken so far.

Step #1: Find out which application or applications are causing the problem. Using the process ID from the task manager, you can use one of the following methods depending on whether this is IIS6 or IIS7

1. On II7 the IIS Manager gives an option to locate running worker processes, the pools they belong to and the requests they are currently processing right from the GUI. 
2. On II6, this can get a little tricky. A little VB Script can be of help: IISApp.vbs. Since it is typically found in the system folders, you can pretty much run it directly from the command tool. Note that this script won't be found on IIS7 installs.

Step #2: The next step typically is to start tracking performance counters and see which ones may indicate problems. From the command prompt, type "perfmon". Using perfmon, you can turn on different performance counters. The slowness can be due to a variety of reasons. There could be a queue which is getting very long - a processor or network queue for example or system is doing too many context switches or there are too many interrupts or .NET garbage collection could be going on. The important point is to pick a place to start and find patterns. For example, I noticed that the processor queue length was relatively high and the context switches were very high in the system. The next step, it seemed to me was to try and isolate the process threads which were switching in and out and what was causing them to block so the OS would switch the thread out.

Perfmon shows multiple instances of the same process with suffixes like "#1", '#2' etc. This is not very helpful and brings us to Step #3 meanwhile in the digging process:

Step #3 The following article from Microsoft describes how to fix perfmon to print process IDs instead.

http://support.microsoft.com/kb/281884