We Keep Coding

Why MemberwiseClone() can not be used directly, like other inherited methods of Object class? (For shallow copy)

Lets say I have some custom type:
public class MyClass
{
public int Age;
}
According to MS documentation here, all classes in .NET are derived from Object, and every method defined in the Object class is available in all objects in the system
Since Object.MemberwiseClone() is part of object class, why I can't do shallow copy just by calling it form instance on my custom class, like "Equals(), GetHashCode(), etc? Why I can't do something like this:
class Program
{
static void Main(string[] args)
{
MyClass myClass = new MyClass();
MyClass myClassCopy = (MyClass)myClass.MemberwiseClone(); //Not working!
}
}
Instead, in all the examples I have see, I need to implement some shallow copy method explicitly like:
public class MyClass
{
public int Age;
public MyClass ShallowCopy()
{
return (MyClass)MemberwiseClone();
}
}
And only then, I can call to this method ShallowCopy().
[EDIT]
I think this question here explains the point:
Why is MemberwiseClone defined in System.Object protected?
I was need to ask what it the rationale of making Object.MemberwiseClone() as
private, and the main reason is:
The problem here is that MemberwiseClone just blindly copies the state. In many cases, this is undesirable

It's a protected method - presumably to allow each class's implementation to decide on whether or not memberwise cloning makes sense and, if so, how to expose it to callers.

Why would one create a Base Class object with reference to the Derived Class

I was practicing inheritance, using a test program in C# and I found out that the following statement does not throw an error:
BaseClass baseObj = new DerivedClass();
Why is this statement allowed and is there a situation where this statement would be useful to a programmer?
Here is my test program:
class BaseClass
{
public void show()
{
Console.WriteLine("Base Class!");
}
}
class DerivedClass : BaseClass
{
public void Display()
{
Console.WriteLine("Derived Class!");
}
}
class Result
{
public static void Main()
{
BaseClass baseObj = new DerivedClass();
baseObj.show();
}
}

I recommend you read about inheritance and Polymorphism in more detail. (here and here)
In this answer I try to keep concepts simple enough.
Why is this statement allowed and is there a situation where this
statement would be useful to a programmer?
But in order to explain your question a bit lets take a look at simple and classic example of object oriented program that needs to use polymorphism.
Assume you are writing a program that needs to store some shapes and display them on screen. To achieve this you need to store all shapes in an array for example. right?
Suppose our classes are something like these:
class BaseShape
{
public virtual void Display()
{
Console.WriteLine("Displaying Base Class!");
}
}
class Circle : BaseShape
{
public override void Display()
{
Console.WriteLine("Displaying Circle Class!");
}
}
class Rectangle : BaseShape
{
public override void Display()
{
Console.WriteLine("Displaying Rectangle Class!");
}
}
And your array can be object array. like this:
object[] shapes = new object[10];
In your application you need to write a method to display shapes.
One solution can be iterating over all shapes and call right method of exact type of shape. like this:
public static void DisplayShapes_BAD(){
foreach(var item in Shapes)
{
if(typeof(Circle) == item.GetType())
{
((Circle)item).Display();
}
if(typeof(Rectangle) == item.GetType())
{
((Rectangle)item).Display();
}
}
}
But what happens when another type of Shape appears in application? Basically you need to modify DisplayShapes_BAD() method to support new type of Shape (add new if statement to body of method)
This way you break Open/Closed principle of object oriented programming. and your code is not much maintainable.
Better way to store shapes to avoid this bad method is to use array of BaseShape. like this:
public static List<BaseShape> Shapes = new List<BaseShape>();
Here is how to add item to this list of shapes:
Shapes.Add(new Circle());
Shapes.Add(new Rectangle());
Now take a look at good implementation of DisplayShapes method.
public static void DisplayShapes_GOOD()
{
foreach(var item in Shapes)
{
item.Display();
}
}
In above method we call Display method on item with type of BaseShape. But how C# knows to call right method (for example circle display or rectangle display). This mechanism is Polymorphism.
Complete Code shared as Gist.

