Sogeti Phoenix Blogs

Ever wonder how that magical tag called ‘[Serializable]’ placed at the top of a class enables it to be deconstructed into XML that can be tranmitted through firewalls or persisted in a files or database tables? Not to get too technical but attribute classes are embedded into the tagged classes’ metadata at compilation and can be reflected on to perform any function you desire. 

The following example provides a real world scenario where custom attributes can enhance one’s  coding experience.  I can’t tell you how many times I have to use stored procedures that have a million parameters each having the capacity to be null.  Think of a search procedure that has ten criteria.  If I was coding this with the SqlCommand class, I would have to write a method that creates each SqlParameter and populates it with DBNull or some value. There are over ninety nine combinations in this scenario.  That really cuts into my ebay time.

If I wrote an attribute that could turn a class into a SqlCommand with populated values and could be serialized in session or view state and reduce my time coding, life would be wonderful.  In addition, if I wrote a tool that generated the code for the attributed class, my evil plan to do no work would be complete!

I have attached a solution that contains all the code mentioned above.

AtrributeSolution.zip (51.43 kb)

Since I can remember, helper classes have been the backbone of coding since they comprise all the utilities that are missing in the .Net framework.  The downside is that one must keep track of all the assemblies, namespaces and various implementations as the toolset grows.  This can be a daunting task when considering each client’s library and the exhaustive resources available in the developer community. Wouldn’t be nice if we could simply extend the functionality of our existing libraries?

.Net 3.5 now allows classes to be extended by using a specific type of method declaration.

//The key work 'this' is included at the beginning 
//of the parameter list with the type to be 
//extended.  You can then do any type of implementation you like 
public static void DoSomething(this string str) 
{   
}

The following attached example illustrates taking a simple helper class used for encrypting strings and converting it into an extension that becomes part of the .Net framework. 

ExtensionExample.zip (94.54 kb)

Delegates are a big part of the .NET Framework. They were included since the beginning with .NET 1.0 and have matured since then, but in my experience I don't see them used intentionally too often.

I think the reason for this is because the concept of a delegate is kind of foreign if you have a more procedural background, using mainly languages like Visual Basic or Java, and to a certain extent, C. I certainly hadn't encountered anything like that until I started using C#, and had a difficult time wrapping my head around the concept.

To understand them better, let's take a look at the history of delegates, starting with the positively ancient and crusty .NET 1.0.

At the most basic level, a delegate serves as a way to treat a method as a variable. This means that it can be passed around to different methods, or have its execution delayed until deemed fit. A common reaction to this is "Why would I ever want to do that?" Well, it lets you do some interesting things. For starters, it makes it easier to perform certain kinds of logic at runtime without having to write a great deal of code.

And since every explanation is better with a little bit of code, let's get to it. As stated, delegates have been around for a while. With .NET 1.0, a delegate could only wrap an existing method, nothing on-the-fly:

// This is the definition of the delegate. The return type (void) and 
// arguments (int num) are the signature for any methods that 
// will be wrapped by this delegate.
public delegate void SomeFunction(int num);

// A standard method
public void PrintHello(int num) {
    for (int i = 0; i < num; i++) {
        Console.WriteLine("Hello."); 
    }
}

public void Main() {
    // PrintHello's signature matches what was declared by the 
    // delegate, so it can be used as a variable if needed.
    SomeFunction func = new SomeFunction(this.PrintHello);
    func(10);
}

Again, why does this even matter? The most useful thing about delegates is that you don't need to know which method needs to be called at compile time. One of the classical Design Patterns is the Command Pattern, which let's you abstract a common piece of functionality out to a variable, and pass it around... sound familiar? Delegates are not a complete substitute for the pattern, but can perform similar functionality with far less code. And less code is always better.

Additionally, .NET's event model is based on delegates. The EventHandler is really just a delegate that returns null and takes an Object and an EventArgs. They are also used with some of the asynchronous logic in the framework, BeginInvoke being primary.

For a real-world example, I've seen them used as a neat solution for some of the shortcomings with a Windows Form ToolBar. Back in .NET 1.1, the ToolBar still had many COM underpinnings, and the ToolBarButtons that made up the Bar did not have individual OnClick events on them; you had to handle the ToolBar's ButtonClick event, and pull the Button property from the event's arguments (this was a mess that was replaced with the ToolStrip in .NET 2.0). Once you got this, then you would need to perform some sort of test to determine the appropriate action method. Rather than have a 20 line select statement, one bright co-worker just wrapped the desired method in a delegate and dropped it into the button's Tag property. In just two lines he was able to accomplish what my 20+ did. I call that a bargain.

Here is an example of using delegates to implement a State Machine. This is just the framework for a machine, the strength of it lies in its ability to declare the edges of the graph dynamically.

public delegate Node EvalOp(State s);

public abstract class State {
    // State contains all information about the current position in the graph.
}

public class Node {
    private string _name;
    public EvalOp[] ops;

    public Node(string name) {
        this._name = name;
        this.ops = new EvalOp[] { };
    }

