I think WCF would have been well off using the ASP.NET MVC filter model. WCF actions are very similar to REST endpoints.

Still better than:

if Windows

...

elseif Mac

...

However what I've come to like allo more than abstract factories is a plugin architecture combined with a boostrapper reponsible for dynamically loading pluggins.

This way you can centralize and isolate your specific features in separate plugins, withouth having to deal with the mess of working with factory factories.

Well, yes. It does seem to point at a conflict though, and too may layers is the inevitable result. The old adage, that all problems in computer science can be solved with another layer of indirection, results in things like Abstract Pattern where you point at places in your architecture and say that all things must pass through here. What you need is a good way to say, you must pass though here when you need to, and otherwise, not so much.

I think in general Factory pattern is just OOP alternative to Functional curry if you will.

Intuition would be to think about this pattern (or curry in OOP) as a process to shape object. You have some formless object (wrapped in factory pattern), you give it more specs and it starts to shape itself, and you can continue to shape it until you satisfied and it fits your needs.

Any thoughts about how abstract factory relates to dependency injection?

My favourite flavour of abstract factories are when someone gets the idea to abstract something like an ORM/DAL, then proceed to create an abstract factory that only has one construction option with a comment that they may want to support "X" in the future. YAGNTDAF! (ya ain't gonna need that damned abstract factory)

Java hasn't changed that much since Joel's post. They have added a few factory factories to the standard. For example, an ORM factory [JPA] - Steve, you'll like it.

Instead of checking the OS_TYPE, I would let the Installer decide which is the correct Type to use, configure the type where Autofac (or whatever Inversion of Control Container you use) can map it to IGUI Factory.

I agree, implementing this pattern is a degree of last-resort. It has certainly been superseded (and just as abused by Containers).

Personally I'm not a fan of switch statements - a popular hacky alternative for object creation.

For simple abstract factories I've followed this approach:

internal abstract class Widget
{
    internal static Widget Create()
    {
        var map = new Dictionary<PlatformID, Func<Widget>>
                      {
                          {PlatformID.Win32Windows, () => new Windows()},
                          {PlatformID.MacOSX, ()=> new Mac()}
                      };

        return map[Environment.OSVersion.Platform]();
    }

    internal abstract void Action();
}

internal class Windows : Widget
{
    internal override void Action() { }
}

internal class Mac : Widget
{
    internal override void Action() { }
}

@Ed Blackburn,

That IS a container, it's just far far simpler than the ones you see out there. :) As long as Widget has no dependencies this is the way to go IMO.