Last minute geek

last minute tech news from around the net

Sunday, Nov 19th

Last update01:00:00 AM

You are here: English WTF CodeSOD: The Distract Factory Pattern

CodeSOD: The Distract Factory Pattern

User Rating: / 0
PoorBest 

The Gang-of-Four design patterns have an entire category of creational patterns, to handle the complexities of creating objects. And yes, it can get complicated, especially when we think in terms of the single-responsibility principle. Often, creating an instance of an class is itself so complex that we need a new class to do it.

Thus, we have the Factory pattern. And the Abstract Factory Pattern. And the Abstract Factory Factory Abstract Provider Bean pattern, if you’re using Spring. The purpose of these patterns is to add indirection between the client, calling code, and the creation of the objects- different concrete implementations can be instantiated, without the client code needing to worry about what actual type it received. Polymorphism wins the day. Code is more loosely coupled, because the client code never needs to name the concrete type it uses.

Unless you want to do it wrong, in which case Jen M found this particular solution:

public abstract class TaskBase
{
        public static TaskBase CreateInstance(
                Manager manager,
                Type TaskType)
        {
                object[] args = {manager, -1};

                return Activator.CreateInstance(TaskType, args) as TaskBase;
        }

        public static TaskBase CreateInstance(
                Manager manager,
                int taskId,
                string fullyQualifiedTypeName)
        {
                var TaskType = TypeLoader.GetType(fullyQualifiedTypeName, true);

                object[] args = {manager, taskId};

                var taskInstance = Activator.CreateInstance(TaskType, args) as TaskBase;

                return taskInstance;
        }
}

In this version, you can specify the concrete child of TaskBase that you want an instance of, and this will helpfully call the constructor for you. That means you could write:

var task = TaskBase.CreateInstance(mgr, TypeOf(MyDll.MyPackage.BasicTask))

Which is obviously far more loosely coupled than:

var task = new BasicTask(mgr);

As Jen puts it: “Some of the code I see makes me want to quit my job and go hunt down the people who wrote it. This is one of those instances.” Instead, Jen replaced this code with an actual version of the Factory pattern.

[Advertisement] Manage IT infrastructure as code across all environments with Puppet. Puppet Enterprise now offers more control and insight, with role-based access control, activity logging and all-new Puppet Apps. Start your free trial today!

Read all
Comment Policy:
We pre-moderate any comments and welcome all kinds of thoughts, supportive, dissenting, critical or otherwise. We delete or censor comments that are:

* abusive
* off-topic
* contain personal attacks, or against any company or organization
* promote hate of any kind
* use excessively foul language
* is blatantly spam or advertising

We do not discriminate based on the person who is posting, and we never censor comments for political or ideological reasons. We never delete an appropriate comment because we disagree with its viewpoint or ideology, and we never publish an inappropriate comment because we agree with or support its viewpoint or ideology.


Attention spammers: we manually approve all comments. Spamming and blatant advertising will NOT be published on this site and is deleted immediately, you've been warned, do not waste your time here.

Add comment

Security code
Refresh