    public string Name {
        get { return this._name; }
    }

    public Node Evaluate(State s) {
        foreach (EvalOp op in this.ops) {
            Node n = op(s);
            if (n != null) {
                return n;
            }
        }
        // If we reach this point, we are at the end.
        return null;
    }

    private static Node _end = new Node("End");

    public static Node EndNode {
        get { return _end; }
    }
}

public abstract class Graph {
    protected Node[] nodes;
    protected Node currentNode;
    protected State state;

    public Graph() {
        this.Init();
    }

    public void Start() {
        for (this.currentNode = nodes[0]; this.currentNode != Node.EndNode; this.currentNode = this.currentNode.Evaluate(this.state)) { 
            this.Step();
        }
    }

    protected abstract void Step();

    // Create nodes and state here
    protected abstract void Init();
}

The basic operation is that each node contains an array of delegates (EvalOp) to define the edges to a new node. The EvalOp takes a State object and determines if it satisfies the requirements of the edge. If it does, it returns the next node to travel to. Each EvalOp is evaluated until the first valid Node is returned. It's not the most robust State Machine ever created, but I wanted to demonstrate delegates rather than State Machines.

I wrote a simple implementation to demonstrate it. There are three nodes, including the EndNode already created by the framework. One is called Odd, and the other is Even, and they switch back and forth depending on the value of State, which is incremented each step of the way, until 100 is reached.

public class ConcreteState : State {
    private int _count;

    // Note the lack of auto-properties in 1.0. Argh.
    public int Count {
        get { return this._count; }
        set { this._count = value; }
    }
}

public class ConcreteGraph : Graph {
    protected override void Init() {
        this.state = new ConcreteState();
        Node odd = new Node("Odd");
        Node even = new Node("Even");

        EvalOp oddTest = new EvalOp(this.OddOp);
        EvalOp evenTest = new EvalOp(this.EvenOp);
        EvalOp finishTest = new EvalOp(this.CountOp);

        odd.ops = new EvalOp[] { finishTest, oddTest };
        even.ops = new EvalOp[] { finishTest, evenTest };
        this.nodes = new Node[] { odd, even };
    }

    protected override void Step() {
        ((ConcreteState)this.state).Count++;
    }

    private Node OddOp(State s) {
        if (((ConcreteState)s).Count % 2 == 1) {
            Console.WriteLine("Odd");
        }
        return this.nodes[1]; // move to the even op
    }

    private Node EvenOp(State s) {
        if (((ConcreteState)s).Count % 2 == 0) {
            Console.WriteLine("Even");
        }
        return this.nodes[0]; // move to the odd op.
    }

    private Node CountOp(State s) {
        return ((ConcreteState)s).Count == 100 ? Node.EndNode : null;
    }
}

More complicated functionality could be added by just creating a new EvalOp delegate (like say, MultipleOfFourOp) and adding it to the proper node[s].

Delegates are not all roses of course. Their biggest shortcoming in 1.1, was that they were too rigid. You needed to have a method defined elsewhere in the app, and you couldn't do some of the neat things that other languages were able to do with similar constructs (typically called lambdas). Fortunately, .NET 2.0 significantly improved delegate's abilities and 3.5 made them extra delicious. I'll write more about them later.

XML is kind of a neat thing. It is generally human readable and well supported by everything under the sun. But, like everything else in the programming scope, it is imperfect. The problem I have with it is that it seems like everyone is trying to shoehorn technologies into it.

Let's back up a second. XML is a Declarative Programming Language. This means that it describes a process rather than performing one. The most obvious example of this is HTML*. At a basic level, a web page is just a document, and HTML describes its structure well enough. In other words, all it does is state "Here is a heading. Here is a paragraph..." However, when a web page needs to be manipulated or have of some kind of logical flow, something else must be used. I don't know if this is an intended behavior, but it ends up working very well.

[* Technically speaking, HTML came first, and then XML was created as a superset of it.]

Most "classical" programming languages are considered Procedural (or in some circles, Imperative). Rather than describe something, they state the logical flow of execution. These languages have all the control expressions that people are familiar with: ifs, loops, functions, etc.

Each technology performs quite well in its own domain. But the road to pain and suffering begins when things get mixed up, and Procedural concepts are introduced into a Declarative syntax and vice versa.

The biggest example of this woe is an XML based rules engine that I stumbled across not too long ago. Here is how it handles a conditional statement:

<Logic>
  <If>
    <And>
        <Equals leftId="CLIENT_RATING" rightId="PREMIUM_RATING" />
        <Equals leftId="PRODUCT_TYPE" rightId="REGULAR_TYPE" />
    </And>
    <Do>
        <Integer id="DISCOUNT_PERCENT" value="5" />
    </Do>
  </If>
</Logic> 

Just looking at that makes my skin itchy. Just for contrast, here's the same thing in JavaScript:

if (ClientRating == PremiumRating && ProductType == RegularType) {
  DiscountPercent = 5;
}

