Abstract Factory

Revisiting the GoF patterns with a good friend and learned more about the Abstract Factory pattern.

For some reason at jobs in the past, developers always talked about the “factory pattern” and I kind of thought I knew what they meant. But looking closer at the GoF patterns, there is the Abstract Factory and the Factory Method pattern.
And the things I come across with “factory” tacked at the end, are neither.

There is so much literature on this, so go ahead and refresh your memory, if you need to (search Abstract Factory and Factory Method)

In the wild I will usually come across a FooFactory with a static method CreateIFoo(string argument), encapsulating some basic decision logic on how to decide which subclass to return.

But the value of an Abstract Factory, being able to replace a family of related objects by other concrete classes, is never leveraged. Because OO design is hard and thus there hardly ever are any rich object models, where the opportunity and need for this would arise.

And an advantage of the Factory Method, letting you extend the supported types in a clean modular way, also isn’t leveraged. Because FooFactory is implemented as a monolithic base structure that contains all the logic to create any subclass.

Theme music for this blog post

Advertisements
Abstract Factory

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s