Joe's Blog

Extend Yourself

jbennett — Wed, 12 Aug 2009 01:53:46 GMT

I tend to have a fairly long list of things I want to investigate in .NET development. Extension methods have been on my list for a long time. I finally got around to looking into them and wish I had done so much sooner. They are a handy little feature available in .NET 3.0 and later.

So what are extension methods? I’m glad you asked. Suppose you want to add some functionality to an existing class but you don’t have the source code. One way is to derive a class and add the new functionality there. That works, but if you are using the base class in lots of places in your application, you have to go to each instance and replace the base class with the derived class. This doesn’t give me a warm, fuzzy feeling and makes me think there must be a better way. This is where extension methods come in. They provide a way to extend the functionality of a class without subclassing.

Let’s see how it works. Suppose you want to be able to log exceptions in your application. It would be nice to be able to write something like

catch (Exception ex) 
{ 
   ex.Log(); 
}

That would be very cool, and as it turns out, is exactly what extension methods do for you.

Declare your extension methods in a common project that will be referenced from any project that needs access to the extension method. Extension methods must be static methods declared in a static class.

using System; 
using System.Diagnostics; 

namespace Common 
{ 
    public static class ExceptionExtensions 
    { 
        public static void Log(this Exception ex) 
        { 
            Debug.WriteLine(ex.Message + 
                Environment.NewLine + 
                ex.StackTrace); 
        } 

        public static void Log(this Exception ex, string msg) 
        { 
            Debug.WriteLine(msg + 
                Environment.NewLine + 
                ex.Message + 
                Environment.NewLine + 
                ex.StackTrace); 
        } 
    } 
}

The strange syntax of the first argument means you want to extend the Exception class (and any class derived from it) with the extension method. The second and later arguments are passed to the extension method when you call it. You are free to put whatever code you want in your extension methods. Log to SQL Server if you want, or use your favorite logger.

Now that you have your extension methods written, you can do this in your application code.

catch (Exception ex) 
{ 
   ex.Log(); 
    // or
   ex.Log("some more info to log"); 
}

You even have IntelliSense available and it tells you the method is an extension method.

Now, throw new InvalidOperationException("Don't do that.");

produces the following output with the two overloaded calls to Log.

A first chance exception of type 'System.InvalidOperationException' occurred in Common.dll
Don't do that.
at Common.ViewHelper.RegisterView(IRegionManager regionManager, String regionName, Type viewType) in C:\Users\jbennett\Documents\Visual Studio 2008\Projects\PrismFontViewer\Common\ViewHelper.cs:line 25

some more info to log
Don't do that.
at Common.ViewHelper.RegisterView(IRegionManager regionManager, String regionName, Type viewType) in C:\Users\jbennett\Documents\Visual Studio 2008\Projects\PrismFontViewer\Common\ViewHelper.cs:line 25

That’s all there is to it. Enjoy and extend!

Windows 7 RTM

jbennett — Mon, 27 Jul 2009 21:27:45 GMT

Windows 7 has been released to manufacturing! The official bits are getting very close. You can still get the RC until August 20, but laying down your cash at the local Best Buy will have to wait until October 22.

Raleigh Code Camp

jbennett — Tue, 21 Jul 2009 00:48:31 GMT

TRINUG will be holding a Code Camp in Raleigh on September 19, 2009. If you are interested in attending, registration will begin near the end of August. If you are interested in presenting, get your session info submitted as soon as possible.

Hangin’ with the Big Dogs

jbennett — Tue, 21 Jul 2009 00:37:37 GMT

I spent this past Saturday at the annual Community Leaders Summit in Summerfield, NC. Thanks for the invitation, Brian. It’s an event for folks involved in the developer community to get together, eat some burgers and dogs, and see what the user groups in the area are doing. There are some cool things happening in Charlotte at the Enterprise Developers Guild. Let me just say “Carolina Mega Code Camp” and “October 10, 2009” in the same sentence. Watch their site for more info. I hope to see everyone again next year.

Prism Demo

jbennett — Thu, 02 Jul 2009 22:17:59 GMT

I’ll be speaking July 22 about building a simple WPF application using Prism (Composite Application Guidance or CAG just doesn’t roll off your tongue like Prism) for the TRINUG Design Patterns group. If you’ve never seen Prism and what it can do for you, you should come see it. It’s very cool stuff.

Code Contracts and Pex

jbennett — Thu, 11 Jun 2009 02:42:53 GMT

