Colin Ramsay

PTOM: Breaking Free from HttpContext

2009-05-05T03:08:00Z

The System.Web.HttpContext class is a real heavyweight of the .NET Framework. It holds a wealth of information on the current server context, from the details of the current user request to a host of details about the server. It's accessible from the HttpContext.Current static property, which means you can get hold of this information at and point in your code. Whether this is a strength or a weakness depends on your point of view, but consider the following code:

public class AuthenticationService
{
    public IRepository Repository { get; set; }

    public void Login(string username, string password)
    {
        User user = Repository.FindByLogin(username, password);

        HttpContext.Current.Session["currentuserid"] = user.Id;
    }
}

This type of code is probably pretty widespread; separate authentication code into a separate class. The problem with this type of code comes when you want to test it. Consider this test snippet:

[TestMethod]
public void Should_Retrieve_User_From_Repo()
{
    _authService.Login(username, password);
    _repo.AssertWasCalled(x => x.FindByLogin(username, password);
}

This will fail hard, because when your test runs, you don't have a current HttpContext available to work with. In theory, you could fire up a webserver class and populate HttpContext.Current and everything would work just fine; with early versions of the Castle Monorail project, the Controller test support did something similar. However, this is pretty unwieldy and not to mention slow. Of course we do have some horrible situations in which teams don't run these kind of tests, so they're probably thinking that they don't care. They always run their code with a valid HttpContext available and are perfectly happy. Wait till you try and reuse your code to integrate with a third party which calls your authentication service. Ouch. So the bottom line is that we need to make sure HttpContext.Current is kept as far away from our code as possible. Another example of HttpContext usage is something like this:

public void Log(string message)
{
    WriteFile(message, DateTime.Now, HttpContext.Current.Url);
}

So we're writing a log message along with the time and the page where the message was logged. We need this information for debugging, so it's understandable why this code arises, but again we can see testing issues with HttpContext. Fortunately in this case it's easy to fix:

public void Log(string message, string url)
{
    WriteFile(message, DateTime.Now, url);
}

Of course this kind of solution applies to any static class you need to pull out, so let's look at an example which is more closely related to HttpContext: cookies. A standard approach would see us doing something like this:

private void PersistUser(string encryptedUserIdentifier)
{
    HttpCookie cookie = new HttpCookie("user");
    cookie.Value = encryptedUserIdentifier;
    cookie.Expiry = DateTime.Now.AddDays(14);
    Response.Cookies.Add(cookie);
}

This does the job, and adds a cookie to the response so that the browser will acknowledge it. The problem again lies in testing this code; without an HttpContext, we're in trouble. Because a lot of new C# code is working with ASP.NET MVC and test-first practices, we need to take that in to account in every part of our application. How about this instead:

private readonly ICookieContainer _cookies;

public Controller(ICookieContainer cookieContainer)
{
    _cookies = cookieContainer;
}

private void PersistUser(string encryptedUserIdentifier)
{
    _cookies.Set("user", encryptedUserIdentifier, DateTime.Now.AddDays(14));
}

Now, we don't include any kind of code which references the cookie implementation directly, and that in turn means we don't use HttpContext.Current. We provide an implementation of an ICookieContainer via the constructor. That interface and implementation could look like this:

public interface ICookieContainer
{
    void Set(string name, string value, DateTime expires);
    string Get(string name);
}

public class HttpCookieContainer : ICookieContainer
{
    public void Set(string name, string value, DateTime expires)
    {
        HttpCookie cookie = new HttpCookie("user");
        cookie.Value = encryptedUserIdentifier;
        cookie.Expiry = DateTime.Now.AddDays(14);
        Response.Cookies.Add(cookie);
    }
}

Now, looking at this you might be wondering what on earth the point is - this is exactly the same code but in a different class! The important thing is that the first set of code is likely to be part of a bigger controller class, a class which you want to keep as thin as possible. So we pull the cookie handling code out and then the controller doesn't have to be concerned about it at all. Similar approaches can be used where ever HttpContext touches your code. The important thing is that because HttpContext is such a heavyweight, we can break it apart and use only the parts that are needed by wrapping them up into custom classes which can be injected where they're needed.

Castle MicroKernel Fluent Event Wiring

2009-01-25T06:32:00Z

The Castle MicroKernel Registration API is also used in Windsor, and both have a facility to allow a components to subscribe to events exposed by each other. Right now, the only way to use the fluent API to configure the facility is to go right down and build the configuration nodes (taken from http://blogger.forgottenskies.com/?p=266):

container.Register(Component.For<PublisherClass>() .Configuration(Child.ForName("subscribers") .Eq( Child.ForName("subscriber").Eq( Attrib.ForName("id").Eq("Subscriber"), Attrib.ForName("event").Eq("Published"), Attrib.ForName("handler").Eq("OnPublish") ), Child.ForName("subscriber").Eq( Attrib.ForName("id").Eq("Subscriber"), Attrib.ForName("event").Eq("Published"), Attrib.ForName("handler").Eq("OnPublish") ), ) ) );

This works fine, but it's a little verbose for my liking. I've managed to get it down to:

container.Register(Component.For<PublisherClass>() .Subscribers( Subscriber.ForComponent("Subscriber", "Published", "OnPublish"), Subscriber.ForComponent("Subscriber", "Published", "OnPublish") ) );

Much nicer! In effect all I've done is abstract away the building of the configuration nodes. Firstly I have a Subscriber class:

public class Subscriber { public class SubscriberInfo { public string Id { get; set; } public string EventName { get; set; } public string HandlerMethodName { get; set; } } public static SubscriberInfo ForComponent(string id, string eventName, string handlerMethodName) { return new SubscriberInfo{Id = id, EventName = eventName, HandlerMethodName = handlerMethodName}; } }

Then the actual business end of things is the Extension method which allows me to use this:

public static class EventWiringFacilityRegistrationExtensions { public static ComponentRegistration<S> Subscribers<S>(this ComponentRegistration<S> componentRegistration, params Subscriber.SubscriberInfo[] subscribers) { var subscriberNodes = from s in subscribers select Child.ForName("subscriber") .Eq( Attrib.ForName("id").Eq(s.Id), Attrib.ForName("event").Eq(s.EventName), Attrib.ForName("handler").Eq(s.HandlerMethodName) ); var subs = Child.ForName("subscribers").Eq(subscriberNodes.ToArray()); return componentRegistration.AddDescriptor(new ConfigurationDescriptor<S>(subs)); } }

As you can see, I'm just pulling out the data from the SubscriberInfo array and building up the configuration nodes. These are then passed to a ConfigurationDescriptor which is where the real business happens. Writing a custom descriptor would probably make for a more elegant solution, so if anyone's got any suggestions then I'm all ears. When I work out how to write a test for this behaviour I'll try and sort out a Castle patch.

The State of Windows Mobile

2009-01-14T12:57:00Z

“Have you done any Windows Mobile development?”
“A tiny bit. Isn’t it just like Winforms but on a phone?”

And from such an innocent beginning, a world of pain did explode into my universe. Just like Winforms on a phone is it? What’s the difference between the Compact Framework, Smartphone development, Pocket PC development, Windows Mobile? So many terms! So little time!

Windows Mobile is the operating system, just like Windows Vista. The Compact Framework is just like the .NET Framework on the desktop. As for the difference between a Smartphone and a Pocket PC, well, you’ve got me there. I picked Smartphone because my device had phone functionality and it seems to be working so far. There are separate SDKs for each, so I assume there are some key differences which escape me. With Windows Mobile 6, the Smartphone and Pocket PC SDKs are now Windows Mobile 6 Standard and Windows Mobile 6 Professional, respectively. I think.

Actually I think the real difference in these is the templates for projects you create and the emulators you are provided with. Professional, or Pocket PC, provides emulators for bigger screens. Microsoft has this to say about the naming kerfuffle:

With Windows Mobile 6, we are revising our SKU taxonomy and naming to better align our brand and products with the realities of today’s mobile device marketplace. The historical form-factor based distinction between Windows Mobile powered Smartphone and Windows Mobile powered Pocket PC Phone Edition is blurring dramatically. We want our taxonomies and terminology to evolve to better reflect the evolution of the mobile device industry.

So in order to reflect the blurring of the mobile device form factors, they’ve changed from having SDKs named after the types of device to SDKs named “Standard” and “Professional”. Hmm. How about having a single SDK called “Mobile Device SDK” and allow me to pick the device dimensions from within my project on the fly? Back at the start of this tale, I assumed that picking Windows Mobile for development would allow us to target a range of different devices, large and small, and in fact I can do that. I can deploy my application to a Windows Mobile phone with a big screen and to one with a small screen. The SDK split seems pretty artificial with that in mind.

Naming conventions and confusions aside, it is nice to be able to write against a single API and deploy to any Windows Mobile device. Or it would be if it worked.

My bugbear here is with a particular class: CameraCaptureDialog. Take the Samsung Omnia for example. You can certainly pop up the camera using CCD.ShowDialog(), but can you retrieve the filename of the image you took? You cannot. That’s because the Omnia’s camera supports taking multiple images one after the other until you explicitly close it.

How about the HTC Diamond? Well that opens fine, and returns a filename too, but if you try and re-open the camera straight after processing the filename, to allow the user to take another photo, it fails silently and doesn’t show the camera. If you try and do the same thing with the HTC Touch, it freezes.

Part of the issue is that the Compact Framework leaves too much up to the manufacturers and doesn’t give enough control to the developer. We can set the resolution of the camera for example, but we have no shortcut of setting it to the maximum resolution available. If you try and set it to a resolution which is not supported, some devices reset silently to a much lower resolution.

Microsoft need to extend camera support for .NET developers and give a lower level of access. They need to push device manufacturers to adhere to the Windows Mobile APIs and be more precise in how they are specified. And they need to simplify and modernise their mobile development framework so that developers can be fully aware of all the options available to them.

This post was also published on my personal blog.

Parsing XML-like Files

2008-12-07T10:23:00Z

The quantity of data now stored in XML, HTML, and other similar formats must now be absolutely huge. Fetching that data from XML-like files is largely seen as a solved problem on many platforms, but I'm going to look at the various alternatives and see where each would be appropriate and how you can improve the development process by using each method.

The Manual Method

This is the one which makes me go *yuck* in a bit way. You can read in a file as a straightforward string or array of line strings, and skip to the part of the document you want. This is most definitely the manual method when it comes to parsing XML, because you're not really taking an interest in whether the document's XML or not. You're not takin advantage of the structure and you're treeating the file in the same way you would any flat file.

I saw this approach in a PHP application, and it was being used to parse HTML. In this environment I can kind of understand why you'd think about the manual method: PHP doesn't have a built in means of parsing XML into HTML, so there's no way of getting a structured document to even use PHP's DOM support with. However, there are third-party libraries which support methods which are a bit less laborious.

Taming HTML

Many platforms have libraries which parse HTML into a well-formed state to allow further processing. In fact, using HTML Tidy, you can do this manually from pretty much any platform. Some libraries will wrap HTML Tidy and some will provide their own method, but the bottom line is that you're likely to be able to leverage some tool to tame the horrific mess of HTML that is the world wide web.

XPATH

With your HTML under control, or your XML at the ready, you've now got a chance to pull data from your document with some more advanced techniques. Most developers will have touched on XPATH at some time or another, as it's commonplace within the ecosystems of most development platforms. The name gives it away - XPATH is XML Path Language, and allows the use of specialized queries to pull out parts of an XML document:

//li

This XPATH expression specifies that we wish to find all <li> elements at any level of the document. More complex expressions are available, providing means of selecting elements based on attributes, values of nodes, and much more. The strength of XPATH is its availability. In the .NET world, for example, fast XML processing and XPATH are available as first-class members of the framework, only a using directive away. This makes the use of XPATH common-place.

CSS Selectors

This alternative approach is less common due to the lack of first-class support in most frameworks. However, choice is good, so let's look at the way in which CSS can pull out data from your XML documents. I suspect there are still developers out there with an aversion to CSS, so let's be clear: this approach discusses CSS selectors, not layout with CSS. That means all of the strange behavious with comes with floating elements is not applicable here. We're also not running CSS in the browser, so there are no incompatibility issues. This is a subset of CSS, working as advertised.

Hpricot for Ruby, phpQuery for PHP and my own Fizzler for .NET are examples of this kind of solution. Here's a simple sample using Fizzler:

var engine = new Fizzler.Parser.SelectorEngine(html);
engine.Parse(".content");

We start up Fizzler by passing in some HTML string, and then select any nodes with a class name of "content". Fizzler uses HTML Agility Pack underneath, so the result comes back as a collection of nodes which you can further manipulate.

Conclusion

My rationale for developing Fizzler was a personal dislike of XPATH. Because I was strongly familiar with CSS, and because Fizzler supports some advanced CSS 3 selectors, it's possible for me to achieve the same results using CSS selectors without the barrier for entry presented by XPATH. Your mileage may vary, depending on your experience with each technology, but Fizzler fills a gap in the .NET market and I hope some people will find it useful.

Open Source Documentation

2008-11-23T15:49:00Z

Recently I've set up a network attached storage computer on my home network. As well as providing RAID storage for all the devices in the house, it acts as a central download server for everyone to use. Key to this strategy is SABnzbd, a Python application which downloads binaries from newsgroups, and which sits on the server as a daemon, grabbing files on a schedule or when we ask it to. The functionality of this software is incredible, but more than that, there is a great deal of documentation for each feature directly linked from the web interface. This enabled me to set up advanced features such as RSS feeds, categorisation, and post-download scripts, in order to shift SABnzbd from being handy to indispensible.

This post is not about SABnzbd though - it's about documentation. My latest project has been a very quick CMS solution using Monorail, and I've been taking advantage of the new features available in Castle's trunk. The new routing in Monorail, the fluent API for component registration in Microkernel, and more new features, have all been making my life easier... once I've figured them out. I'm in awe of the people who have produced these features and I'm not adverse to digging round test cases where I can, in order to find out how to use them.

However, it would unarguably be better if the Castle documentation reflected these new changes. It's understandable that the documention lags behind these features, and since I don't have the intimate Castle knowledge needed to contribute to fixing bugs or adding new code, I figured it'd be good to try and work on this documentation. Castle uses an XML based documentation format which is just fine for final docs, but not that great for scrabbling down notes and filling out information. For that, I've decided to use the using.castleproject.org wiki, a site designed to hold tips and tricks for the Castle Project.

I've set up a simple system of tagging which allows people to search out stuff in need of documentation and then tag it when it's complete. At that point, I plan on converting it into a patch for the official Castle documentation. In this way we can get the rapid prototyping of a wiki combined with an easy route to formal documentation. I think barrier for entry is a definite problem for contributing on many projects, and documentation can be a good place to start. For Castle, I'm trying to make even the barrier for entry for even that documentation very low. So if you can help out with the routing documentation or the validation documentation or anything else that's missing or incomplete in the main Castle docs, please pitch in and try and help!

(Also published on my personal blog)

Common Interfaces for Tool Families

2008-11-13T10:05:00Z

There are a load of different tool "families" in use in the .NET ecosystem which I'm sure LosTechies readers will take advantage of pretty much every day. IoC containers. Logging infrastructures. URL routing mechanisms. Each of these families operate on broadly similar principals - taking the container example, we know that we need to add types to the container and resolve types which are already in there. For logging, we'd generally have the ability to log to different levels of severity. So you can see that while the implementations and underlying behaviour may be significantly different, there is a layer of abstraction which highlights commonality.

Castle Project has a Castle.Core.Logging.ILogger class which supports the use of a variety of different logging systems within your applications. It is a facade behind which log4net or NLog does the magic while your application happily logs information while not worrying about what is actually taking care of the logging. To me, this is a very interesting method of supporting a tool family - expose the most common methods which a tool supports and let the tool get on with its own business.

What I'd like to see is a community effort to publish an ILogger interface to which various logging libraries can adhere, and an IContainer interface for IoC libraries, and other interfaces for various tool families which have enough common features. In this way, we can enable a new level of code sharing and integration between projects.

(Also published on my personal blog)

Application Configuration

2008-11-12T21:13:00Z

I had cause to recently revisit an old ASP.NET application I'd written way back when I was a development newcomer. Digging around the web.config I found the appSettings section:

<appSettings>
    <add key="systemEmailAddress" value="me@me.com" />
    <add key="adminEmailAddress" value="me@me.com" />
    <add key="templateDirectory" value="~/admin/templates/" />
    <add key="installPath" value="~/admin/" />
</appSettings>

You get the idea. There were loads of these, configuring many different aspects of the system. Many should have been configurable by site administrators from some kind of user interface. Technically this is possible - editing the web.config on the fly - but I really wouldn't recommend it.

Anyway, since then I've used this method a number of times, as well as having a Settings database table which stores key/value pairs:

var email = SettingRepository.FindByKey("email");

Or having a Settings table with a single row and columns for each setting to allow it to be mapped to an object:

Settings settings = SettingsRepository.FindFirst();

All three have upsides and downsides but none are particularly satisfying. I'm mulling over which approach to take in my next project which is going to need a fair few of these settings. Which method do you favour? Do you have a fourth way?

Your Development Environment

2008-06-13T10:00:00Z

When I first started working in "the real world", I had a development environment which I'd describe as typical: average Dell computer and peripherals, one monitor, Windows XP with all my applications installed, including VS2003 and VS2005. I'm sure

Last year, when I struck out on my own to start Plastiscenic, I knew I needed an upgrade. For starters, my XP install was grinding to a halt. But I was also concerned about the way all of my interests were intermingling - games, hobby stuff and professional stuff all on the same installation. That felt pretty bad to me, not least because Windows XP gets very sluggish after a few months with lots of programs installed.

I purchased an Intel Q6600 with 4Gb of RAM, and a 10k RPM boot drive. That was stage one. I set up two monitors on a bigger desk with a lamp on it to reduce any strain on my eyes. I installed Vista 64 Business Edition, which I felt was a better match for the hardware than XP. The core setup was there, but there was still a key component missing.

VMWare provided the answer. By creating a stripped down Windows XP installation I had a fast virtual machine to install development software on. I had another VM for SQL Server. These trim virtual machines could be backed up with ease, and moved offsite if need be. If my main machine died, I only had to reinstall a basic environment and VMWare Player to become productive again.

In a larger team of developers, such virtualisation software provides even more options. An administrator could provide base images which can be served across a network, giving developers tailored environments within a few clicks. This is good for testing too - prepare images for a multitude of operating systems for pre-production testing of a desktop application.

I believe virtualisation will become even more popular over the next few years, giving us more opportunities to create sandboxed environments which can be run at the click of the mouse.

Design Dithering

2008-06-02T18:40:00Z

When you break out of the "new programmer" mindset and begin thinking in terms of organisation, patterns, and good design, I think there's a real danger of hitting a development wall. What actually is the correct way of implementing a shopping cart? Should you use a three or four tier application design? My outlook on this is pretty simple:

It doesn't matter.

The Domain Driven Design book teaches a lot of interesting stuff, some of which can contribute to a brain freeze. So many new concepts can mean that there are a lot of possible avenues of approach for any given problem. But in my eyes, one of the most valuable lessons that Eric Evans gives in that book is that refactoring is key. If I find myself struggling to adapt the right approach, I take the simplest route, safe in the knowledge that if I've done it wrong, my application will let me know, big time. If I'm following a loosely coupled design, no single refactoring should have a huge impact on the rest of the application.

So if you find that you're struggling for a solution, take the simplest, quickest - even do a dirty hack! - and know that next week, if that decision comes back to bite you, you can just refactor it out.

Javascript Patterns & Practices

2008-01-17T22:17:00Z

My previous post on Javascript gave an insight into using the language in a more structured manner than you may have been used to in the past. I'm going to talk about a few more methods which I use a lot, and that help me keep my JS workable.

Pattern

Last time, I talked about the Object Literal pattern. If it helps, you can think about this as if it were a C# static class; you don't need to instantiate it, it can have state, but it is application-wide. I will typically use Object Literal as a kind of "manager", which controls what happens on a page, from a function which fires onload, to functions which get triggered on button clicks.

In other places, such as complex user interfaces, I will typically need "components", which wrap up a lot of functionality and may be used multiple times within a page. An example of this might be a date picker control. For these components, I need to hold state, and so I need the equivalent of a standard C# class.

function DatePicker(date) {

	if(date) {
		this.initial = date;
	} else {
		this.initial = new Date();
	}

	this.show = function(date) {
		alert(this.initial);
	}
}

var startDatePicker = new DatePicker();
var endDatePicker = new DatePicker(new Date('Jan 1, 2009'));

startDatePicker.show();
endDatePicker.show();

In this example, startDatePicker gets instantiated with a default date, but endDatePicker gets a different date passed in its "constructor". You can see that both objects retain their own state when the show() functions get called and different dates are alerted.

Practise

You can do faux-namespaces in Javascript as well as faux-classes. I use them to package up related code and partition it, much as you might do with namespacing in other languages. There are a number of different ways of providing this functionality, and here's one which is incredibly simple:

var NAMESPACE = {};
NAMESPACE.utils = {};
NAMESPACE.interface = {}; // other namespaces

NAMESPACE.utils.fixIE = function() {
// code
}

NAMESPACE.utils.fixIE();

Other ways of organising your javascript code can be pulled directly from C# best-practises, such as one-class- per-file. Another beneficial approach is to avoid embedding your javascript code in your HTML. Code like this:

<a href="/javascriptrequired.aspx" id="showPicker" onclick="showDatePicker();">Pick Date</a>

Can often be easier to maintain when written "unobtrusively", with the following in a linked JS file:

var document.getElementById('showPicker').onclick = showDatePicker;

And now this in your HTML:

<a href="/javascriptrequired.aspx" id="showPicker" &gtPick Date</a>

This keeps your javascript confined to .js files and out of the HTML, which is generally a cleaner approach.

Further Reading

You can continue to develop well by unit testing your javascript and documenting it fully. You can also check it for errors and then compress it for deployment. Javascript is an important tool in your arsenal; use it well!

You Have Nothing To Fear From Javascript

2007-12-08T10:46:00Z

Building a web application consists of a number of discrete layers: server code, client code, HTML, and styling. If you cannot sit down with one of those layers and work on it, you are not fulfilling your role. If I hire a web developer, I don't expect them to tell me that they know little of Javascript, but unfortunately there seems to be a fear of that language, where people are happy to hide it away behind a facade of server-side code which autogenerates it.

This is wrong. If you are working with Javascript, client side code, then you should be able to fully debug, understand, and tweak that code natively. Changing some C# code which you think will generate the right JS is such a horrific approach I can't believe anyone would advocate it. In order to have a robust application you need full control of all aspect, from top to bottom.

Besides, Javascript is actually a great language, though much maligned over the years. As the web matured, Javascript was often responsible for scrolling banners, page errors, and other affronts to the user. But as people have documented its browser support and language tricks, Javascript has matured with its environment. Check out this structure in BLOCKED SCRIPT

// Setup "static" structure
var Application = function() {

	var _privateVar = 0; 


	return {

		someFunction : function() {
			_privateVar = 5;

		}

	}
    } 
}();

// Run the function
Application.someFunction();

Organised, readable Javascript! Whatever next! You can even have psuedo-namespaces, classes, anonymous functions, loads of great dynamic language features which allow you to come up with flexible and concise code. Generating your JS isn't just unwise, it means you're missing out on all the fun!

Working with Interfaces Part Three - Windsor

2007-11-21T18:00:00Z

Castle Windsor is an Inversion of Control container which uses interfaces as a key concept. When working in the manner I described in my previous articles on interfaces, you get a decoupled application but may end up with a lot of "wiring-up" - instantiating interface implementations then passing them into your classes.

For example, a Controller may often demand an implementation of ILogger, IAuthenticationService, IRepository and IPaymentGateway, which would require a fair bit of code to wire up. Windsor removes the wire up burden from the developer. Using XML configuration, you can easily swap out one implementation for another:

public interface ISport{}
public class Football : ISport{}

<component id="default.sport"
	service="ISport, WindsorTest"
	type="Football, WindsorTest"/>

In this example, we use the component element to wire up the Football implementation for any usage of ISport. For Windsor to provide this ISport implementation to your consuming classes, the consumer needs to be in the container too:

public class Consumer
{
	// Parameter injection
	public ISport Sport{ get; set; }
	// Constructor injection
	public Consumer(ISport sport){} 
}

<component id="some.consumer" type="Consumer, WindsorTest"/>

So now Consumer will have the configured ISport passed to its constructor or the Sport parameter, depending on your preference. We could also have an ISport parameter on Consumer and Windsor would be able to set it with the configured implementation of ISport.

Using a system like Windsor is a logical extension of the practises I've talked about before. It gives you the flexibility of interfaces without the burden of having to manually instantiate and pass through all of the implementations your classes may depend upon. When thinking about Domain Driven Design, you can use Windsor to provide Services to your application, allowing it to consume independent components and create one awesome whole. Full Windsor documentation can be found on the Castle website, and I've also written about Windsor on my personal blog.

Working with Interfaces Part Two - Decoupling

2007-10-09T20:47:00Z

In the first part of this mini-series I talked about the basic use of interfaces, which is to provide a contract for your developers to work to. In this part, I'm going to try and demonstrate how interfaces can be used to make your application more flexible. This is probably the most common type of tutorial on interfaces you'll see around the web, so forgive me for adding another.

Here's an example of traditional style development, without interfaces:

public class YoGenerator
{
	public string Generate()
	{
		return "yo!";
	}
}

public class Greeter
{
	public void SaySomething()
	{
		YoGenerator yoGenerator = new YoGenerator();
		
		Console.WriteLine(yoGenerator.Generate());
	}
}

public class Program
{
	public static void Main()
	{
		new Greeter().SaySomething();
	}
}

So we've got a program that creates a new Greeter class and calls the SaySomething method on it. The Greeter class in turn calls a YoGenerator's Generate method to output "yo!" to the console. This should all be fairly straightforward so far and if not, well, you've got bigger worries than what an interface is for.

So, the first step on making this a more useful application (I say that in the loosest terms, I'm not sure how much mileage you can get out of an app that says "yo!") is to refactor by extracting an interface from the YoGenerator class and make YoGenerator inherit it:

public interface IGreetingGenerator
{
	string Generate();
}

public class YoGenerator : IGreetingGenerator
{
	public string Generate()
	{
		return "yo!";
	}
}

In terms of what our app now does, nothing has changed. It still outputs "yo!" to the console and it still does it using the same mechanism. However, we can now make an additional change which opens up more options:

public class Greeter
{
	public void SaySomething(IGreetingGenerator greetingGenerator)
	{
		Console.WriteLine(greetingGenerator.Generate());
	}
}

That's a fairly big jump if you're not familiar with interfaces. We're saying that SaySomething now takes one parameter - an instance of a class which implements IGreetingGenerator. That's an important piece of information, because while you can't directly create a new instance of IGreetingGenerator, you can pass implementing classes round in this way. And because IGreetingGenerator defines a method Generate, we're able to call that on the instance we're passing in. The final piece of the puzzle involves supplying SaySomething with an instance of a class that implements IGreetingGenerator. And remember how we changed YoGenerator to implement IGreetingGenerator...?

public class Program
{
	public static void Main()
	{
		new Greeter().SaySomething(new YoGenerator());
	}
}

So we instantiate a new YoGenerator which is also typeof IGreetingGenerator, and pass that to SaySomething. In the process, we've extracted SaySomething's dependancy on YoGenerator... What does that mean for us? Well it means we can pass in new greeting generators to affect the behaviour of SaySomething, without actually having to change SaySomething's code:

public class DrunkenGreetingGenerator : IGreetingGenerator
{
	public string Generate()
	{
		return "i lovzshh u mannn!!?!";
	}
}

public class Program
{
	public static void Main()
	{
		new Greeter().SaySomething(new DrunkenGreetingGenerator());
	}
}

With a bit of forward thinking we can make the Greeter class work independently of other classes - we've decoupled it from YoGenerator and given it freedom to work with any class that implements IGreetingGenerator.

Why ALT.NET?

2007-10-08T10:56:00Z

DISCLAIMER: This post was inspired by, and contains material from, a recent post on my personal blog entitled "Abandon ALT.NET".

For a few months the term "ALT.NET" has been gaining traction on the blogs I read, starting from a post by David Laribee in April. From there it has taken off, with an ALT.NET Conference taking place this week. So it’s perhaps timely that Sam Gentile has written a post entitled "Goodbye CodeBetter and ALT.NET" which talks about the ALT.NET movement and some of the people surrounding it.

I honestly don't get the point of ALT.NET. While I use and appreciate a lot of the technologies and ideas which they're pushing, I don't see the value in wrapping it with a new moniker. This very act is one of segregation, because it pigeonholes people and technologies away from everything else. As Sam says, "ALT.NET is a divisive thing. No matter what they tell you." Maybe this is a P.R. problem and maybe not. But perception is everything; not your perception but how other people perceive you.

One of the numerous sources of that negative perception is the frequent use of the term "Mort" by ALT.NET bloggers. I strongly dislike this term, I mean come on, the damn thing is short for "mortal". That's a pretty clear proclaimation that the people who aren't "Morts" must be something more: not mere mortals, but Gods of their domain. Overseers of the lower developers who haven’t had the resources, or the guidance, to work with the fantastic array of non-Microsoft technologies that exist.

You're not going to address that imbalance by putting all of the people that already subscribe to your notions in one place. I mean, think about it, DDD, BDD, MVC are things which will be known, in some form or another, to the majority of the ALT.NET Conference attendees.

ALT.NETter A: so… heard of that new BDD business?
ALT.NETter B: Yep.
ALT.NETter A: Oh, well there’s this great new idea called DDD!
ALT.NETter B: Yeah, right into that too.
ALT.NETter A: Oh.

And so on. But wouldn’t that conversation have been a whole lot more interesting if the second developer hadn’t heard of those ideas? Wouldn't it make more sense to talk to the people who are really in need of your ideas and your tools and your knowledge?

A lot of people in the ALT.NET camp may not feel that they’re being divisive but really, by propagating this idea you’re creating a line in the sand, with the highly-knowledgable on one side and the masses on the other. You’re not encouraging dissemination of your information, you’re just creating another impenetrable gang of developers that is almost opaque to the guy on the ground.

The solution? Not to rename or rebrand, or even sharpen your mission statement. Instead break away from ALT.NET, walk among those mortals and share more of your knowledge through the normal channels. It's not as glamorous, but it will be a lot healthier in the long run.

Working with Interfaces Part One - Contracts

2007-10-01T21:15:00Z

I hold my hands up - I am a programmer who doesn't have a computer science background. My education only skimmed programming and was totally bereft of any architectural considerations. I almost stumbled into my first programming job, and I such I realise I have a lot of to learn about that which I use to earn a crust.

One of the things that took me a while to appreciate was the power of interfaces. I specifically remember a conversation I had with my boss in which I said, baffled, "so... they don't actually *do* anything then??". And this is kind of true, interfaces don't really "do" anything. Instead, they're an enabler for a couple of really useful techniques.

Imagine you're creating a series of sub forms in a Windows application. They're each supposed to do a similar thing and should always have methods to LoadSettings and SaveSettings. Something like this:

public class NamePrefs : Form
{
	public void LoadSettings(){}
	public void SaveSettings(){}
}

However, a new developer jumps in to your project and is instructed to create a new preferences form. They come up with something like this:

public class HeightPrefs : Form
{
	public void ExportConfigData(){}
}

For starters they've forgotten that the form needs to load up existing data and so hasn't implemented loading functionality. Secondly, they've called their save method something different to the save method in all your other preference forms. Interfaces can provide a possible solution:

public interface IPreferencesForm
{
	void LoadSettings;
	void SaveSettings;
}

This interface is specifying a contract which implementing classes can adhere. Our initial example would look like:

public class NamePrefs : Form, IPreferencesForm
{
	....
}

If our second example also inherited from IPreferencesForm, that implementation would throw compiler errors as neither the LoadSettings or SaveSettings methods specified in the interface contract are present in the HeightPrefs class.

Using interfaces only solves one part of the problem - you've got to make sure that people do actually inherit from them. That's an issue which can be solved by enforcing developer policies, or technically, by ensuring only classes which implement the correct interface will get loaded by your main program. However, when interfaces are used in this manner, they can improve consistancy and lead to improved discoverability in your code.