Great Axioms for Architects

Great collection of axiom for real architects.

http://97-things.near-time.net/wiki

Similarity between coaching a sports team and developers’ team

Nice one to read:
http://www.infoq.com/articles/sport-coaching-and-agile

If we follow principles explained in pragmatic way , we can make difference in our team's output as well.

Yield and Iterator: Better way of Iterating over Custom Collection

PreYield Era of Coding:

foreach loop can be called only on class which implement IEnumerable interface and defines a method GetEnumerator which return instance of class implementing IEnumerator interface.

The old way of defining the custom collection is to define a class which implements IEnumerable interface and has custom enumerator which implements IEnumerator.
The custom enumerator class has to implement MoveNext, Reset methods along with Current property.

So to have foreach on the custom collection, code has to be written some thing like following:

public class Student
{
private string _firstName;
private string _lastName;
private int _rollNumber;

public Student(string firstName, string lastName, int rollNumber)
{
_firstName = firstName;
_lastName = lastName;
_rollNumber = rollNumber;
}

public string FirstName
{
get { return _firstName; }
}

public string LastName
{
get { return _lastName; }
}

public int RollNumber
{
get { return _rollNumber; }
}
}
public class StudentCollection : IEnumerable
{
private Student[] _student;
public StudentCollection(Student[] student)
{
_student = student;
}
public IEnumerator GetEnumerator()
{
return new StudentEnumerator(_student);
}
}
public class StudentEnumerator : IEnumerator
{
private Student[] _student;
private int _currentIndex = -1;
public StudentEnumerator(Student[] student)
{
_student = student;
}

public bool MoveNext()
{
_currentIndex++;
return (_currentIndex <>

}

public void Reset()
{
_currentIndex = -1;
}

public object Current
{
get
{
return _student[_currentIndex];
}
}
}

Caller place will have code some thing like:

static void Main(string[] args)
{
Student [] studentArray = new Student[]
{
new Student("Ajay", "Mishra", 1),
new Student("Vijay", "Mishra", 2),
new Student("Mohan", "Jha", 3),
new Student("Sohan", "Jha", 4)
};
WithoutYield(studentArray);
Console.ReadLine();
}

private static void WithoutYield(Student [] studentArray )
{
StudentCollection studentCollection = new StudentCollection(studentArray);
foreach(object student in studentCollection)
{
Student tempStudent = student as Student;
Console.WriteLine(tempStudent.FirstName+" "+ tempStudent.LastName+ " "+ tempStudent.RollNumber.ToString());
}
}

From above it is quite clear that one has to churn out bit extra code to call foreach loop on the custom collection class.

PostYield Era of Coding:

The kickass feature “yield and iterator” of C# 2.0 comes as savior to allow developer to remove all the highlighted code in above block.
Now foreach loop can be called even on class which has method GetEnumerator only. One does not need to define class which implement IEnumerable interface. This really allows developer to write short code and looks much maintainable.

To have foreach loop on custom class one can write the code like following:

public class Student
{
private string _firstName;
private string _lastName;
private int _rollNumber;

public Student(string firstName, string lastName, int rollNumber)
{
_firstName = firstName;
_lastName = lastName;
_rollNumber = rollNumber;
}

public string FirstName
{
get { return _firstName; }
}

public string LastName
{
get { return _lastName; }
}

public int RollNumber
{
get { return _rollNumber; }
}
}

public class StudentYieldCollection
{
private Student[] _student;

public StudentYieldCollection(Student[] student)
{
_student = student;
}


public IEnumerator GetEnumerator()
{
for(int counter = 0; counter< _student.Length; counter++)
{
yield return _student[counter];
}
}
}

static void Main(string[] args)
{
Student [] studentArray = new Student[]
{
new Student("Ajay", "Mishra", 1),new Student("Vijay", "Mishra", 2),
new Student("Mohan", "Jha", 3),new Student("Sohan", "Jha", 4)
};
WithYield(studentArray);
Console.ReadLine();
}



private static void WithYield(Student [] studentArray )
{
StudentYieldCollection studentCollection =
new StudentYieldCollection(studentArray);
foreach(Student tempStudent in studentCollection)
{

Console.WriteLine(tempStudent.FirstName+" "+ tempStudent.LastName+ " "+ tempStudent.RollNumber.ToString());
}
}
}

Looks impressive? Huuh.

Iterator is the method which contains yield statement.

