We Keep Coding

C# and inheritance chain of multiple types using generics

I have this setup, and it didn't work as I expected. It seems to me that a generic T in a base class is not the same as the generic T in its sub-class.
namespace StackOverflowQuestion
{
public class Poco1
{
public string Data { get; set; }
}
public class Poco2 : Poco1
{
public string ExtraData { get; set; }
}
public class Poco3 : Poco2
{
public string EvenMoreData { get; set; }
}
public class Base<T> where T: Poco1
{
public virtual void Method(T parameter)
{
// Do something even more general with Data...
parameter.Data = "Test";
}
}
public class FirstLevel<T> : Base<Poco2> where T:Poco2
{
public override void Method(Poco2 parameter)
{
// Do something general with ExtraData...
base.Method(parameter);
}
}
public class SecondLevel<T> : FirstLevel<Poco3> where T: Poco3
{
public override void Method(Poco2 parameter) // <-- Why not Poco3?
{
// Do something with EvenMoreData...
base.Method(parameter);
}
}
}
What I actually expected was that the Method override in type SecondLevel<T> should say Poco3 and not Poco2. Especially as I put a constraint on T to be of type Poco3.
Is it possible to achieve this in another way? It seems to me that the generic T can't be "overridden" the way I wanted. I suspect T in Base<T> is not the same as T in FirstLevel<T> and that T in FirstLevel<T> is not the same as T in SecondLevel<T>?
If SecondLevel<T> inherits from Base<T> then I get Poco3 in the Method override, but not when I inherit from FirstLevel<T>.
I can live with this issue, but then I need to cast the poco parameter type in Level-type sub-classes (from level 2 and up). In my opinion, that should be unnecessary as long as I specify the constraint. But, of course, there might be a good reason for this behavior that I don't see at the moment.

Rather than specifying the POCO type in each overridden method signature you can instead use the T type parameter.
T is already constrained to the POCO type you want so it should behave exactly as you want.
Oh, and I'd do the same with the type you're passing to the base class as well.
e.g.
public class FirstLevel<T> : Base<T> where T:Poco2
{
public override void Method(T parameter)
{
// Do something general with ExtraData...
base.Method(parameter);
}
}
public class SecondLevel<T> : FirstLevel<T> where T: Poco3
{
public override void Method(T parameter)
{
// Do something with EvenMoreData...
base.Method(parameter);
}
}

Difference between abstract class constructor and normal class constructor?

abstract class Animal
{
public string DefaultMessage { get; set; }
public Animal()
{
Console.WriteLine("Animal Cstor called");
DefaultMessage = "Default Speak";
}
public virtual void Speak()
{
Console.WriteLine(DefaultMessage);
}
}
class Dog : Animal
{
public Dog()
: base()//base() redundant. There's an implicit call to base here.
{
Console.WriteLine("Dog cstror called");
}
public override void Speak()
{
Console.WriteLine("Custom Speak");//append new behavior
base.Speak();//Re-use base behavior too
}
}
or else
class Animal
{
public string DefaultMessage { get; set; }
public Animal()
{
Console.WriteLine("Animal Cstor called");
DefaultMessage = "Default Speak";
}
public virtual void Speak()
{
Console.WriteLine(DefaultMessage);
}
}
class Dog : Animal
{
public Dog()
: base()//base() redundant. There's an implicit call to base here.
{
Console.WriteLine("Dog cstror called");
}
public override void Speak()
{
Console.WriteLine("Custom Speak");//append new behavior
base.Speak();//Re-use base behavior too
}
}
what is the Difference between abstract class constructor and normal class constructor?

No difference rather than an abstract class constructor can't be called publicly because otherwise it would defeat the purpose of abstract classes (i.e. they must be inherited and cannot be instantiated directly, thus an abstract class public constructor can be only called by a derived class constructor!).

Whilst you cannot instantiate an abstract class it may have a constructor that is called from a derived one. Thus an abstract one should never be public but protected. So the only difference from an API-point of view is that the first cannot be called directly from any arbitrary class while a normal constrcutor can be called allways from everywhere (depending on access-modifier of course).
To be more precise: an Animal-class should probably NEVER be not-abstract. That would mean that there are animals existing that cannot be categorized any further to Cats, Dogs or whatever, but only animals.

Why doesn't this method invocation invoke the derived class?

