Castle Windsor’s Release Functionality

One of the things that was in AutoGen from version 0.001 was the ability to intercept Dispose.  This might seem like a relatively minor concern, but it was actually central to the design.  First the bad news: after a lot of work, the Dispose functionality still had edge-case failures.  The truth is, the lifestyle aspects of Windsor are quite complex, and any Dispose interception implementation needs to understand it completely.  So why did I bother?  And why is Krzysztof bothering now?

We need to return to one of the basic principles of IoC containers: the code being hosted shouldn’t need to know it’s being hosted.  It’s this design philosophy that sets it apart from EJB, ASP.NET and any number of other hosting technologies.  The release method violates this badly.  Even if you hide the container behind an abstract factory it’s not good enough: you’ll need to add lifecycle concerns directly to the factory interface.  Windsor provides an API for releasing resources that goes against the grain of .NET development.  If you create an object in a using statement and it goes out of scope, you’ve got a reasonable expectation that you’re done with that object.

Container independence may not be a concern to many, but it breaks that too.  Every abstraction that sits on top of Castle has to know about this detail or it will end up leaking instances.  It pretty much breaks the Common Service Locator: there’s just no sensible implementation of it that doesn’t involve providing a footnte saying “I hope you remember to call IWindsorContainer.Release at the appropriate times.”*

Does it matter?  Well, like all resource leaks, it depends.  But in certain circumstances, it will. 

What can we do?

Intercepting IDisposable isn’t ideal either; for a start, you’d need to proxy absolutely everything that implements IDisposable to get it to work.  There’s a couple of other alternatives I can think of here:

  • Leave it the way that it is and pretend it’s a user problem.  (You may suspect I don’t favour this option.)
  • Remove the functionality that requires Windsor hold the reference.  (This might be easier said than done.)
  • Start holding onto transients using WeakReferences.  (Ditto)

UPDATE: Krzysztof has pointed out that the WeakReference proposal may be a cure worse than the disease, since it relies on Finalizers to work.

*Some readers may object that, even if releasing individual instances is relatively hard, you can always get rid of the lot by disposing of the container.  This would, of course, assume that your factory implemented IDisposable, which sadly the Common Service Locator doesn’t.  Siege, thankfully, does, so it’s at least possible to do that if you’re using Marcus’ code.

Technorati Tags: Castle Windsor,Container Independence,AutoGen

Feedback and API Design

One of the most frustrating things for a user is to receive a cryptic error message.  This is closely followed by a developer receiving the same error message.  Let’s say you’re using Fluent NHibernate and you get the error message “Sequence contains no elements”.  Chances are, you’ve done something wrong.  The problem is that you’re not going to figure out what unless you actually debug the source code.  This particular error message is generated by the “Single” extension method.  This code by design does the following:

  • Returns the first element in the list
  • OR Generates a cryptic error message

There’s no sensible way to use the function short of putting a try/catch/rethrow around every single invocation.  You couldn’t even recode the function to be more helpful: there’s simply no useful information provided to it.  Basically, there’s no way Single (or First, for that matter) can be used in high-quality code.  SingleOrDefault and FirstOrDefault, on the other hand, have a way of dealing with failures that doesn’t involve cryptic errors messages (you can still throw an exception, and that can still be cryptic, but then it’s your fault, not Microsoft’s). 

How else could we have designed this API?  Well, we could try “First(Func<Exception> onError)”.  This would be fine for First, because there’s only one failure mode: there’s no elements in the list.  However, for Single there are two possible failure conditions: no elements and multiple elements.  Do we add in two onError functions or do we create a Problem input?  And then should we be using Func<Problem, Exception> or going for the general stable case of ProblemVisitor?

The answer is probably that the last case doesn’t come up: if you’ve got that complex a spectrum of failure conditions, you’ve probably provided the code with enough inputs to generate good error conditions.  However, even in fairly general cases, sometimes you need to pass information to a function purely to improve the diagnostics.  On the other hand, functions like First, Single and Parse (TryParse is okay) will never have good diagnostics are pretty much impossible to use in easy to debug code.

Technorati Tags: ,

FtpWebRequest and (550) File unavailable (e.g., file not found, no access)

Let’s just give you the punchline of the post first:

