Decorator Pattern in .Net Framework

Decorator Pattern is a structural pattern. It is used to attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.

Decorator pattern is used in .Net. The following collection classes are the decorators of the ArrayList class:

1. SyncArrayList: This denotes a synchronized arraylist which can be used multithreading scenario. This arraylist is to be used when multiple threads are to modify a single instance of arraylist.


2. FixedSizeArrayList: This denotes a fixed size arraylist. The size of the array list cannot be changed. Elements cannot be added and removed. Existing elements can be replaced.


3. ReadOnlyArrayList: This denotes a read-only arraylist. Elements cannot be added and removed. Existing elements cannot be replaced.

All the above decorators are defined as following:

private class [Sync/Fixed/ReadOnly]ArrayList : ArrayList

{

internal [Sync/Fixed/ReadOnly]ArrayList(ArrayList arrayList) {...}

}

The above structure is the proof of all the aboved mentioned classes to be a deocorator of the ArrayList class.

All the above deocorators are private and can be instantiated using the static methods provided on ArrayList class:

All the decorators override appropriate virtual methods and adds the additional behavior. Below shows the sample code snippet for the Synchronized arraylist the decorators:

Similarly ReadOnlyArrayList overrides the virtual method of the ArrayList class and throws exception to restrict any modifications in the list.

In a similar manner FixedSizeArrayList overrides the virtual method of the ArrayList class and throws exception to restrict any changes to the size of the list.

This is how the decorator pattern is being used in .net framework. There are possibilities of decorator pattern being used at multiple places in the framework. It can be found out by studying the framework thoroughly and understanding the patterns used in the framework.

Guard Clause

Every method has some behavior or expectations to be fulfilled. The logic required to fulfill the expectations is called as the main flow of the method. Any deviation or exceptional case to the main flow can be represented as a guard clause. A guard clause is a condition and an action which is a deviation to the main flow of the method.

A deviation in a main flow of a method can be:

• Object State Check (Precondition Check)
• Parameter Check (Precondition Check)
• Range check (Precondition Check)
• Validity check (Precondition Check)
• Any logic which is part of the main flow but it is a distraction to the code readability

Guard clause can be used to separate the main flow from the distracted deviation in the main flow.

Below example shows how guard clause can be used to increase the readability of code

Before
DomainObject FetchObject(ObjectSpecification specification)
{
if (specification == null)
{

throw new ArgumentNullException("specification");
}
else
{
objectFetcher.Fetch(specification);
}
}

After
DomainObject FetchObject(ObjectSpecification specification)
{
if (specification == null)
throw new ArgumentNullException("specification");

objectFetcher.Fetch(specification);
}

Guard clause when applied properly can improve the readability of code. In fact it is one of the re-factoring techniques suggested by Martin Fowler. The name of the re-factoring technique suggested by martin fowler is ‘Replace Nested Conditional with Guard Clauses’

CodeProject

"Prevention is better than cure"

"Prevention is better than cure" can be applicable to the software development in regards to defects.

Fixing defects is not a cost free activity. Defect fixing is a costly activity. If the defect is found at the later stage of the software development, the greater the cost of fixing it. Hence it is always better to prevent the defects and also to fix it at the early stage of software development.

Below shows the tentative cost of fixing a bug at the respective stage of software development.

Phase - Relative Cost to Correct
Requirments - 1
High-Level Design - 2
Low-Level Design - 5
Coding - 10
Unit Testing - 15
Integration Testing - 20
System Testing - 50
Post-Release - 100+

Hence defect prevention should be given utmost important in the software development life cycle. Defect prevention can greatly reduce the cost and time to market of the software.

"Prevention of defects is better than fixing it"

Facade Pattern (Part 1): What? and When?

Facade is a structural pattern whose purpose is to provide a unified and simplified interface to the complex sub-system.

The dictionary meaning of facade is:

1. "A face or front of a building"
2. "A showy misrepresentation intended to conceal something unpleasant"

In our day to day life we come across architecturally sound buildings. Now a days the trend is to have the front or the face of the building made up of glasses which give an elegant look. But the internal architecture of the buildings are found to be complex and distracting.

Facade is used when you want to hide something complex behind a simple and unified interface.

For e.g.

Assume that you are a master of OCR technology and have developed some complex OCR sub-system or package or library. This sub-system consists of about 50 odd classes. This package is to be consumed by some application, which is being developed by the application developers. These application developers do not have much knowledge about OCR technology. They just want to perform an OCR on some images and generate a word document out of it.

In these days of RAD and competitive market it is not feasible to first learn the OCR technology and then understand the complete OCR sub-system and then start consuming it. It is always better if the simplified and unified interface for the complex sub-system exists so that RAD can be achieved.

Hence to support RAD and to hide the underlying complexity of the sub-system, Facade can be used. Here facade provides a simplified interface to accomplish trivial tasks. To accomplish difficult or non-trivial tasks, the application programmer has to rely on the sub-system.

The crux of the matter is "Facade hides the complexity of the sub-system from the consumer".

I became blogger

Since last six months I was thinking to blog on technical stuff. Today I suddenly made up my mind and took the initiative. I will be blogging on various subjects like

1. Refactoring
2. Code Cleaning
3. Test Driven Development
4. .Net & C#
5. Puzzles
6. Code Quiz
7. Miscellaneous

I am planning to blog 4 entries per month.

The main aim behind this blog is to become a better developer and let other developers become better. The blog will deal mostly with the development (implementation) aspects of software development.

This blog is open for honest suggestions and feedback.

Happy Reading! Read it regularly and become a better developer.

Thanks, Andy