As per my understanding in java,You are trying to call object of DerivedClass by using BaseClass reference varibale baseobj and this coding scenario is totally valid because it is providing the facility of runtime polymorphism.
Before runtime polymorphism lets understand the Upcasting. When reference variable of parent class is used to refer the object of child class then it is called as Upcasting
class A{}
class B extends A{}
A obj= new B // Upcasting.
Runtime Polymorphism is a process in which a call to an overridden method is resolved at runtime rather than compile-time.
Since you are not overriding show method in derived class,You are not doing runtime polymorphism but simply upcasting and upcasting is useful when we want to resolve the calling to overridden method at runntime.

First off, the question why it's allowed, is simply because an instance of the derived class is an instance of the base class (subtype polymorphism). Same goes for being able to assign any derived class to an object variable: all .net classes derive from object in the end, so you could also have done object baseObj = new DerivedClass().
The goal of the type that is used for the declaration is to indicate which type of interface is being worked with (intent). If you would declare the variable as object, you'd say that only the reference is important. If you declare as BaseClass, you say that you are using an object where the properties and methods of BaseClass are important. By using BaseClass baseObj = new DerivedClass(), you are saying you need the BaseClass functionality, but are using a DerivedClass instance to define the workings of the mapping described in BaseClass.
One reason for this could be that BaseClass is abstract (BaseClasses often are), you want a BaseClass and need a derived type to initiate an instance and the choice of which derived type should be meaningful to the type of implementation.
A reason for which it's even more often used, is because at any time, another class deriving from BaseClass can be assigned to the same variable. Consider:
BaseClass baseObj = SomeCriterium ? (BaseClass)new DerivedClass() : new AlternateDerivedClass();
The scope of the variable in the example is only in the main method, but if it were anywhere in the class, or it could be changed through a property or otherwise, by using BaseClass, anyone using your class could assign other BaseClass (derived) instance, instead of only DerivedClass (derived) instances.
Finally an example for reassigning, using an interface declaration (as far as polymorphism is concerned, the same can be applied to declaring an implemented interface instead of the class as it can to a baseclass):
IEnumerable<T> values = new List<T>();
if(needfilter)
values = values.Where(el => filtercriterium);
If values was declared as a List, the values variable could not be reused for the filtered enumeration. Basically first you say that you need the values variable only for enumeration. After that you can reassign values with another enumeration instead of only with a list.

Generic abstract class inheritance

Explanation:
I have an abstract class like so:
public abstract class Serializer<T> where T : new()
{
T obj { get; set; }
public string ToXML()
{
// return string XML
}
}
And another class that inherits this abstract class:
public class Account : Serializer<Account>
{
// Code
// I don't want to have to implement the methods of
// the inherited class/interface.
}
I want to access it like such:
Account account = new Account();
Console.WriteLine(account.ToXML());
Question:
Can I do this and pass the account to the property obj so the ToXML can perform its task of converting the object to a string?
Serializer s = new Serializer();
s.ToXML(account);
I'd prefer to have each object inherit the Serialize class and all its methods, and just be able to know that without editing anything but adding the inheritance of the class that I can now access these methods.
On another note, I feel like inheriting a class violates the is-a and can-do principles between choosing an interface or a class, but I don't want to override all the methods, when I already have the code written to do it generically in a class (i.e., I don't want to implement the interface). Is there a way to inherit the methods of an interface like a class (no implementing/overriding).