If you’re trying to access the file “ftp://somehost/somedirectory/some.filename” and you’re getting a 550 error, you need to change the Uri to “ftp://somehost/%2f/somedirectory/some.filename”

You can find more details on Mariya Atanasova’s Blog.  OK, now that I’ve performed the public service, let’s explain why this works. 

FtpWebRequest interprets every directory in the chain as a “CWD” command (CD in DOS terminology).  Each of these is relative to the previous location.  The first location is wherever the FTP server dumped you on logon.  A behaviour that is irritating in interactive mode is made just plain unusable as an API.  What’s worse, Microsoft have actually implemented the spec correctly (section 3.2.2 if you really care).  This basically means that FTP urls don’t work the way you expect and don’t behave in a similar way to HTTP urls.

So, to fix this, we need to first change to the root directory.  That, of course, means executing a “CWD /” command.  Of course, since / is a special character in the URL syntax, you end up having to write “%2F” to trick the FtpWebRequest into doing the right thing.  Ultimately, the moral of this story is that FtpWebRequest and ftp URIs are the wrong model for interacting with FTP.  I can’t see that being changed anytime soon, however.

Dependency Reversi

I have to admit, when I read Uncle Bob’s post about dependency injection, I really didn’t expect the response it would get since it struck me as being relatively uncontroversial.  So Davy’s reaction rather surprised me.  Davy had two major objections to the original article:

  • The contention that IoC containers aren’t always appropriate.
  • The advocating of the use of abstract factories.

Now, when I teach constructor injection to developers around my company, I always teach it in the manner Uncle Bob describes: just pass things into the constructor.  Sooner or later someone asks where things come from initially, and I explain that it all gets set up in the main method.  Let’s revisit why we’ve done this: we’ve separated stable code from unstable code since we’ve moved the wiring into the main method.  IoC containers are all about configuration.  If your configuration isn’t complex, I don’t particularly want to confuse a developer by introducing the concept.  I usually let them hit the point at which wiring has become painful and then show them the next step.

Don’t get me wrong, I love IoC containers.  They’re power tools and I wouldn’t do without them on complex projects.  But not everything I write is that complex, and I wouldn’t use an IoC container for Solution Transform any more than I would use an electric drill on an Ikea table; the likelihood of woodchips flying everywhere is just way too high.

Charlie and the Abstract Factory

A point that I don’t think is made enough is that the SOLID principles aren’t just about what, they’re about where.  Dependency Inversion, however you practice it, moves your externalities into one place: the Main method.  However, Uncle Bob’s second point is about location as well.  Now, I don’t think many people in the .NET world are still using attribute-based registration but the fact remains that it does cause your entire code to take a dependency on your container.  If you and every possible client you can envisage uses that container that’s not the end of the world.  The same argument applies to any invariant dependency.  For anyone else, it’s at best rude and quite likely to lead them back into the kind of configuration hell IoC is meant to avoid.*

As I understand it, the main objections to the abstract factory concept are as follows:

  • They will result in a lot of abstract factories.
  • The factories will be dependent upon the container.

I think the first problem is overstated.  As Davy says himself, the constructor injection behaviour of the container ensures that most resolution is handled seamlessly.  When would you actually need to use container resolution?**

  • In the main method. 
  • Where you need to create multiple objects of the same type.
  • Where you need to dynamically create different implementations for the same interface depending on your current state.

The first isn’t a problem, you’ve already got a hard dependency on your container there.  It’s the other two where you need an Abstract Factory.  Here, you’ve got three choices again:

  • Write a dedicated implementation that doesn’t use a container at all.  This is the classical (GoF) understanding of how to implement the pattern.
  • Use your container’s resolution API
  • Hide your container behind an Adapter pattern.

I’d argue the first approach can be appropriate, but may be a code-smell in code that uses an IoC container.  It indicates you’re not really happy with the resolution behaviour of your container.  On the other hand, nServiceBus takes the last approach with the IBuilder interface and implementations.  Davy’s own Agatha does something similar.  However, these are slightly misleading examples since they’re still phenomenally general.  If you’re throwing an interface that general around your code, you’re either writing a framework or violating the Interface Segregation Principle. 

You are in a Maze of Twisty Principles, All Alike

Imagine if whilst reading the Gang of Four book, you were told that the correct maze factory implementation was this:

