.NET Delegates Part 1

One of the things I've struggled with in OOP is how to take concepts I learned in college, post-college learnings in OOP, and use them in a way that creates good code. I really believe that there is no perfect way to do code, because there are nearly an infinite amount of ways of solving the same problem; however, I do believe that there is a difference between good code and bad code. Furthermore, I believe that bad code can be created, regardless of whether or not proper elements of coding have been followed. I think that good code can be described as having the following characteristics:

1. Extensible - The code is capable of being expanded for future growth.
2. Properly Engineered - Code should match the job. Overengineering doesn't help anyone if the project doesn't call for it. Overly verbose code ends up destroying agility, which hinders the programmer's ability to solve a problem quickly.
3. Efficiency - The fastest processing code with the smallest amount of lines of code is the name of the game. It's the programmer's dilemma, and it's one of the reasons I love programming.

There's probably more nuances in good code, but I think that the above 3 characteristics describe good code, and lack of the above characteristics describe bad code.

Delegates are one concept in code that gets at all 3 of the above characteristics. A delegate is not all that easy to explain, but I'll do my best, given my experience with them, and the value I find in them, at a practical level.

A delegate can do many things, but the first thing that all the tutorials talk about with the application of delegates is to "Encapsulate a method." In a nutshell, that means delegates provide another form of abstraction. Below is an example:


delegate void GenericMessage(string message);

class MyClass
{
    ///Notice that this method is type void
    ///just like the delegate. Also has the
    ///same parameter types as the delegate
    private void realMessageWriter(string theMessage)
    {
        Console.WriteLine(message);
    }

    ///The entry method for this class
    public void Entry()
    {
        ///Notice variable _Message is of type
        ///GenericMessage - which is the delegate
        ///Similar functionality could be done
        ///with an abstract class or an interface
        GenericMessage _Message = realMessageWriter;
        _Message("Hey dude");
    }
}

This is a very simple code example, but I think it demonstrates the point, that delegates provide a way to hide a method, as long as the method shares a similar "fingerprint" as the delegate. In the above example, the method that is being hidden (realMessageWriter()) is of type VOID, and accepts a string parameter.

This is the foundation of a delegate. There is a curve ball that delegates present, when you take into account that they are the foundation for events, which could allow you to fire code in the event that something happens without proactively coding for that scenario after each iteration of some action, but I think that falls into Delegates Part 2.