Standards

Extension Methods

Dave Redding — Tue, 18 Dec 2007 15:59:33 GMT

My friend J. Chapman has a great demonstration of how extension methods can help to further de-couple UI elements from BL. Good stuff. I like the approach. This is a good post that i would say to you "Hand out to all the hethens who preach heresy against the church of C#"!!

Tech in 5 minutes: The Abstract Factory Pattern

Dave Redding — Thu, 28 Dec 2006 19:41:00 GMT

In the sprit of the coming New Year, I thought I’d bring you all this little egg of wisdom. By egg I mean code and by wisdom I mean code I could write before I got hammered.

When I go out with the Wife to drink, (Yes she can do more than fill the fridge and get me beer….hell, half the time she doesn’t even get me the beer, I have to get off my ass and do it myself!) We like to drink as much as possible, not only that, but we love to sample every brewery possible. We have a few requirements, for one there has to be a bathroom.... if you whip it out in public, you get thrown in jail, and that kinda puts a stop to your celebrating depending on how you get your kicks. Another one is that they must serve at least one standby beer (Sam Adams for me, Michelob Light for the wife) and one beer we’d like to give a try.

The problem that we find on nights like New Years is that after a few bars (maybe fewer for me than the wife)....we don’t know what the hell their serving, if we walk in and just ask for a Beer, who knows what we’d get!

By now you’re probably saying “Dave, you promised me tech, and patterns and stuff, but so far all I’ve seen is how you like to drink”. To that I say: calm the hell down, I’m getting to it. I’ve got to set the stage here for Christ sakes.

If we could make the world a more program friendly place, I’d say we could implement a Factory Pattern here. Basically where I have a bar, it produces beer, I drink the beer, and all is well. If you remember from my last example we had a beer class that inherited from a Drink class. Something like this:

public abstract class Drink : FridgeCrap

{

    public abstract void Consume();

}

public abstract class Beer : Drink

{

    public override void Consume()

    {

        Console.WriteLine("Glug glug glug.... mmmmmm beer.");

    }

}

Like I said earlier, I ‘m not going to be able to order just a plain “Beer” from the bar, so that class must be marked abstract. Now if I want specific beers, its simple right?

public class SamAdams : Beer

{

    public override void Consume()

    {

        Console.WriteLine("Mmmm, refreshing, filling and a great aftertaste...");

    }

}

public class MichelobUltra : Beer

{

    public override void Consume()

    {

        Console.WriteLine("Really....why not just drink water? You'll probally get buzzed faster :)");

    }

}

Fantastic. So now I have my required beers. Now like I said, each bar is going to have its own beers, so we need a few more classes:

public class BarA_stout : Beer

{

    public override void Consume()

    {

        Console.WriteLine("Goes down smooth, nice frothy head. Goes great with a burger.....i want a burger!");

    }

}

public class BarB_liteAmber : Beer

{

    public override void Consume()

    {

        Console.WriteLine("Great with wings, has a nice amber color and is an easy drink to have over conversation!");

    }

}

public class BarC_Crap : Beer

{

    public override void Consume()

    {

        Console.WriteLine("Holy shit, this must be budwiser...we need to get the hell out of here, they probally spiked my Sam with water!");

    }

}

public class BarD_JagerBomb : Beer

{

    public override void Consume()

    {

        Console.WriteLine("Wow....they lied, this ain't just beer..... One more round please!");

    }

}

Ok, so we have our beers (the names kinda gave away the punchline did’nt they?). Now all we need are a few bars to serve them up to us!

public abstract class Bar

{

    public Beer GetSamAdams()

    {

        return new SamAdams();

    }

    public Beer GetMichUltra()

    {

        return new MichelobUltra();

    }

    public abstract Beer GetHouseBeer();

}

public class BarA :Bar

{

    public override Beer GetHouseBeer()

    {

        return new BarA_stout();

    }

}

public class BarB : Bar

{

    public override Beer GetHouseBeer()

    {

        return new BarB_liteAmber();

    }

}

public class BarC : Bar

{

    public override Beer GetHouseBeer()

    {

        return new BarC_Crap();

    }

}

public class BarD : Bar

{

    public override Beer GetHouseBeer()

    {

        return new BarD_JagerBomb();

    }

}

Now, it’s not just good programming practice to have that abstract bar there, oh no. Remember how I said that I after a bar or two, I’d probably have no idea where I was? The problem here is that, if I want the house beer from BarC, I have to know that BarC is serving it. Great for going out for lunch, bad when you’re drunk and looking for another beer. So enter the Abstract Bar Factory. We’ll just put a static method that helps with making the decision on where to drink, or more importantly, tells us where to drink.