Did you see any strange in above implementation?
GetEnumerator method returns object rather than returning and instance of class which implements IEnumerator. :-(

I don’t care for it because C# does all under cover for me :-)

Looks impressive? Huuh. Iterator is the method which contains yield statement.

Did you see any strange in above implementation?
GetEnumerator method returns object rather than returning and instance of class which implements IEnumerator.  :-(

I don’t care for it because C# does all under cover for me  :-)

Microsoft Build Sidekick

I worked on a task where I had to modify our NANT build file to MSBuild file and I had to all those changes in notepad.
Sometime I wonder why I never did googling for "UI editor for modifying the MSBuild file". It may not be very important finding but I thought to put it blog because I made a mistake by not doing even basic analysis work before starting a tedious work.

The tool I found was Microsoft Build Sidekick, more information can be found @ http://www.attrice.info/msbuild/index.htm.

Normalization - Where to Stop?

Why most designers don't go beyond the 3NF?

The First thing we learn in our DBMS Topics is Normalization. Whether you are a data modeler, DBA, or SQL developer, normalization is one of those topics we all learn. We learn this early either at work or during our formal IT degree.

But take a look at most production databases. The best you will find that the database has been implemented using Third normal form (3NF). Very few databases reflect higher normal forms, such as Boyce-Codd normal form (BCNF), the Fourth normal form (4NF), and the Fifth normal form (5NF). So, why don't most database designers go beyond the 3NF?

If you want to know what these normal forms are, they can be found in my previous post for your reference.

How far should you go with normalization?
To be sure, each progressive step may impact upon overall performance. I have seen normalization taken to absurd lengths. In one of the recent discussion one person came out with the idea of different financial document types. As though the world of accounting is going to change. I had to remind him that Accounting is just the recording of historical events :)

A while ago I was reading an article and there the author mentioned about the normalization. Over a period of time I learnt to ask few questions before I decide how much normalization is required.
1. What is the nature of the system. Is it an OLTP or OLAP system?
2. What is the nature of DB Query. Are they mostly Insert or Retrieve?
3. For Part of DB where the inserts are more, its better to have the Data in 3rd normal form.
4. For system where Retrieve operation is more than Inserts, 2nd Normal form is the best.

Where you draw the line in the sand is ultimately up to you, but you will be better equipped to draw it with a sound understanding of the various normal forms and the risks of not going far enough.

Until Next Time... :)

Database Normalization

I was talking to a developer a while ago and when I started talking about database normalization the other person was kind of lost in a vaccum. I was wondering what happened, but then realized that he does not know much about the normalization and he finds it kind of boring. Boring because all the text books give very lengthy explanation of normalization and most of the times they are boring to read :)


Being a Developer It's important to understand the differences between 3NF, BCNF, 4NF, and 5NF along with other normal forms. Here are concise definitions of each normal form.

First normal form (1NF)
Each table must have a primary key, i.e., a minimal set of attributes that can uniquely identify a record. Eliminate repeating groups (categories of data that would seem to be required a different number of times on different records) by defining keyed and non-keyed attributes appropriately. Atomicity: Each attribute must contain a single value, not a set of values.

Second normal form (2NF)
The database must meet all the requirements of the 1NF. In addition to that, if a table has a composite key, all attributes must be related to the whole key. And, data that is redundantly duplicated across multiple rows of a table is moved out to a separate table.

Third normal form (3NF)
In Addition to all the requirements for 2NF, The data stored in a table must be dependent only on the primary key and not on any other field in the table. Any field that is dependent not only on the primary key but also on another field is moved out to a separate table.

Boyce-Codd normal form (BCNF)
There must be no non-trivial functional dependencies of attributes on something other than a superset of a candidate key (called a superkey).

Fourth normal form (4NF)
There must be no non-trivial multi-valued dependencies of attribute sets on something other than a superset of a candidate key. A table is said to be in 4NF if and only if it is in the BCNF and multi-valued dependencies are functional dependencies. The 4NF removes unwanted data structures: multi-valued dependencies.

Fifth normal form (5NF)
There must be no non-trivial join dependencies that do not follow from the key constraints. A table is said to be in the 5NF if and only if it is in 4NF and every join dependency in it is implied by the candidate keys.

Happy Reading :)

Until Next time... :)

Scaling Agile Development Via Architecture

Nice artcile to read for people involved in architecture with Agile.
http://www.agilejournal.com/content/view/146/

Way of implementing Dependency Injection

I am working on spring .NET for last of couple of months so thought to put my understanding of idea behind Sring.NET framework in following words.

Any cohesive application made of lots of reusable components. A good designer always dream of reducing the dependency among components in application. Dependency Injection allows coder to get rid of such menial tasks of creating of instances and setting the dependency of objects in code.

