Is it worth abstracting out Object creation for single classes?

I'm playing around with design patterns, and things are coming along nicely. One thing I'm unsure of is it worth abstracting out Object creation when there is currently only one object?

For example a project I'm working on contains two different user types which are not related in any way. They are IStudent and IStaff. For the application in question, there will never be any other types of user (staff Roles handle all none-student interactions with the system).

In my controllers I could simply:

IStudent student = new Student();

Or I something like this:

public static class UserFactory
{
    public static 开发者_高级运维T Create<T>() where T : class
    {
        if(typeof(T) == typeof(IStudent))
            return new Student() as T;

        if (typeof(T) == typeof(IStaff))
            return new Staff() as T;

         throw new Exception("The requested user type is not valid.");
    }
}

And then:

IStudent student = UserFactory.Create<IStudent>();

Is this overkill? I'm trying to work out best practice in these situations.

---

Personally, I use TDD for most development. One thing I like about that is that it provides an answer for your question: "not unless it's required to make a failing unit test pass".

In other words, if you don't need it, then don't do it.

---

Ok ... you need a factory class, or just, you need to call the constructor. Why people have fear to call a constructor?

I believe that patterns are good. I believe also that the abuse of them is pure evil :)

If you start to see that your programming paradigm is making your life harder, then abandon that paradigm, not your programmer abilities. Sometime too much abstraction is just not useful at all.

Being clean and writing clean codes don't means following a pattern, means writing code that makes sense.

The Factory pattern: if we have to write a Factory for the Factory and a Factory for the Factory for the Factory .... until the deadline arrives, when we write the real code?

Since I see system analysts more as architects than bricklayers, i believe that just following some rule cannot make your software good.

People can blame Turing or Church or Goedel if they want, but is not their fault if a software that write software cannot be written :) We still need our human part to write software, our creativity and imagination and our soul, also if some software engeneer tried to make it a pure mechanical act, programming is still an art in a big part of it.

Conclusion: I believe patterns are very good if used with the right criticism and following always the good programmer's sixth sense :)

I think that programming requires some flexibility, we are not in a perfect world, we have no perfect computer, we are not perfect and our software cannot be perfect and especially machine cannot think, still.

So, calling a constructor is always better than 2000 lines of code to just call a constructor.

---

In this particular case, your solution provides no benefits over simply calling the constructor. If you have a reason for a factory, then by all means. Otherwise, don't over-complicate your code.

If your controller always knows what kind of User it's going to create (i.e. it's always going to pass in a concrete type in your type parameter), you don't need a factory.

---

You would generally only use the factory pattern when creating more than one type and you want to hide creation to prevent ugly things like:

if(newPerson == "student")
 person = new Student();
else if(newPerson == "Staff")
 person = new Staff();

You could then just do:

Person.CreatePerson(newPerson);

Again, this only matters if you have to do if then statements in more than one place.

---

I would say that your message:

there will never be any other types of user (staff Roles handle all none-student interactions with the system)

Very similar to this one:

640K of memory is all that anybody with a computer would ever need

In other words use simpler code you can, as suggests Sounders, but keep in mind that one day something could change, even if today it seems impossible.

EDIT

If you have a sequence of types (not just 2 ) of completely unrelated classes (from design perspective) Factory pattern applied by you could be pretty suitable IMHO.

Good luck.