public abstract class Bar

{

    private static int BarCounter = 0;

    private static Bar[] itenerary = new Bar[4]

                                    {

                                        new BarA(),

                                        new BarB(),

                                        new BarC(),

                                        new BarD()

                                    };



    public static Bar GetNextBar()

    {

        if (BarCounter >= itenerary.Length)

            BarCounter = 0;

        return itenerary[BarCounter++];

    }

    public Beer GetSamAdams()

    {

        return new SamAdams();

    }

    public Beer GetMichUltra()

    {

        return new MichelobUltra();

    }

    public abstract Beer GetHouseBeer();

}

Excellent, now, my Wife and I just need to drink the beer.

public class DaveAndWife

{

    private Random beerTolorence = new Random();

    public DaveAndWife()

    {

        int trips = beerTolorence.Next(4, 20); //thats alot of beer!

        for (int i = 0; i < trips; i++)

        {

            WeWantBeer();

        }

    }

    public void WeWantBeer()

    {

        Bar currentBar = (Bar.GetNextBar());

        //For the wife

        currentBar.GetMichUltra().Consume();

        //for me

        currentBar.GetSamAdams().Consume();

        //for us to try

        currentBar.GetHouseBeer().Consume();

      }

}

Note the simplicity here! We don’t care where were drinking. If it’s on the itinerary, were going to drink there! And best of all, I don’t need to keep track of where to go next or where we’ve been. Abstract Factories are great for getting drunk, just remember that and you’ll be OK.

Now, if you have any ideas for any future topics you’d like me to cover in a 5 minute tech. Let me know via comments or email. But if you want to be really suave, come to the Ann Arbor .Net meeting on Jan.10^th where we’ll be having the project manager for Windows Workflow, Matt Winkler , speaking on...... Windows Workflow! And while your there you can meet me and drop me your suggestion. I might even give you something (stop snickering!).

Dave.

Tech in 5 minutes : Singleton Pattern

Dave Redding — Wed, 20 Dec 2006 16:07:00 GMT

This is for all of you out there who say "I use design patterns that I don't know by name". I'm sure everyone does. So, here is one you probably use in some likeness that you may not have known, and a simple example of how it's used.

singleton
noun

a single object (as distinguished from a pair)
a set containing a single member
the playing card that is the only card in a suit held in a bridge hand as initially dealt

Long and short. I only have/want one of it. Kinda like what you say after your first kid turns two. Unlike in real life, we can control ourselves a little better and require that we only have one.

Playing off that example, say I have a "Kid" class, and I only ever want one instance of Kid, the code is simple:

public class Kid

{

    private static Kid m_kidInstance;

    private Kid()

    {

    }

    public static Kid Instance()

    {

        if (m_kidInstance == null)

            m_kidInstance = new Kid();

        return m_kidInstance;

    }

}

Thats it. So if i have a Father and Mother class, they won't get confused and can interact with the same kid without ever having to actually specify his name:

public class Father

{

    private Kid m_kid;

    public Father()

    {

        m_kid = Kid.Instance();

    }

    public void YellAtKid()

    {

        Console.WriteLine("Hey {0}, do the damn dishes!", m_kid);

    }

}

public class Mother

{

    private Kid m_kid;

    public Mother()

    {

        m_kid = Kid.Instance();

    }

    public void CoddleKid()

    {

        Console.WriteLine("It's ok {0}, don't listen to that mean man.", m_kid);

    }

}

As you can see the parents have relatively different opinions on how to raise their child. But whats important is their doing it together (awwwwww). Meaning that when they access Kid.Instance, they are both accessing the same kid, since the class will only ever return 1 kid. Unfortunately, this won't help the kid later in life when he's in group therapy because his parents only were able to make him do the dishes and protect him from the big mean dad.

Interesting

Dave Redding — Wed, 20 Dec 2006 14:18:00 GMT

A free e-book for C#/VB Coding standards, from SubDomain can be found here :http://submain.com/blog/FreeCVBNETCodingGuidelinesEbookDownload.aspx (Referenced from Sreenivas Mogullapalli's blog.)

I'd have to say that, while it's a great read (short too, only about 100 pages), and straight to the point, it doesn't really cover anything that most people don't already know. I would suggest, however, if your trying to enforce some kind of coding standard at your work (I went through a ordeal with a company who believed that coding standards were a waste of time), then it's probally good to give it a read and use it as reference when making your argument.

Dave