public interface IGeneralFactory
{
    TResult Make<TResult>(IDictionary<string, object> parameters);
}

Rather than this:

public interface IMazeFactory {
    IMaze MakeMaze();
    IRoom MakeRoom(int id);
    IWall MakeWall();
    IDoor MakeDoor(IRoom room1, IRoom room2);
}

The latter code communicates intent and limits the interface to the operations the client is going to need.  The former is overly general and its purpose could be anything.  It’s so general it would be pretty impossible to simulate, which quickly leads to the “containers in tests” anti-pattern.  Unless you believe that there’s something magical about inversion of control containers that make standard design concerns go away, you’re going to be favouring the latter interface in your code.  Moreover, by putting the maze factory interface with the library which consumes it and the implementation with the registration code (which is container specific) we’ve remove all of our dependencies in our library code on the framework.

Uncle Bob’s example isn’t really helped by the fact that it doesn’t scale.  Although perfect for mid-sized apps with relatively few requirements for dynamic resolution, in practice you’re more likely to implement the factories as taking a container as a dependency, with a similarly modular system for the registration of components.  (Krzysztof has already remarked that .NET containers seem to have better tooling in this regard, but the principles apply either way.)  However, the classes are still coupled, and should be located in the same assembly.**

Removing Tedium

This last part isn’t really about coding principles, but let’s take this further.  There’s an unspoken third objection to using abstract factories religiously: that the code is dull and repetitive.  It bulks up our registration code with form-filling noise.  Wouldn’t it be better if you could just inject the interface into your container and have it auto-generate the implementation class for you?  This would shorten your registration code, keep the complete lack of hard dependencies on your containers and generally make your code shorter and more flexible.  Well, that’s the point I reached a year ago with AutoGen.  Castle Windsor had a crippled implementation at that time, but it’s usable these days.

Seriously, would you rather:

  • Take a hard dependency on your IoC container throughout your code.
  • Write “Component.For<IMazeFactory>().AsFactory()”?

Not all containers expose this functionality (I’d argue that most should) but that’s not a problem.  You’ve still got the technique Uncle Bob describes to fall back upon.  If more did, we’d be a lot further along the road to container independence than we are now.

*I could expand on this point further, but I’m not convinced anyone is likely to contend with what I’m saying here.

**I’ve used the terms “resolve” and “assembly” throughout here, because I’m a .NET developer.  However, the argument doesn’t noticeably change if you say “getInstance” and “Package”.

UPDATE: I’ve tightened up the style at points to improve readability. Semantically it’s unchanged.

UPDATE 2: Jeffrey Palermo made a comment to the original post which said “[We are] lying to ourselves […] that it is not a global and that it in itself is not a dependency”. He then followed it up with a post which ended up proposing a poor man’s IoC as a global variable. As I’ve said before, I don’t agree with approaches like this.

UPDATE 3: Oren posted a counter-example to the idea about manual constructor injection. He seemed to be arguing that just because you couldn’t write expedia.com that way you shouldn’t try to do so for smaller programs. In particular, two things about his example aren’t shown on the diagram: the need for lifecycle management and the presence of more than one controller. A straight console program that required that set up would probably be better written just using manual injection.

UPDATE 4: Davy posted a response to this article that makes it clear that we’re actually pretty much in agreement as to best practice (although he doesn’t have the tooling that’s the final step in the article). I now think that his principal objection to Uncle Bob’s factory code is that it puts registration and resolution into the same class, which I agree doesn’t scale. There’s another case of “container as global variable” in his code, but I think I’ll work that into a separate blog post.

(Incidentally, one major objection to putting registration and resolution into the same object is that it violates SRP. However, that argument would also apply to the container itself.)

UPDATE 5: Uncle Bob followed this up with a similarly back-to-basics post about mocking frameworks. Again, his emphasis is on how the principles are independent of the tools, and that the tools are sometime overkill. However, I think I’m going to sit this one out. 🙂

Christmas Trees and Process Flow