A common argument for using XML is that it is easier for a lay-person to read, meaning that a programmer is not needed for maintenance. This may be true for smallish files (say 20 lines or so), but what happens when a non-programmer opens up a thousand line build script to make a substantial change? Once a file gets to be sufficiently large, the maintainer needs to have significant knowledge of the domain to make reliable changes, no matter how "easy" it is to read.

Though the bigger problem with this is that the XML here doesn't describe anything, it actually runs the process!

Build scripts are particular offenders here, MSBuild and NAnt being the bigger fish in the sea. In general I like both of these technologies; they provide incredibly useful services to programmers, but editing and maintaining them is arduous. On the surface, a Declarative language would fit in well here. After all, you are just describing a build. But when you get down and dirty, it becomes apparent that these are really procedures being run.

In both pieces of software, there is the concept of "Tasks," These tasks can clean a directory, compile code, publish it, and more. There isn't actually much of a description going on here, the XML is stating exactly what needs to be done. The individual components of a task are really just the lines of a function:

<csc target="exe" output="HelloWorld.exe" debug="false">
  <sources>
    <include name="**/*.cs" />
  </sources>
  <references>
    <include name="System.dll" />
  </references>
</csc>

Could map directly to this JavaScript:

function compile(target, output, debug) {
  var compiler = new Compiler(target, output, debug);
  compiler.sources.push('*.cs');
  compiler.references.push('System.dll');
  compiler.compile();
}

I've been using JavaScript in these examples for a reason: it lends itself well to the simple procedural programming that is described here. It's fairly lightweight, has a straightforward syntax (especially when certain conventions are forced on it), and most programmers already are familiar with it, due to the ubiquity of it on the Internet. You could have a whole scaffolding of a build script that looks like this:

// Build variables
var codeDir = 'c:\code';
var outDir = 'c:\output';

// Entry Point
function init() {
  clean();
  getFromScm();
  compile();
  test();
  deploy();  
}

// Error Handling
function onError(msg) {
}

// Tasks
function clean() {
}

function getFromScm() {
}

function compile() {
}

function test() {
}

function deploy() {
}

If JavaScript isn't your thing, there is a fascinating build utility out there called Rake. It is billed as a replacement for the old Unix and C Make utility. It does something similar to my JavaScript example, and has the power of Ruby behind it.

For programmers, and even laymen, this is readable and maybe even intuitive. Additionally, you have hosts of technologies that go with a popular procedural languages. Can you create a full battery of unit tests for your build script? Quickly? Can you easily attach them to a debugger? Perform static analysis? All of those things would be useful in a build script, but are difficult to do with XML.

Well then, what exactly is XML good for? In my experience I have found that XML is the "right" solution when you do not have to do any extra processing to handle it. Yes, most modern libraries have XmlReaders and such, but it is still a dreary task to using them to parse a large document. Perhaps the best example I can give is .NET's XmlSerialization modules. With a few lines of code, you can turn an object into an XML node, and then back again. No mucking about with Readers, XPath, or anything. And generally, the resulting XML is lightweight enough that it isn't a huge chore to modify it if needed.

The rule of thumb here is that XML is good when you do not need to put forth a huge effort to use it. Remember, things like this are supposed to be increasing our productivity, not lowering it.

I hope that I didn't come down too hard on XML here. Again, I think it is an incredibly useful tool, and there have been plenty good technologies based on it, I just think that you need to be careful not to use it (or any other "hot" commodity) in the domains that it is simply not suited for.

If you are like me you tend to enjoy keeping up with new technololgies.  I find one of the easiest ways to do this is to subscribe to some podcasts/blogs.  Here is a posting of what I subscribe to, hopefully you find something here that you haven't heard of or seen, and maybe you can leave a comment with some of the blogs you enjoy to read.

 Podcasts:

• Polymorphic Podcast 
• Hanselminutes 
• Diggnation (not really a tech podcast, but highly entertaining to watch)

 Blogs:

• CodeBetter
• The Old New Thing
• Hanselman
• ScottGu
• CodeSqueeze
• Haacked
• Martin Fowler's Bliki

If you haven't read this article on InfoWorld I strongly suggest it -   The 30 skills every IT person should have .

I think my favorite is no 23 -"There is no such thing as a dumb question, so ask it ... once. Then write down the answer so that you don't have to ask it again. If you ask the same person the same question more than twice, you're an idiot (in their eyes)." 

I also like to add to this list:

31.  Learn some SQL - Even if it's the most basic of basic stuff - select *, there's no excuse for not being able to query a simple database.

32.  Don't forget your users are stupid - Seems harsh but what seems obvious to a developer will usually not be obvious to the user.  If your software makes them feel stupid then they won't want to use.  Trust me, I know.  

33.  The coolest technology might not be the best technology - Some developers are like cats - dangle a shiny object in front of them - they'll pounce on it like it's the best thing.  Just because you see everything as a nail doesn't mean the latest and greatest of something is the best hammer to use.

34.  Wear sunscreen -  We live in Phoenix, it's important to take care of your skin.