Try to return this:
T obj { get { return (T)this; } }
But, this means that the child class has to provide itself as a type parameter, it's the curiously recurring "template" pattern... To be sure though, you don't necessarily need to know the type of the object at compile time to serialize it to XML (if you use the usual serializers), so accessing this within the serializer method would be OK, without the need for that type parameter and that property.
I'd personally prefer a more hands off approach to an abstract base class (using the XmlSerializer):
public interface MXmlSerializable { }
public static class XmlSerializable {
public static string ToXml(this MXmlSerializable self) {
if (self == null) throw new ArgumentNullException();
var serializer = new XmlSerializer(self.GetType());
using (var writer = new StringWriter()) {
serializer.Serialize(writer, self);
return writer.GetStringBuilder().ToString();
}
}
}
M stands for mixin. It's effectively a marker interface with an extension method. Use it like this:
public class Account : MXmlSerializable {
...
}
...
Account account = new Account();
...
string accountXml = account.ToXml();

Your construct hardly makes sense. There's no clear point for the Serializer<T> instance to point to itself. You can easily use this and cast it to T. Also, unless your ToXML method implements some really generic XML serialization algorithm (like processing the current instance via reflection), you should make it virtual and place the specific implementations in Serializer<T>'s ancestors.
Also, I would also object your approach to inheritance. If your Account class is in fact a single purpose account serializer, then name it so (AccountSerializer). If not, and Account represents an actual account, then yes, from an independent reader's point of view you are mixing two primary concepts: a business object (Account) and some technical mechanism (Serializer<T>).
If you have a general-purpose serialization algorith, why don't you just have a separate, non-abstract Serializer<T> class, accepting T instances in ToXML()? You will end up with better separation of concerns.
Is there a way to inherit the methods of an interface like a class (no implementing/overriding).
No. Interfaces are interfaces, not classes than embed particular code.

What about just doing it like this;
public string ToXML()
{
convert `this` to xml directly
// return string XML
}
Why do you need the property to return a reference to the class itself.
With the above structure you can do the following, without even needing the T property
Account account = new Account();
Console.WriteLine(account.ToXML());

If your code in the Abstract class will not change just to serialize the object, this approach doesn't make sense, Serialization you do not need to know the object type (Especially if your using xml which means building a easy to access string).
If you want the Serialization only available to certain objects make an interface i.e
public interface ISerialize
{
}
public class Account : ISerialize
{
}
and then create an Extension method
public static class ExtenstionMethods
{
public static string ToXml(this ISerialize obj)
{
// code to build xml string
}
}
This way you can do what you want to do because Account is of the Interface and the ExtensionMethods will only work on that Interface, thus you only need the code in the ExtensionMethods class and then include the namespace wherever you want to use the "ToXml()" etc
Account account = new Account();
Console.WriteLine(account.ToXML());

Creating an instance of derived class through the base class without hardcoding