Dependency Injection using Factories:

Factories provide centralized approach to handle to instance creation and resolve the dependency among components and hence provide easier way of code maintenance which could have been big mess if such things solved in decentralized way. Using encapsulation Factories shields the information about object creation and it also hides the information about how factored components fit with each other in architecture of the application. All the client code has to do is to call create instance of factory method.

Following is sample code to achieve dependency injection using Factories:

Factory Code:

using System;

namespace DependencyInjectionFactory

{

public interface IFactoredProduct{}

public class ConcreteFactoredProduct:IFactoredProduct{}

public abstract class AbstractProduct

{

protected IFactoredProduct _factoredProduct;

protected AbstractProduct(IFactoredProduct factoredProduct){}

}

public class ConcreteProduct:AbstractProduct

{

public ConcreteProduct(IFactoredProduct factoredProduct)

:base(factoredProduct){}

}

public class ConcreteProductTwo:AbstractProduct

{

public ConcreteProductTwo(IFactoredProduct factoredProduct)

:base(factoredProduct){}

}

public enum AbstractFactoryEnum

{

ConcreteFactory1,

ConcreteFactory2

}

public abstract class AbstractFactory

{

public abstract AbstractProduct Create();

public static AbstractFactory GetFactory(AbstractFactoryEnum enumValue)

{

if(enumValue == AbstractFactoryEnum.ConcreteFactory1)

{

return new ConcreteFactory1();

}

else if(enumValue == AbstractFactoryEnum.ConcreteFactory2)

{

return new ConcreteFactory2();

}

return null;

}

}

public class ConcreteFactory1:AbstractFactory

{

public override AbstractProduct Create()

{

//Object creation and dependecy issue is solved here

return new ConcreteProduct(new ConcreteFactoredProduct());

}

}

public class ConcreteFactory2:AbstractFactory

{

public override AbstractProduct Create()

{

return new ConcreteProductTwo(new ConcreteFactoredProduct());

}

}

}

Client Code:

AbstractFactory factory =

AbstractFactory.GetFactory(AbstractFactoryEnum.ConcreteFactory1);

AbstractProduct product = factory.Create();

//Client code calls Create method of Factory

Console.WriteLine(product.GetType().ToString());

From boilerplate wiring point of view factories has following problems:

1) Instance creation code is hard coded in implementation of factory and thus makes it non extensible. Client code as seen in above code has to know what kind of factory has to be created.

2) All dependencies of objects are well known at compile time.

Dependency Injection using Containers:

Above problems can be solved by containers. Containers provides one layer of abstraction through allow client code to get rid of life cycle management and dependency issues. Containers are not new concept and have been in MS platform for long time now. MTS, CLR are some of the examples of heavy weight containers. In .NET world Spring.NET (http://www.springframework.net/) allows you to create custom light weight containers.

Following is the code which solves same problem described above (DI using factories) in bit different way.

Source Code:

using System;

namespace DependencyInjectionContainer

{

public interface IFactoredProduct{}

public class ConcreteFactoredProduct:IFactoredProduct{}

public abstract class AbstractProduct

{

protected IFactoredProduct _factoredProduct;

protected AbstractProduct(IFactoredProduct factoredProduct){}

}

public class ConcreteProduct:AbstractProduct

{

public ConcreteProduct(IFactoredProduct factoredProduct)

:base(factoredProduct){}

}

}

In Container approach instance creation and object plumbing is done thorough configuration file and thus avoid any hard coding like Factories approach.

xml version="1.0" encoding="utf-8" ?>

<configuration>

<configSections>

<sectionGroup name="spring">

<section name="context" type="Spring.Context.Support.ContextHandler, Spring.Core" />

<section name="objects" type="Spring.Context.Support.DefaultSectionHandler, Spring.Core" />

sectionGroup>

configSections>

<spring>

<context>

<resource uri="config://spring/objects" />

context>

<objects>

<object id="concreteProduct" type="DependencyInjectionContainer.ConcreteProduct,DependencyInjection">

<constructor-arg name="factoredProduct" ref="factoredInstance" />

object>

<object id="factoredInstance" type="DependencyInjectionContainer.ConcreteFactoredProduct,DependencyInjection">object>

objects>

spring>

configuration>

Client Code: The way Client code consumes created object is:

IApplicationContext appContext = ContextRegistry.GetContext();

Console.WriteLine(appContext.GetObject("concreteProduct").GetType().ToString());

More on “Dependency Injection” can be found in interesting article from Martin Fowler @ http://www.martinfowler.com/articles/injection.html#FormsOfDependencyInjection