Most people reading this blog probably had to take a Christmas tree down in the last month.  Now, my Christmas tree is a pretty cheap plastic one I picked up at the local supermarket and requires some assembly.  This got me thinking about the lean concept of process flow.  Let’s analyze what’s involved in getting the tree put away for next year:

  • I have to take the branches off the tree
  • I have to “un-spread”, or flatten, the branches.  This involves me gathering all of the sub-branches together and twisting until they stay together.
  • Finally, I had to put the branches in the box.

Now, in manufacturing one of the principal sources of waste can be transport and storage costs.  Obviously, storage isn’t really going to cost me anything: I can just drop pieces on the floor.  On the other hand, transport can be an issue: it’s easy to drop pieces on the floor, but picking them up involves bending down and I’d rather minimize that.

Now, Lean Thinking will tell you always to concentrate on making processes flow.  Here’s how that would look:

  • Take a branch off the tree
  • Flatten it
  • Put it in the box

There’s two difficulties in practice with that approach, and both are related to the final step.  First, certain pieces need to go in first or it’s unlikely you’ll get them all to fit.  Those pieces are large and at the centre of the tree.  In other words, they’re the last pieces you get hold of taking branches off the tree.  Another is that, actually, it’s much easier to put in five small pieces at a time than five in a go.  (There’s another alternative here I’m not going to examine: take the box apart, put all the pieces in it and then use gaffer tape to stick it back together.)

So, now I’m flattening everything before putting it into the box.  So, is process flow not working for me?  Not quite.

The Whole Value Chain

The first step of lean thinking is to analyze the whole value chain.  Now, value for me is defined as getting all of the Christmas stuff put away.  So far, I’ve only been considering the tree.  Let’s just add in the lights on the tree to the value chain.

Now, I’m very fond of my Christmas lights, but they’re a series of large (5cm) baubles connected by wire wrapped around the tree.  A tree which is, itself, pretty physically complex.  They catch everywhere.  Taking them off is a pain in the neck and needs to be done before you start disassembling the tree.

Actually, no it doesn’t.

Here’s what you can do: find one end of the lights and pull lightly.  Identify the branch on which it is caught and pull the branch off and leave it on the floor.  This has the entertaining property of making it significantly easier to take the lights off and doing a fair proportion of the next step.  You can then

  • Take the remaining branches and flatten them before dropping them on the floor as well. 
  • Sit down and flatten the remaining branches
  • Put the whole thing in the box.

This is definitely improved, but the two stage flattening looks inelegant.  I can’t flatten the branches while I’m taking off the lights because my hands are already occupied.  But what would have happened if I’d added the rest of the tree’s decorations into the analysis?

Here, we’ve got another process improvement.  Removing the branch and then removing the decorations from it is probably easier than removing them from the fully assembled tree.  The lights would then be easier to remove.  Finally, it addresses all of the branches, making it possible to flatten them straight after removing the decorations and re-introducing some of the “flow” we lost when we realized the boxing was a batch step.

Why didn’t I do that?  Simply, that bit was done by my wife and I wasn’t involved at that stage.  Again, we’re seeing another aspect of lean thinking here: to correctly optimize the process flow, I can’t just concentrate on my part of the job, I’ve got to look at the whole enterprise.  Of course, that’s easier to achieve when you’re part of the same company (or marriage) than otherwise, but often that’s where a lot of benefit can be found.

So, what have we seen here:

  • Making processes flow is desirable, but there are cases, such as packing the branches, where it doesn’t work.
  • The more steps in the value chain you include, the more likely you are to come up with an optimal solution.
  • Communication with other producers in the value chain can revolutionise the process.
Technorati Tags: ,

Understanding the Single Responsibility Principle

You might be wondering why I tackled single responsibility last rather than, as is more conventional, first.  Partly it’s because I simply found it very hard to write about, but I think it goes deeper than that: it’s actually very hard to understand, partly because of the perspective issues it raises.  There’s no one right answer to how to observe SRP.

The official statement of the principle is “A class should have one, and only one, reason to change.”  It’s not clear to me that “one reason to change” is any better defined than “single responsibility”.  As I’ve said before, it’s fundamentally a naming problem.  Academic studies on functional cohesion focus on coming up with better metrics.  Given that no-one’s developed a decent metric for evaluating a method yet, I don’t think this is going to be fruitful. 