I have an interface IDeepCloneable, that I'm using to implement generic deep copying. I have a base class and a derived class as well, each implementing IDeepCloneable. I'm running into issues with derived classes.
Here is the code:
public class Program
{
public static void Main()
{
var a = new BaseClass();
var ac = a.DeepClone();
var b = (BaseClass)(new DerivedClass());
var bc = b.DeepClone();
}
}
public interface IDeepCloneable<T>
{
T DeepClone();
}
public class BaseClass : IDeepCloneable<BaseClass>
{
public string Value { get; set; }
public BaseClass(){}
public BaseClass(BaseClass copy)
{
Value = copy.Value;
}
public BaseClass DeepClone()
{
Console.WriteLine("BLAH1");
return new BaseClass(this);
}
}
public class DerivedClass : BaseClass, IDeepCloneable<DerivedClass>
{
public string SomeOtherValue { get; set; }
public DerivedClass(){}
public DerivedClass(DerivedClass copy)
: base(copy)
{
SomeOtherValue = copy.SomeOtherValue;
}
public new DerivedClass DeepClone()
{
Console.WriteLine("BLAH2");
return new DerivedClass(this);
}
}
This outputs:
BLAH1
BLAH1
I understand why it outputs BLAH1 twice, I'm just not sure how to fix it..

Your derived class needs to override the DeepClone() method, and your DeepClone method in the base class needs to be virtual.
Right now, your DeepClone method in the derived class is unrelated (other than having the same name) to the base class. See Interface Implementation Inheritance in the C# standard.
That said, it looks like you're trying to do deep copies. Have you considered using a BinaryFormatter to serialize and de-serialize your data?

since that base class or yours implements the interface already, so you can either make the base class's DeepClone method as virtual and override it, or you can do
public abstract class BaseClass : IDeepCloneable<T>
...
public abstract T DeepClone(){}
and in your DerivedClass do
public class DerivedClass : BaseClass<DerivedClass>

