Ayende @ Rahien

João P. Bragança commented on Design patterns in the test of time: Abstract Factory

Wed, 24 Oct 2012 17:53:25 GMT

@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.

Ed Blackburn commented on Design patterns in the test of time: Abstract Factory

Wed, 24 Oct 2012 15:22:47 GMT

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.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() { } }

Michael commented on Design patterns in the test of time: Abstract Factory

Wed, 24 Oct 2012 08:26:59 GMT

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.

Rafal commented on Design patterns in the test of time: Abstract Factory

Wed, 24 Oct 2012 04:30:12 GMT

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.

Steve Py commented on Design patterns in the test of time: Abstract Factory

Wed, 24 Oct 2012 02:41:28 GMT

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)

Bertrand Le Roy commented on Design patterns in the test of time: Abstract Factory

Tue, 23 Oct 2012 17:50:04 GMT

Any thoughts about how abstract factory relates to dependency injection?

slava commented on Design patterns in the test of time: Abstract Factory

Tue, 23 Oct 2012 17:04:06 GMT

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.

Philip Nelson commented on Design patterns in the test of time: Abstract Factory

Tue, 23 Oct 2012 15:27:30 GMT

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.

Pop Catalin commented on Design patterns in the test of time: Abstract Factory

Tue, 23 Oct 2012 15:25:47 GMT

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.

tobi commented on Design patterns in the test of time: Abstract Factory

Tue, 23 Oct 2012 14:35:01 GMT

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