However, I think it’s worth looking at the single responsibility principle and seeing how it interacts with the other SOLID principles.  From the perspective of the interface segregation principle, it basically looks like a generalization.  Not only should your interactions be small and well defined, so should your implementations.  Like the ISP, it makes observing Liskov easier.  The fewer things a class does, the less likely you’re going to need to break Liskov to get a subclass to do what you need.  Equally, it’s less likely to need to change, so it makes it easier to observe the open closed principle.

The story gets even more interesting when you look at dependency inversion.  The smaller your objects, the more you’re going to have to throw around.  Again, you probably need facades on top of these single responsibility objects to simplify interactions.  Providing a facade is a responsibility in its own right.*  However, just as Liskov makes inheritance work, Single Responsibility makes pluggability work.  The smaller classes need to be changed less often, and are easier to swap out for alternative implementations.

So, where do we go next?  Well, the Open Closed Principle lead us to refinements, where we came up with techniques to ensure it such as constructor injection and Liskov.  Equally, since we have an issue of naming here, it can help to standardize naming in some way.  Luckily, we have a fairly large catalog of standard names to begin with in the shape of design patterns.  e.g. Abstract Factory, Repository, Presenter

*Or to put it another way: eventually you’re going to need a car object.

Introducing Solution Transform: Enabling Parallel Development for .NET and Silverlight

I can’t be the only person who has been frustrated by the inflexible nature of Visual Studio solutions and projects.  So when Krzysztof asked for someone to write a program to convert vanilla .NET projects to Silverlight projects, I jumped at the chance.  Of course, I then proceeded to take four months to deliver what is, in all honesty, a fairly simple piece of code.  Anyway, it’s finally checked into Castle Contrib at https://svn.castleproject.org/svn/castlecontrib/SolutionTransform/trunk/.

Ironically, I’ve already blogged about the basic architecture, although the code is now a bit more complex than the braindead example I was running with at the time. I make BOO do the work.  Basically, the code goes through the solution and filters out projects.  It then applies transforms to the projects and (optionally) the underlying code files.

You call it as follows:

SolutionTransform <<Name of Script>> <<Full Path of Solution>>

There’s only two scripts so far (in the scripts folder).  One standardizes code files for the Castle Project, the other converts castle vs2008 projects to Silverlight 3.0 projects.  This second has been the whole point of the project .  It’s the missing piece of any plan to develop a class library for regular .NET and Silverlight simultaneously.  Without something like this, it’s a complete pain to keep the versions in sync.

The Challenge

You’ll find there are exactly four tests at the moment.  I know what some people are going to say about this, but the truth is the expected end result hasn’t been very well understood until quite recently.  This was, in fact, the principal challenge in writing the code.  Krzysztof had to throw several versions back before I checked anything in.  It looked like it would work, but it didn’t.  Writing extensive tests wouldn’t have helped: the tests would have been wrong too.

The nature of the project is that I’m pretty much guaranteed that there’s going to be a wall of edge cases.  I’ve spent a month with something that looked stable except for one show-stopper.  (I’ll blog about that soon.)  Neither of these file formats is exactly documented.  CSProj files are actually MSBuild files, but with conventions.  The conventions aren’t exactly defined anywhere.  Solution files aren’t documented anywhere at all.  In future, I expect the number of tests to grow faster than the code base.

To give you an idea of how bad it is, open up a solution file in Notepad.  Make a small modification like changing a project filename and save it to another file.  See if you can double click it.  Your chances are about 50/50.  It has to be UTF-16, and sometimes there’s a mysterious mandatory blank line at the top of the file.  

What’s Next?

Well, it’s pretty modest at the moment, but I’d like it to become a fairly general library for manipulating Visual Studio files.  .NET has fragmented, as was inevitable.  Keeping Silverlight, Mono, 4.0 and Compact Framework together is a pain at the moment.  The next problem I’d like to address is swapping between reference assemblies and project files.  Synchronizing assembly dependencies is a big deal as well.  However, like all OSS projects, the future direction is pretty much a direct function of who’s interested.

A small note: this is very early days, and the API is likely to change quite a lot as we learn more about the problem space.  If you want to use this, and really don’t want to worry about change, take a copy of the executable.  As with everything Castle Project, it’s licensed under Apache 2.0.  Finally, a big thanks to Krzysztof, who’s done a fair chunk of the testing and has put up with more dud versions than one man should.