I’ll be presenting on Code Contracts and Pex at the June 17th meeting of the TRINUG .NET in Depth SIG. If you haven’t used these two products from Microsoft Research, you have missed a treat! Code Contracts allow you to express pre and post-condition coding assumptions as well as object invariants in .NET source code. Pex is automated white box parameterized unit testing with very high levels of code coverage. Both products are very cool and together they are awesome! Code Contracts has been released as a separate .NET library and will be a part of .NET 4.0 when it’s released. Pex is still pre-release software but has been very stable for me and is definitely worth getting for some eye-popping demos at the next geekathon. Get yourself some Code Contracts and Pex bits and have some fun.

Windows 7 RC1

jbennett — Tue, 05 May 2009 21:03:01 GMT

Windows 7 RC1 has been released to the public. This is the replacement for Vista that so many have been waiting for. This version is available through July 2009 and expires June 1, 2010. You will want to get some new bits though before March 1, 2010, because that is when your PC starts shutting down every two hours as a friendly reminder. So, dig out a PC that isn’t used for production and install the bits. Get them while they are hot.

Richmond Code Camp

jbennett — Tue, 28 Apr 2009 18:00:56 GMT

I went to the Richmond Code Camp 2009.1 event this past weekend. It was a last-minute decision to go and I’m glad I was able to attend. It was an excellent event, well organized, plenty of good speakers, and pizza for lunch. What more could you possibly want? I spent the day immersed in WPF and Silverlight sessions. They make me want to write code! I really enjoyed it and will definitely go back again. Thanks to Andy and the rest of the gang in Richmond.

Good Free Stuff

jbennett — Thu, 16 Apr 2009 12:18:09 GMT

I may have mentioned before that I love free stuff. If someone is giving away a free T-Shirt or coffee cup, I’m in line. I also like to learn about different technologies. Now, if I could just find a way to combine the free and the learning I’d be a happy man.

As it turns out, our friends at Microsoft created Ramp Up for guys just like me. So if you want some free basic technical training, head on over and take a look. You may not get a free coffee cup, but you do get some good things to put in your head.

Sentient DSLs

jbennett — Thu, 02 Apr 2009 03:49:00 GMT

The Channel 9 guys made my day today! Check it out. http://channel9.msdn.com/shows/10-4/10-4-Episode-14-Sentient-DSLs/

Back by Popular Demand

jbennett — Wed, 25 Mar 2009 19:43:04 GMT

Last month I spoke with the TRINUG Design Patterns group about Dependency Injection with the Unity framework. There was a lot of interest and some of the folks wanted more. So, this month I will be speaking there again and demonstrating the interception capabilities of Unity. I'm also going to demo the Validation application block from the Enterprise Library. EntLib and Unity together offer some interesting possibilities.

Intercept Something

jbennett — Tue, 17 Mar 2009 16:18:40 GMT

I've been working with the Unity DI framework lately. The guys at P&P have created a piece of work you really should get to know. Unity encourages developing highly cohesive and loosely coupled modules for use in your application. That's great, but there are some cross-cutting concerns that tend to muddy up our code. For example, logging various kinds of information at runtime is a common task. Sometimes it seems as if we have as much logging code in our applications as we have code that actually does what our application was intended to do. Including that logging code just kicks our cohesiveness out the door. We are no longer focused on just one task. We now are focused on one task and logging. It can make a method hard to understand just because the logging code tends to mask what the method is actually doing. Unity provides a solution to that problem.

The Interception Extension for Unity provides the capability to intercept a method call, do something before the call and after the call. That sounds like it's ideal for logging doesn't it? As it turns out, it actually works very well for handling that kind of cross-cutting concern without muddying up our code. An easy way (but not the only way) to accomplish interception is to create a new LogAttribute and override its CreateHandler method.

Make sure you have references to Microsoft.Practices.ObjectBuilder2, Microsoft.Practices.Unity, and Microsoft.Practices.Unity.Interception in your project and a using Microsoft.Practices.Unity.Interception directive at the top of your source file.

public class LogAttribute : HandlerAttribute

