Enum can now have method

Thanks to Extension method.

Have you ever programmed against enum in the .NEt framework. Have you realized that the .NEt enum is not as efficient as other enum living in other platforms like the Java Land. Still the .NET enum is suffering from advance ways of using constants. An .NET enum cannot even have a method (Thats how bad it is) this is referred to constants specific method in Java.

But with the method extension in the .NET framework 3.5, we can pro grammatically extend an enum with methods that makes us think that they are actually defined within the enum scope.

public enum MyEnum
{
Name,
Age,
}

public static string RealName(this enum myEnum)
{
return Enum.GetName(typeof(MyName), myEnum);
}

MyEnum enn = MyEnum.Name,

enn.RealName();

Pragmatic Approach To development. (Developing for Today and Tomorrow)

Recently i have been engrossed in a project that will contribute to the way we develop system rapidly. This project is an ORM framework that maps the impedance mismatch between the relational world and the object oriented world. I must confess its one of those projects that does not have a finished date, its a project that will continuously apply the current trend in our no destination journey of system development. What i meant by no destination is that software evolves overtime and there is no promise land, is either we re-invent the wheel and make it a better wheel or we introduce a new form of practices or complexity.

I started on this project out of frustration because designing data access frameworks per the project isn't a good development practice this can lead to inconsistent development methodologies and framework will be prone to errors. In my software development lifetime i have worked on several real world projects in their hundreds, and i understand fully well what fits well in what area. Dont get me wrong, i do mistakes too, but i accept these mistakes immediately and i make it my strength. So, over the years, i have struggled to find a long lasting solutions to poor and repeated programming approach.

Develop For Tomorrow
One of the greatest software practice i have learn't is not letting requirement to control the software but letting the software development process think ahead of what the requirement maybe in the nearer future. This is a proactive approach to developing a scalable and reliable applications that will cut across different environment and requirements.

Most of us, developers allow software requirements to drive and predict the architecture of our software for us, so when requirement changes, we need to change heavy chunk of our code. To me thats a very bad approach and it could be very costly to organisations that are practicing such approach. Where is separation of concern, where is pragmatic development.


Requirement Volatility does not mean software volatility
Feasibility checks should be done on requirements before the changes can be made. Even without full requirement, software should be built with adaptability and reconfigurability in mind, this will ensure that the volatility nature of requirements does not affect system development.


Separate as many concern as you like
Recently, in Microsoft (MSDN) Forum, somebody asked a question about separating the a UI framework or layer from a data layer, many suggestions where given to this question, some say use DTO (Data transport Object) some say use interface, the bottom line is use something that wont have adverse effect on your codebase even when the underlying structure changes, be very pragmatic and scrutinize the kind of changes that are anti pattern, we are not in the procedural programming ERA, we are developing in the world of Objects (Think in objects).

Beware of hard-coding
One of the major setback of good programming practices is hard coding. When developers hard code, it shows how vulnerable our codes can be, and how it is difficult to maitain and sustain. I wonder why we will leave a pragmatic approach to development (Even if it takes time, lets do it right). So never hard code, instead create constant file or xml or use enum.