My problem is as follows:
I have a base class that needs to be abstract. It has several derived classes, each with their own special properties that are contained in the Properties member.
I need to be able to create a new instance of one of these derived classes, so that all the members are equivalent but modifying the new instance doesn't modify the original.
Finally, I want to do it without having to hardcode in every derived type of the base class. (Which would, admittedly, be the easiest solution, however that isn't the point)
All the derived classes satisfy an "is-a" relationship to the base class.
Here is the code:
public abstract class BaseClass
{
//Default properties here
int x, y, z, ...;
//Custom made class to hold custom properties
protected Attributes Properties;
public BaseClass createNewInstance()
{
return createNewInstanceStep1();
}
//Each derived class implements their own version of this,
//to handle copying any custom members contained in Properties.
protected abstract BaseClass createNewInstanceStep2();
protected BaseClass createNewInstanceStep1()
{
BaseClass newInstance = new BaseClass(); // <- Doesn't work because class is abstract
//Copy default properties
newInstance.x = x;
newInstance.y = y;
newInstance.z = z;
//Call the new instance's step 2 method, and return the result.
return newInstance.createNewInstanceStep2();
}
}
The issue with this code is the BaseClass newKeyFrame = new BaseClass(); line. As the class is abstract, you cannot create an instance of it.
The problem is that I need to be able to call the constructor of whatever type the derived class is, as they all have different code in their constructors that cannot be shared.
I've heard that using Reflection might be a viable solution, however I have no idea how.
How can I solve this without having to hardcode in a case for every derived type?

You could make createNewInstanceStep1 generic. I've also modified the Step2 to be type void (I'm expecting it to modify the current instance, so the return would always be return this; anyway), because otherwise it doesn't really make sense the way I'd like to use it here. If it doesn't make sense to change it like this, then my whole approach of only making this method generic won't work.
And createNewInstance now uses reflection to call the equivalent of return createNewInstanceStep1<this.GetType()>();.
public BaseClass createNewInstance()
{
var method = typeof(BaseClass).GetMethod("createNewInstanceStep1", BindingFlags.NonPublic | BindingFlags.Instance).MakeGenericMethod(this.GetType());
var value = method.Invoke(this, null);
return (BaseClass)value;
}
//Each derived class implements their own version of this,
//to handle copying any custom members contained in Properties.
protected abstract void createNewInstanceStep2();
protected T createNewInstanceStep1<T>() where T : BaseClass, new()
{
T newInstance = new T(); // works!
//Copy default properties
newInstance.x = x;
newInstance.y = y;
newInstance.z = z;
//Call the new instance's step 2 method, and return the result.
newInstance.createNewInstanceStep2();
return newInstance;
}
If this won't work, another approach is a self-referential generic type. It's good to avoid this, though, because it's confusing and overall not a good design.
public sealed class SubClass : BaseClass<SubClass>
{
protected override SubClass createNewInstanceStep2()
{
Console.WriteLine("In step 2");
return this;
}
}
public abstract class BaseClass<T> where T : BaseClass<T>, new()
public T createNewInstance()
{
return createNewInstanceStep1();
}
//Each derived class implements their own version of this,
//to handle copying any custom members contained in Properties.
protected abstract T createNewInstanceStep2();
protected T createNewInstanceStep1()
{
T newInstance = new T();
...

What's the problem with letting the derived classes do the instantiation of the new instance?
public abstract class BaseClass
{
//Default properties here
int x, y, z, ...;
//Custom made class to hold custom properties
protected Attributes Properties;
public abstract BaseClass createNewInstance();
protected void CopyData(BaseClass original)
{
this.x = original.x;
this.y = original.y;
this.z = original.z;
}
}
public class ChildClass : BaseClass
{
public BaseClass createNewInstance()
{
ChildClass newInstance = new ChildClass();
newInstance.CopyData(this);
// Do any additional copying
return newInstance;
}
}

You can make createNewInstanceStep1 a protected void init method that initiates this object, and call it in each subclass's constructor.

How are you going to know what type of instance to create? If you'll have an existing instance of the derived class and want to create another instance which is basically identical to it, you should have your base type implement a protected virtual CloneBase method which calls MemberwiseClone and does any deep copying the base type knows about, and a public Clone method which chains to CloneBase and casts to the base type. Each derived types should override CloneBase to chain to base.CloneBase and add any necessary additional deep copying (that step may be omitted if no additional deep-copy logic is required), and also shadow the public Clone method with one that chains to CloneBase and casts the result to its type [using a separate CloneBase makes it possible to both declare a new Clone method with a different signature while also overriding and chaining to the base-class method].
If you'll have an existing instance of the new class, but want its properties to be copied from some other instance, could have an abstract ConstructInstanceLike(x) method which each derived type would implement to either call one of its constructors, or clone itself and modify the clone to match the passed-in object. Neither approach is terribly elegant, but either can work.
If you won't have an existing instance of the new class, you'll need some other means of getting something of the appropriate type. The nicest approach is probably to store a collection of Func<TParams, TResult> delegates, one for each derived type of interest, and then invoke one of those functions to generate an object of one of the associated derived type. It would also be possible to define an interface
IFactory<TParam, TResult> { TResult Create(TParams param); }
but in many cases a delegate will be more convenient to work with.

C# creating another instance of subclass - Reflection?

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?
i.e. 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.

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.

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

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 */
}
}

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.