{

public override ICallHandler CreateHandler(Microsoft.Practices.Unity.IUnityContainer container)

{

return new LogCallHandler();

}

Now create the LogCallHandler class like this:

public class LogCallHandler : ICallHandler

{

private int order;

public LogCallHandler() : this(0) {}

public LogCallHandler(int order)

{

Order = order;

}

public int Order

{

get { return order; }

set { order = value; }

}

public IMethodReturn Invoke(IMethodInvocation input, GetNextHandlerDelegate getNext)

{

ILogger logger = container.Resolve<ILogger>(); // get your logger

logger.Write("Precall logging"); // log whatever you want before the call

var result = getNext().Invoke(input, getNext); // this invokes the method you called

logger.Write("Postcall logging"); // log whatever you want after the call

return result;

}

Now, add the Interception Extension to the container and configure it to use the InterfaceInterceptor.

container.AddNewExtension<Interception>();

container.Configure<Interception>().SetInterceptorFor<IMessenger>(new InterfaceInterceptor());

You have the container configured so that any class that implements the IMessenger interface can have its methods intercepted. To wire everything together, use the LogAttribute you created on the methods of IMessenger you want logged. In the concrete class, when you call a method of the IMessenger interface that has the LogAttribute on it, it will be intercepted and the Invoke method above will be called instead. The information you wanted logged before the call is logged, then the call is made to the method you called, then the information you wanted logged after the call is logged.

Enjoy! More information is available on using Interception with Unity.

Object Responsibility

jbennett — Sat, 31 Jan 2009 17:32:16 GMT

One of the most basic concepts of object oriented design is the class. A class is one of those things that we know when we see one, but describing what it is, is a little harder. More importantly, how do we know when we are through creating one in code? What should be included in it and what should not? One definition could be when we quit typing, and that is a definition I have unfortunately seen too often in code. Designing a class correctly is more than looking at a source file and saying "This Widget doesn't have too much stuff in it, I think I'll put the code for the new Zinger in here." An object should be responsible for maintaining its own state and behaving in a way that is reasonable.

I like to think of a class as a model of something real. Suppose I had a class named Apple. What is an Apple and how do I represent it in code? Well, it probably has a name and depending on your point of view it might be "Fuji" or "Mac." Let's take the fruit and think of other things that might help describe it. Size and weight are possibilities, and so is color. We might even need some indication of whether it is ripe or a measure of its sweetness. All those things are the state of an Apple. They represent a particular instance of an Apple with variables that contain values at a particular point in time.

An object is more than just state, it also includes behaviors. Behaviors are represented by methods in our classes. What kind of behaviors can an Apple have? Watch one for a while and see what it does. If you actually did that exercise, your list of behaviors is probably pretty short. This is characteristic of a category of objects called Entities. Entities have very few behaviors. When you describe what software should do, they are some of the nouns in the description. They are typically inanimate, have very few of their own behaviors, and are acted upon by other objects. While that description is not always accurate, if you find something that fits that description you have probably found an entity. Examples of entity objects might be a Book in a library application or a DVD in video store software.

Should an Apple have a Find method that locates a particular Apple in a Basket of Apples? No, it is not the responsibility of an Apple to find other Apples. An Apple should be unaware of other Apples or even the Basket instance that is its container. So how is a particular Apple found in a Basket of Apples? Should the Basket class have a method named FindApple? No, have you ever seen a basket search for anything? I haven't. The way you model an object in code should be as close to the object in the real world as possible. It is the responsibility of a Basket to hold things, not search for them. A Person might be interested in a particular Apple. So, should a Person have a FindApple method? Probably not, but people use tools to help them do things. A type of object called a Collection knows how to manipulate multiple instances of some class. So a person would use an instance of a Collection as a tool to find a particular instance of an Apple in a collection of Apples.

To define an object we need to understand exactly what it looks like and how it behaves. We describe an object in code by the internal variables (and externally visible properties) used to store its state, other variables used to store values required by one or more of its behaviors, and only the behaviors that are required for that object. What else should go into a class? NOTHING!

While this is not meant to be the last word on object responsibility it is meant to be a guideline on how to create well-designed objects. Understanding what an object's responsibilities are helps in knowing when to stop adding things to your classes. Use common sense and good judgement and don't add unnecessary things to your classes, it just clutters up your code and makes maintaining your software harder and more time consuming.

Design Patterns

jbennett — Mon, 12 Jan 2009 15:30:43 GMT

I'll be speaking to the TRINUG Design Patterns group on February 25, 2009 about creating highly cohesive and loosely coupled applications using the Unity Dependency Injection framework. Come check it out.

Loosely Coupled Applications

jbennett — Fri, 09 Jan 2009 17:23:00 GMT

I've been working with the Unity Dependency Injection Application Block lately. It is part of the Enterprise Library beginning with version 4.0. You can also get it as a separate download without EntLib. Pick your flavor at www.CodePlex.com/Unity.

The benefits of using Unity (other than the cool factor) are from the way it encourages developing your software as loosely coupled modules. Anyone who has ever worked with a tangled mess of spaghetti code will understand the advantages of loose coupling.

Although it's great as is, there are a few shortcomings in version 1.2 I'd like to see addressed. I'd like to see MS throw some more complete extensions into the mix. Currently, you get a simple event broker extension. It's very cool and easy to use. Limitations on the type of the event and event handler are a bit of an annoyance, but you can work around that.

Overall, for a version 1.x product the guys at Patterns and Practices have produced some very cool and very useful software in Unity. You should get it now and use it in your projects. Thanks P&P guys! I look forward to future versions of Unity.