C＃创建子类的另一个实例-反射？

Question

I'm reposting a question I've just asked, but want to re-ask this question in a more concise way as I think I was causing some confusion.

I have a base class: RoomObject. I have two subclasses: Bed and Table, which inherit from RoomObject.

I have a variable currentObject, which is of type RoomObject, but will actually hold either an instance of Bed or Table (RoomObject is never instantiated itself).

How can I clone my currentObject, without knowing its full type?

ie if currentObject is a Bed, I want to clone the Bed using

currentObject = new Bed(currentObject); 

and if currentObject is a Table, I want to use

currentObject = new Table(currentObject);

I could use reflection, by calling Activator.CreateInstance(currentObject.GetType()), and then copy across any attributes I need, but this seems messy.

Answer 1

You should use the pattern known as the virtual constructor , or a cloning method .

Add a virtual method to RoomObject that returns a copy of the current object:

abstract RoomObject Clone();

Now implement this method in Bed to return new Bed(...) , and in the Table to return new Table(...) . Pass whatever parameters necessary to the constructors of Bed and Table to copy what's in the current object.

.NET has an interface ICloneable that is commonly used to implement this pattern. A small disadvantage of that approach is that Clone must return object , not RoomObject , so if you need RoomObject , you'd need to cast it.

Answer 2

This is one of the best things about reflection: The ability to create an object without your client code knowing what type it is. Sometimes it can get messy, or even slow down the code at times, but--if used correctly--will make your code a lot more manageable.

For example, take a look at the Factory Pattern , and how one can implement it with Reflection and here as well

Answer 3

I think one solution would be implement ICloneable interface for all your objects. Here's some sample code:

class RoomObject : ICloneable
{
    public abstract object Clone();
}

class Bed : ICloneable
{
    public override object Clone()
    {
        return new Bed();
    }
}

class Table : ICloneable
{
    public override object Clone()
    {
        return new Table();
    }
}

class Program
{
    public static void Main(String[] args)
    {
        RoomObject ro = /* from some other places*/
        RoomObject newOne = ro.Clone() as RoomObject;  /* here's what you what */
    }
}

Answer 4

Instead of that, implement the ICloneable interface that's out-of-the-box on .NET Framework as others said in their answers.

Since ICloneable.Clone() method returns object , what about a custom ICloneable<T> that also implements ICloneable ?

public interface ICloneable<T> : ICloneable
    where T : class
{
    T TypedClone();
}

public class MyCloneableObject : ICloneable<MyCloneableObject>
{
     public string Some { get; set; }

     public object Clone()
     {
         MyCloneableObject clone = new MyCloneableObject { Some = this.Some };
     }

     public MyCloneableObject TypedClone()
     {
          return (MyCloneableObject)Clone();
     }
}

Later, in your code...

MyCloneableObject some = new MyCloneableObject();

if(some is ICloneable<MyCloneableObject>)
{
    MyCloneableObject myClone = some.TypedClone();

    // .. or the standard `Clone()`:
    myClone = (MyCloneableObject)some.Clone();
}

Implementing both built-in and custom interface is a good idea, as your cloneable will operate with other libraries that may accept ICloneable implementations.

Finally, rather than using reflection, this case should be solved in design-time. I would argue that doing with reflection should be done if you can't modify the library containing the ICloneable wannabe.