.Net Design patterns

Design patterns are recurring sequences, built-in .Net patterns are scattered over the framework.

In practice following standard software patterns will help to achieve a more standard code, that is manageable, and understandable by a bigger set of software programmers/developers and architects.

For example the data adapter factory, that enables the creation of specific DBMS adapters. This centralized class helps in establishing a strong data layer, that supplies a more generic way to communicate with business layer.

For example:

Imports System.Data.Common

dbPFactory = DbProviderFactories.GetFactory(“FactoryName”)
adapter = dbPFactory.CreateDataAdapter()

In simple technical english, a factory pattern is responsible for managing and creating product class instances from a base class that has increasing or more than one number of child classes. The DbProviderFactories is a factory of factories, that manages the dbms adapters in .Net 2.0. Building a class wrapper over this architecture and supplying the correct parameters will enable the direct generation of specified data adapters to communicate with most of the standard DBMS in the market.

Singleton pattern is implemented in many places in the .net framework, single instance window applications, also in remoting we deal with singleton classes.

A singleton pattern can be achieved by forbidding the creation of direct class instance, using the constructors. This is done by making constructors private, and preventing the user from creating an instance of the class.

This enables only the creation of instances from class scope. To enable single instance in memory we use static or shared reference to the class, we make it private to prevent public access, and we set it to NULL.

We add a static or shared function that checks if the class static reference is NULL, if NULL an instance is created, otherwise the previous instance is returned.

The .Net frame makes good use of the proxy pattern , that is a mediator between the real object and the client object. When applying proxy design pattern, the proxy class provides the same services as the real object. That is they inherit from same base class, or apply the same interface. Proxy classes are used in remoting, and when communicating with services.

Such patterns define the extensions road map for the framework, using these patterns will allow your application benefit a great deal, for extendability and code maintenance.

This was an introduction to .Net Design patterns, I an example of using DBFactory to create a generic adapter can be downloaded using the following link http://www.codeproject.com/KB/dotnet/dotNetDesignPatterns_.aspx.

Regards

Rabeeh Abla

Refactoring - Functions

Rules:

- A function does only one goal, or a grouped goal created from sub goals.

- A set of instructions is formed into a function, if it achieves a certain job that can be of multiple or future use.

- Instructions that can not be grouped into one goal or job , are classified under compound functions, and should be partitioned into sub functions.

Functions should follow defined patterns, for example a function will be more manageable if has defined exit points, increasing the exit points by adding returns, will make the function harder to debug, maintain and fix.

Return types should be documented, for example if return type is Boolean, the values that will be returned belong to the following set : {True, False}, this is manageable.

But if the return type is of bigger set for example integer belonging to set {…,-3,-2,-1,0,1,2,3,4,…}, and the function logic we wrote calculates values that belong to a smaller set N of non-negatives.

We pattern our function ‘return type’ domain to the following:

- Positive as legal value
- 0
- -1 as Error occurred for example, or nothing found

The idea is to define boundaries for the return type domain, in order to remove ambiguity.


Variables and References // global to function

Info resultInfo { Success, Result, Error}

Try
{

Critical Code instructions

resultInfo.Result = {Code Result}

}
Catch(Exception ex)
{

resultInfo.Error = ex.Message

resultInfo.Success = false // Signal failure

Log(ex) // Log error

}
Finally
{

Recurring logic, clean up or concluding calculation

}

Return resultInfo

Naming patterns

Choosing friendly variable names, types, and Methods will help in making the code easier to read understand and use.

Enumeration Type Naming Guidelines

Namespace Naming Guidelines

Class Naming Guidelines

Interface Naming Guidelines

Method Naming Guidelines

Parameter Naming Guidelines

Documentation

Documentation is very important, there is an old famous saying "The computers will always understand the code, but humans will not" writing for yourself and others.

Documenting function parameters and return values.

Using friendly names that reflects the algorithm flow and motive.

Practice documentation at programming-time, document the function role and motive, if the function impacts on shared or global data it is important to write the pre and post states that should happen and will occur.

Documentation should be at all levels from class responsibilities and role, global variables, methods their parameters, and complicated instructions.

Documenting class relations, using UML (Unified modeling language) to display the architecture used, and help with extension of the code.

Documenting the whole software cycle from requirement phase to developing phase will enable later the maintenance at minimum cost.