Understanding polymorphism in general (c# example)

I am currently in the middle of self-teaching some basic concepts of C# and I am experimenting with abstract classes and polymorphism. I thought I got the basic concept but it turned out that the concept doesn't work like I understood it :). However - I hope I get some answers which clear the dust a little bit :).
The whole task I am trying to achieve is to extend an abstract base class and use the extension with an object of the base class. Like here:
I have an abstract class which implements an abstract property like:
public abstract class BaseClass
{
public abstract MyProperty mP{get;}
}
where the property is
public abstract class MyProperty
{
public abstract string PropertyName{get;}
}
Now I am deriving the MyProperty class for an actual implementation like
public class DerivedProperty : MyProperty
{
public override string PropertyName
{
get
{
return this._name;
}
}
private _name = "Property1";
/* some other implementation follows here...... */
}
As I've understood polymorphism and inheritance it should now be possible to instantiate a derived class from BaseClass and override the property MyProperty with an object of DerivedProperty like this:
public class DerivedClass : BaseClass
{
public override DerivedProperty mP
{
get
{
return dP;
}
}
private DerivedProperty dP = new DerivedProperty();
/* more implementation follows here...... */
}
Because DerivedProperty is an object of MyProperty and DerivedProperty at the same time it is possible to use it where either MyProperty or DerivedProperty is referenced. At least that's what I thought but it seems that this is wrong.
Now I am wondering - why is polymorphism so useful when something like above is not possible? Because even when I try something like this:
public class DerivedClass : BaseClass
{
public override MyProperty mP
{
get
{
return dP as DerivedProperty;
}
}
private DerivedProperty dP = new DerivedProperty();
/* more implementation follows here...... */
}
I still get only my base object MyProperty and not my extended object DerivedProperty which I want to get.
I know why I get those results - I just don't seem logical to me :). Is it really like polymorphism is supposed to work or is my implementation just crap and I have to do it in a different way to get my extended property?
Appreciate your help here!

You have to provide the same type for overrided property. You can use it later in your abstract BaseClass. Parameters as well as return value of member have to be the same when overriding. It is usually not a problem.
I've prepared following examples that my code look similar to yours.
In some scenarios I've seen that there is added second property with more specific type and different (more specific) name:
public abstract class BaseCar
{
public abstract BaseDriver Driver { get; }
}
public abstract class BaseDriver
{
public abstract string Name { get; set; }
}
public class AgressiveDriver : BaseDriver
{
public override string Name { get; set; }
}
public class FastCar : BaseCar
{
private AgressiveDriver _agressiveDriver = new AgressiveDriver();
public override BaseDriver Driver { get { return _agressiveDriver; } }
public AgressiveDriver AgressiveDriver { get { return _agressiveDriver; } }
}
Second approach is to use generics:
public abstract class BaseCar<TDriver>
where TDriver : BaseDriver
{
public abstract TDriver Driver { get; }
}
public abstract class BaseDriver
{
public abstract string Name { get; set; }
}
public class AgressiveDriver : BaseDriver
{
public override string Name { get; set; }
}
public class FastCar : BaseCar<AgressiveDriver>
{
private AgressiveDriver _agressiveDriver = new AgressiveDriver();
public override AgressiveDriver Driver { get { return _agressiveDriver; } }
}
but I think first approach is better because there is no problem with creating/using BaseCar objects (for example to create BaseCar<> variable you have to specify type parameter). Also it makes sense to create more specific name for more specific property.

I think you have an extra bit of complexity you don't need. You have an abstract class inside an abstract class. If you are just learning/relearning this you have skipped a couple easy steps for understanding. Here's a simpler example to start with.
public abstract class Shape
{
public abstract double GetArea();
public abstract double Circumference();
}
public class Square: Shape
{
public double width {get; set;}
public override double GetArea()
{
return width * width;
}
public override Circumference()
{
return width * 4;
}
}
You can now instantiate a Square or create a Circle Class and be able to use either where you use Shape.

Can you override one of the abstract methods in a base class with another base class?

I have a base class that has some abstract methods on it and there are 21 classes that are inheriting from this base class. Now for one of those abstract methods I want to implement it with a common implementation for 6 of the 21 classes so I thought about creating another base class that would do this.
I am open to suggestions but my main purpose of creating another base class between the current base class and the 21 classes is to keep from repeating the same code in 6 of the 21 classes if I didn't have to.
Here is a sample of code to illustrate the situation:
public abstract class FooBase
{
public abstract string Bar();
public abstract string SomeMethod();
public virtual string OtherMethod()
{
return this.SomeMethod();
}
}
public abstract class AnotherBase : FooBase
{
public abstract string Bar();
public abstract string SomeMethod();
public override OtherMethod()
{
//this is the common method used by 6 of the classes
return "special string for the 6 classes";
}
}
public class Foo1 : FooBase
{
public override string Bar()
{
//do something specific for the Foo1 class here
return "Foo1 special string";
}
public override string SomeMethod()
{
//do something specific for the Foo1 class here
return "Foo1 special string";
}
}
public class Another2 : AnotherBase
{
public override string Bar()
{
//do something specific for the Another2 class here
return "Another special string";
}
public override string SomeMethod()
{
//do something specific for the Another2 class here
return "Another2 special string";
}
}

Yes, you can derive an abstract class from another abstract class
public abstract class FooBase
{
//Base class content
}
public abstract class AnotherBase : FooBase
{
//it is "optional" to make the definition of the abstract methods of the Parent class in here
}
When we say it is optional to define the abstract methods of the parent class inside of the child class, it is mandatory that the child class should be abstract.
public abstract class FooBase
{
public abstract string Bar();
public abstract string SomeMethod();
public abstract string OtherMethod();
}
public abstract class AnotherBase : FooBase
{
public override string OtherMethod()
{
//common method that you wanted to use for 6 of your classes
return "special string for the 6 classes";
}
}
//child class that inherits FooBase where none of the method is defined
public class Foo1 : FooBase
{
public override string Bar()
{
//definition
}
public override string SomeMethod()
{
//definition
}
public override string OtherMethod()
{
//definition
}
}
//child class that inherits AnotheBase that defines OtherMethod
public class Another2 : AnotherBase
{
public override string Bar()
{
//definition
}
public override string SomeMethod()
{
//definition
}
}
So I'm guessing that there will be 5 more classes like Another2 which inherits from AnotherBase that will have a common definition for OtherMethod

Yes, that is entirely possible and frequently done. There is no rule that says that you can have only one base class at the bottommost level of your class hierarchy; subclasses of that class can just as well be abstract and thereby become (somewhat more specialized) base classes for one group of classes indirectly derived from your general base class.

You should specify what exactly those classes do, but.. given the information you provided:
This is the exact problem that the Strategy pattern aims to solve, as shown in the example given in the Head First Design Patterns book.
You have an abstract Duck class, from which other ducks (e.g., RedheadDuck, MallardDuck) derive. The Duck class has a Quack method, that simply displays the string "quack" on the screen.
Now you are told to add a RubberDuck. This guy doesn't quack! So what do you do? Make Quack abstract and let the subclasses decide how to implement this? No, that'll lead to duplicated code.
Instead, you define an IQuackBehaviour interface with a Quack method. From there, you derive two classes, QuackBehaviour and SqueakBehaviour.
public class SqueakBehaviour: IQuackBehaviour
{
public void Quack(){
Console.WriteLine("squeak");
}
}
public class QuackBehaviour: IQuackBehaviour
{
public void Quack(){
Console.WriteLine("quack");
}
}
Now, you compose your ducks with this behaviour as appropriate:
public class MallardDuck : Duck
{
private IQuackBehaviour quackBehaviour = new QuackBehaviour();
public override void Quack()
{
quackBehaviour.Quack();
}
}
public class RubberDuck : Duck
{
private IQuackBehaviour quackBehaviour = new SqueakBehaviour();
public override void Quack()
{
quackBehaviour.Quack();
}
}
You can even inject an instance of IQuackBehaviour through a property if you want the ducks to change their behaviour at runtime.