views:

407

answers:

14

I have a collection of classes that inherit from an abstract class I created. I'd like to use the abstract class as a factory for creating instances of concrete implementations of my abstract class.

Is there any way to hide a constructor from all code except a parent class.

I'd like to do this basically

public abstract class AbstractClass
{
    public static AbstractClass MakeAbstractClass(string args)
    {
        if (args == "a")
            return new ConcreteClassA();
        if (args == "b")
            return new ConcreteClassB();
    }
}

public class ConcreteClassA : AbstractClass
{
}

public class ConcreteClassB : AbstractClass
{
}

But I want to prevent anyone from directly instantiating the 2 concrete classes. I want to ensure that only the MakeAbstractClass() method can instantiate the base classes. Is there any way to do this?

UPDATE
I don't need to access any specific methods of ConcreteClassA or B from outside of the Abstract class. I only need the public methods my Abstract class provides. I don't really need to prevent the Concrete classes from being instantiated, I'm just trying to avoid it since they provide no new public interfaces, just different implementations of some very specific things internal to the abstract class.

To me, the simplest solution is to make child classes as samjudson mentioned. I'd like to avoid this however since it would make my abstract class' file a lot bigger than I'd like it to be. I'd rather keep classes split out over a few files for organization.

I guess there's no easy solution to this...

+1  A: 

No, I don't think we can do that.

Vaibhav
+1  A: 

You can make the sub classes child classes, something like this:

public abstract class AbstractClass
{
    public static AbstractClass MakeAbstractClass(string args)
    {
        if (args == "a")
            return new ConcreteClassA();
        if (args == "b")
            return new ConcreteClassB();
    }

    private class ConcreteClassA : AbstractClass
    {
    }

    private class ConcreteClassB : AbstractClass
    {
    }
}

@Vaibhav This does indeed mean that the classes are also hidden. But this is as far as I am aware the only way to completely hide the constructor.

Edit: As others have mentioned the same thing can be accomplished using Reflection, which might actually be closer to what you would like to be the case - for example the above method replies on the concrete classes being inside the same file as the Abstract class, which probably isn't very convenient. Having said that this way is a nice 'Hack', and good if the number and complexity of the concrete classes is low.

samjudson
Nice example, but make the naming a bit more .NETy and call it "CreateAbstractClass(string args)" for coding-standards sake :)
Seb Nilsson
A: 

@samjudson

If we make the sub classes private, then they won't be usable from outside (or at least any subclass specific methods/properties won't be).

Vaibhav
+3  A: 

If the classes are in the same assembly, can you not make the constructors internal?

Rob Cooper
A: 

@Vaibhav

Why use a factory if you are going to be calling implementation specific methods/properties?

Chris Marasti-Georg
A: 

@Chris

you are right. I concede. Although, I still think that there may be cases where you might still use a factory, but have implementation specific methods.

@Sam

this means, your method will work.

Vaibhav
A: 

Do you actually need to do this? If you're using some kind of pseudo factory pattern without a true design need for it, you're only going to make your code harder to understand, maintain and extend.

If you don't need to do this, just implement a true factory pattern. Or, more ALTy, use a DI/IoC framework.

Will
+6  A: 

To me, the simplest solution is to make child classes as samjudson mentioned. I'd like to avoid this however since it would make my abstract class' file a lot bigger than I'd like it to be. I'd rather keep classes split out over a few files for organization.

No problem, just use partial keyword and you can split your inner classes into as many files as you wish. You don't have to keep it in the same file.

Previous answer:

It's possible but only with reflection

public abstract class AbstractClass
{
    public static AbstractClass MakeAbstractClass(string args)
    {
        if (args == "a")
            return (AbstractClass)Activator.CreateInstance(typeof(ConcreteClassA), true);
        if (args == "b")
            return (AbstractClass)Activator.CreateInstance(typeof(ConcreteClassB), true);
    }
}

public class ConcreteClassA : AbstractClass
{
    private ConcreteClassA()
    {
    }
}

public class ConcreteClassB : AbstractClass
{
    private ConcreteClassB()
    {
    }
}

and here is another pattern, without ugly MakeAbstractClass(string args)

public abstract class AbstractClass<T> where T : AbstractClass<T>
{
    public static T MakeAbstractClass()
    {
        T value = (T)Activator.CreateInstance(typeof(T), true);
        // your processing logic
        return value;
    }
}

public class ConcreteClassA : AbstractClass<ConcreteClassA>
{
    private ConcreteClassA()
    {
    }
}

public class ConcreteClassB : AbstractClass<ConcreteClassB>
{
    private ConcreteClassB()
    {
    }
}
lubos hasko
A: 

What you need to do is this to prevent the default constructor to be create. The internal can be change to public if the classes are not in the same assembly.

public abstract class AbstractClass{

 public static AbstractClass MakeAbstractClass(string args)
 {
    if (args == "a")
        return ConcreteClassA().GetConcreteClassA();
    if (args == "b")
        return ConcreteClassB().GetConcreteClassB();
 }
}

public class ConcreteClassA : AbstractClass
{
  private ConcreteClassA(){}

  internal static ConcreteClassA GetConcreteClassA(){
       return ConcreteClassA();
  }
}

public class ConcreteClassB : AbstractClass
{
  private ConcreteClassB(){}
  internal static ConcreteClassB Get ConcreteClassB(){
       return ConcreteClassB();
  }

}
Jedi Master Spooky
A: 

Can't you use the keyword partial for splitting the code for a class into many files?

Peteter
A: 

If you are using this class in a seperate service assembly, you can use the internal keyword.

public class AbstractClass
{
    public AbstractClass ClassFactory(string args)
    {
        switch (args)
        {
            case "A":
                return new ConcreteClassA();               
            case "B":
                return new ConcreteClassB();               
            default:
                return null;
        }
    }
}

public class ConcreteClassA : AbstractClass
{
    internal ConcreteClassA(){ }
}

public class ConcreteClassB : AbstractClass
{
    internal ConcreteClassB() {}
}
FlySwat
A: 

@Jonathan: I don't think internal means what you think it means. The internal modifier limits access to only within the assembly, not just self or parent. That said, declaring the constructors internal may solve the OP's problem if he only wants to disallow instantiation from outside the assembly.

Mike Powell
A: 

@Jonathan: I don't think internal means what you think it means. The internal modifier limits access to only within the assembly, not just self or parent. That said, declaring the constructors internal may solve the OP's problem if he only wants to disallow instantiation from outside the assembly.

You are right, I modified my post to reflect that. I might have been thinking of Visual Basic's friend modifier.

FlySwat
A: 

Following on from the accepted answer, if you had a public interface and made the private classes implement the interface, you could then return a pointer to the interface and anyone outside of your parent abstract class could then use them (whilst still hiding the child classes).

Mark Ingram