We Keep Coding

How to identity which class object is being created in Helper class

I am having a abstract class which is being inherited by 2 classes. How can I find out which class is being created in my helper class.
Abstract Class
public abstract class AbstractClass
{
private IHelper helper{ get; }
public Entity()
{
helper= new MyHelper(this);
}
}
MyHelper.cs
public class MyHelper: IHelper
{
private AbstractClass ABClass{get;}
public EntityDataOperation(AbstractClass abClass)
{
//How can I find out which concrete type it is i.e. ClassA or ClassB
ABClass= abClass;
}
}
ClassA
public class ClassA:AbstractClass
{
public string data= "ClassA";
}
ClassB
public class ClassB:AbstractClass
{
public string data= "ClassB";
}

You can use Reflection but your code and methodology is very questionable:
entity.GetType().Name;
You can also test for the subclasses
if (abClass is ClassA)
// found is ClassA
else if (abClass is ClassB)
// found ClassB

It seems like your question boils down to, "If I have an object, how do I get the type of that object?"
var typeOfTheObject = theObject.GetType();
The problem is that this largely defeats the purpose of strongly typed parameters.
This tells you what you need to know about the type:
public EntityDataOperation(AbstractClass abClass)
^^^
That tells you what the type is. It's AbstractClass. If that's not what you need to know - if you don't care that it's an AbstractClass, then why not change the parameter to object?
Polymorphism literally means "multiple shapes." It means that the when you get an instance of AbstractClass, the actual object could be one of many shapes - many implementations of the class. But by taking a parameter of type AbstractClass, this method says that it doesn't care which type it is. It just interacts with the interface it knows about - the methods and properties of AbstractClass, without knowing or caring what the concrete implementation is.

Inherit from a base class and provide the inheritance type to overridden method

I have a base class with a method that can be overridden. If I inherit a class from this base class how can I make the method return the inherited type?
Like:
public class ClassA : BaseClass
{
public override ClassA TestMethod(...)
{
// ...
}
}
Do I need to provide a type manually to the base class ? Or can I make it provide that type automatically?

You could use a generic type to do it.
public class BaseClass<T> where T : BaseClass<T> {
public abstract T TestMethod(...);
}
public class ClassA : BaseClass<ClassA>
{
public override ClassA TestMethod(...)
{
// ...
}
}
Why do you need it? Might lead to better suiting answers...

The feature you want has a name; this is return type covariance.
The reasons it is not supported in C# are here:
Why C# doesn't allow inheritance of return type when implementing an Interface
The other answers are all suggesting that you use the C# version of the curiously recurring template pattern to solve your problem. My opinion is that the pattern makes more problems than it solves. See my article on that subject for more details:
http://blogs.msdn.com/b/ericlippert/archive/2011/02/03/curiouser-and-curiouser.aspx
A better way to solve this problem is to use this pattern:
abstract class Animal
{
protected abstract Animal ProtectedGetMother();
public Animal GetMother()
{
return this.ProtectedGetMother();
}
}
class Cat : Animal
{
protected override Animal ProtectedGetMother()
{
do the work particular to cats here
make sure you return a Cat
}
public new Cat GetMother()
{
return (Cat)this.ProtectedGetMother();
}
}
The problem is that you cannot override a virtual method with a different return type. So don't. Make a brand new method with a different return type and make the virtual method an implementation detail of the class hierarchy.
This technique is approximately one billion times easier to understand than this Cat : Animal<Cat> "a cat is an animal of cat" nonsense.

You can do this in a generic way:
public abstract class Base
{
public abstract T AbstractTestMethod<T>() where T : Base;
public virtual T VirtualTestMethod<T>() where T : Base, new()
{
return new T();
}
}
public class ClassA : Base
{
public override ClassA AbstractTestMethod<ClassA>()
{
return new ClassA();
}
public override ClassA VirtualTestMethod<ClassA>()
{
return new ClassA();
}
}
Using virtual methods behaves not as strict as using abstract methods. Using the abstract way you can force developers to implement the method on their own. Using the virtual way you can tell them something like "meet my constraints and feel free to use the default behaviour".

Inheritance/classes in C#

I am new to C#, and are trying to understand classes and "is a" relationships. I've been trying to get a piece of code to work, but I can't seem to get it right.
It looks like this: http://pastebin.com/cQDusptB
I have a base class, Mammal, which one should be able to create instances of, giving the name of the mammal as input.
I also have a class, Dog, which is a Mammal. One should be able to create an instance of this too, in the same manner as Mammal.
Can anyone see my flaw(s)? If yes, can you please explain what i misunderstood/forgot?

When posting questions like this it is helpful to also post the error message the compiler gave you.
Can anyone see my flaw(s)?
You have a virtual constructor.
can you please explain what i misunderstood/forgot?
Constructors are not inherited in C# and therefore it makes no sense to mark them as either virtual or override.

The constructor of Dog needs to be named "Dog". You can't/don't need to override "Mammal". Also, Mammal's constructor shouldn't be virtual.
public class Mammal
{
public Mammal(string name)
{
//....
}
}
public class Dog : Mammal {
public Dog(string name) : base(name)
{
}
}
You pass arguments to the base class constructor using the "base" keyword (see code above).
Be sure to pick up a good book on C# to get the language basics right.

You have a few issues here. For one, constructors can not be marked as virtual or overridden. Another problem is that you attempt to call the method .Name without parentheses. The corrected version looks like this:
public class Mammal
{
protected string _Name;
public virtual string Name()
{
return (this._Name + " - of type " + this.GetType());
}
public Mammal(string Name)
{
this._Name = Name;
}
}
public class Dog : Mammal
{
public Dog(string Name) : base(Name)
{
}
public override string Name()
{
return (base._Name + "Dog");
}
}
static void Main()
{
Mammal AnimalA = new Mammal("SubjectA");
Console.WriteLine("{0}", AnimalA.Name());
Mammal AnimalB = new Dog("SubjectB");
Console.WriteLine("{0}", AnimalB.Name());
Console.ReadLine();
}

Constructors are not inherited/overridden.
Lose the 'virtual' keyword from the Mammal constructor in the Mammal class.
Remove the Mammal ctor override attempt in the Dog class.
Replace it with a Dog constructor that calls the Mammal one (like this):
public Dog(string name) : base(name)
{
}
Now when a dog is constructed it will call through to the mammal base class constructor passing the specified name.

c# covariant return types utilizing generics

Is the code below the only way to implement covariant return types?
public abstract class BaseApplication<T> {
public T Employee{ get; set; }
}
public class Application : BaseApplication<ExistingEmployee> {}
public class NewApplication : BaseApplication<NewEmployee> {}
I want to be able to construct an Application or a NewApplication and have it return the appropriate Employee type from the Employee property.
var app = new Application();
var employee = app.Employee; // this should be of type ExistingEmployee
I believe this code works fine, but it gets really nasty when I have several properties that require the same behavior.
Are there any other ways to implement this behavior? Generics or otherwise?

UPDATE: This answer was written in 2010. After two decades of people proposing return type covariance for C#, it looks like it will finally be implemented; I am rather surprised. See the bottom of https://devblogs.microsoft.com/dotnet/welcome-to-c-9-0/ for the announcement; I'm sure details will follow. The portions of the answer below which speculate on the possibility of the feature being implemented should be considered of historical interest only going forwards.
First off, the answer to your question is no, C# does not support any form of return type covariance on virtual overrides.
A number of answerers and commenters have said "there is no covariance in this question". This is incorrect; the original poster was entirely correct to pose the question as they did.
Recall that a covariant mapping is a mapping which preserves the existence and direction of some other relation. For example, the mapping from a type T to a type IEnumerable<T> is covariant because it preserves the assignment compatibility relation. If Tiger is assignment compatible with Animal, then the transformation under the map is also preserved: IEnumerable<Tiger> is assignment compatible with IEnumerable<Animal>.
The covariant mapping here is a little bit harder to see, but it is still there. The question essentially is this: should this be legal?
class B
{
public virtual Animal M() {...}
}
class D : B
{
public override Tiger M() {...}
}
Tiger is assignment-compatible with Animal. Now make a mapping from a type T to a method "public T M()". Does that mapping preserve compatibility? That is, if Tiger is compatible with Animal for the purposes of assignment, then is public Tiger M() compatible with public Animal M() for the purposes of virtual overriding?
The answer in C# is "no". C# does not support this kind of covariance.
Now that we have established that the question has been asked using the correct type algebra jargon, a few more thoughts on the actual question. The obvious first problem is that the property has not even been declared as virtual, so questions of virtual compatibilty are moot. The obvious second problem is that a "get; set;" property could not be covariant even if C# did support return type covariance because the type of a property with a setter is not just its return type, it is also its formal parameter type. You need contravariance on formal parameter types to achieve type safety. If we allowed return type covariance on properties with setters then you'd have:
class B
{
public virtual Animal Animal{ get; set;}
}
class D : B
{
public override Tiger Animal { ... }
}
B b = new D();
b.Animal = new Giraffe();
and hey, we just passed a Giraffe to a setter that is expecting a Tiger. If we supported this feature we would have to restrict it to return types (as we do with assignment-compatibility covariance on generic interfaces.)
The third problem is that the CLR does not support this kind of variance; if we wanted to support it in the language (as I believe managed C++ does) then we would have to do some reasonably heroic measures to work around signature matching restrictions in the CLR.
You can do those heroic measures yourself by carefully defining "new" methods that have the appropriate return types that shadow their base class types:
abstract class B
{
protected abstract Animal ProtectedM();
public Animal Animal { get { return this.ProtectedM(); } }
}
class D : B
{
protected override Animal ProtectedM() { return new Tiger(); }
public new Tiger Animal { get { return (Tiger)this.ProtectedM(); } }
}
Now if you have an instance of D, you see the Tiger-typed property. If you cast it to B then you see the Animal-typed property. In either case, you still get the virtual behaviour via the protected member.
In short, we have no plans to ever do this feature, sorry.

There might be multiple problems with what you try to achieve.
First of all, as somebody already noticed, there is no covarianace in your example. You can find a short description of covariance and generics here, new features in C# 2.0 - Variance, covariance on generics.
Secondly it seems that you try to solve with generics what should be solved with polymorphism. If both ExistingEmployee and NewEmployee inherit from a base class Employee, your problem would be solved:
public class Application {
public ExistingEmployee Employee { get; }
}
public class NewApplication {
public NewEmployee Employee { get; }
}
...
Application app = new Application;
var emp = app.Employee; // this will be of type ExistingEmployee!
Please note that the below is also true:
Employee emp = app.Employee; // this will be of type ExistingEmployee even if
// declared as Employee because of polymorphism
The one thing that would be different between polymorphism and generics, would be that if you return the variable to the specific type you would need a cast in the later case:
ExistingEmployee emp = (ExistingEmployee)app.Employee; // would have not been needed
// if working with generics
Hope this helps.

You could code against an Employee Interface to get what you want I think.
public interface IEmployee
{}
public abstract class BaseApplication<T> where T:IEmployee{
public T IEmployee{ get; set; }
}
public class ExistingEmployee : IEmployee {}
public class NewEmployee : IEmployee {}
public class Application : BaseApplication<ExistingEmployee> {}
public class NewApplication : BaseApplication<NewEmployee> {}

The code you posted will not compile but I get the basic idea of what you want to do. In short the answer is yes, that is the only way. If you want a property to return different types and be typed differently in extended classes then you have to use generics in the way that you already are.
If you can encapsulate the public contract of an employee object, new or existing, into an interface then you don't need to use generics at all. Instead you can just return the interface and let polymorphism take over.
public interface IEmployee
{ }
public class Employee1 : IEmployee
{ }
public class Employee2 : IEmployee
{ }
public abstract class ApplicationBase
{
public abstract IEmployee Employee { get; set; }
}
public class App1 : ApplicationBase
{
public override IEmployee Employee
{
get { return new Employee1(); }
set;
}
}
public class App2 : ApplicationBase
{
public override IEmployee Employee
{
get { return new Employee2(); }
set;
}
}

You can achieve a somewhat neat looking version of this using generics.
Covariant return types are not supported by c#. So this is not a solution, however, my feeling is that syntactically speaking this reads well. It does achieve a similar result.
I find it useful when creating fluent API's where the base class needs to perform some actions, but I need the derived implementation back. All it really achieves is to hide the cast.
public class Base
{
public virtual T Foo<T>() where T : Base
{
//... // do stuff
return (T)this;
}
}
public class A : Base
{
public A Bar() { "Bar".Dump(); return this; }
public A Baz() { "Baz".Dump(); return this; }
// optionally override the base...
public override T Foo<T>() { "Foo".Dump(); return base.Foo<T>(); }
}
var x = new A()
.Bar()
.Foo<A>() // cast back to A
.Baz();
Opinions will vary, and it's not 100% pretty. It's probably not appropriate for an API that will be published, but for internal use, for instance in unit tests, I find it useful.

YES!! Like this. There is more boiler plate than you would hope for, but it does work. The trick is done with extension methods.
It dose some nasty casting internally, but presents a covariant interface.
See also: http://richarddelorenzi.wordpress.com/2011/03/25/return-type-co-variance-in-c/
using System;
namespace return_type_covariance
{
public interface A1{}
public class A2 : A1{}
public class A3 : A1{}
public interface B1
{
A1 theA();
}
public class B2 : B1
{
public A1 theA()
{
return new A2();
}
}
public static class B2_ReturnTypeCovariance
{
public static A2 theA_safe(this B2 b)
{
return b.theA() as A2;
}
}
public class B3 : B1
{
public A1 theA()
{
return new A3();
}
}
public static class B3_ReturnTypeCovariance
{
public static A3 theA_safe(this B3 b)
{
return b.theA() as A3;
}
}
public class C2
{
public void doSomething(A2 a){}
}
class MainClass
{
public static void Main (string[] args)
{
var c2 = new C2();
var b2 = new B2();
var a2=b2.theA_safe();
c2.doSomething(a2);
}
}
}

One idea without generics, but it has other downsides:
public abstract class BaseApplication {
public Employee Employee{ get; protected set; }
}
public class Application : BaseApplication
{
public new ExistingEmployee Employee{ get{return (ExistingEmployee)base.Employee;} set{base.Employee=value; }}
}
public class NewApplication : BaseApplication
{
public new NewEmployee Employee{ get{return (NewEmployee)base.Employee;} set{base.Employee=value; }}
}
In particular with this code you can cast to the base class and assign an employee of an undesirable type. So you need to add checks against that in the setter of the base-class. Or remove the setter, which I usually prefer anyways. one way to do that is making the setter protected.
Another is adding a virtual function EmployeeType() which you override in derived classes and return a derived type. Then you check in the setter if EmployeeType().IsInstanceOf(value) and else throw an exception.
And IMO simulating covariant return types is one of the few good applications of the new marker. It returns the same thing as the base-class and just adds additional guarantees to the function contract.

generic inheritance in C#? [duplicate]

This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Why cannot C# generics derive from one of the generic type parameters like they can in C++ templates?
I can do
public class MyGenericClass : DL
//but i cannot do
public class MyGenericClass <T> : T
How would i do the second? if i cannot do that, how can i do something like
public class MyGenericClass <T>
{
T obj;
//have all MyGenericClass.XYZ call obj.XYZ
}

This is not possible, because depending on what type T is, the public interface of MyGenericClass would change.
If you have lots of different classes that all expose the same interface, you could declare MyGenericClass to expose that interface, and in the implementation of all of the functions delegate the calls to obj

The specific question, why can't you do this:
public class MyGenericClass<T> : T
And you can do this:
public class MyGenericClass<T>
{
T obj;
}
The reason is that the CLR likes to be able to compile a single version of the code for MyGenericClass that will work for any reference type specified for T.
It can do this for the second case, because it can quietly replace T with object and insert appropriate casts, roughly equivalent to:
public class MyGenericClass
{
object obj;
}
But for the inheritance version, that trick doesn't work.
Also, many useful facilities would be impossible to describe through interface constraints. When you inherit from a type, you can do a lot more than just call methods on it - you can override them as well. Consider this hypothetical example:
class MyBase
{
public virtual void MyVirtual() { }
}
class MyGenericDerived<T> : T
{
public override void MyVirtual()
{
Console.WriteLine("Overridden!");
}
}
MyBase obj = new MyGenericDerived<MyBase>();
obj.MyVirtual();
What I want to do there is something like a "mix-in", where MyGenericDerived supplies definitions for virtual functions in whatever base it is applied to. But how does the compiler know that T will have a method called MyVirtual that can be overridden? I'd need to put a constraint on T. How would I express that through interfaces? It's impossible. Using interfaces to describe constraints isn't an adequate solution once you allow inheritance from type parameters. So that's another reason why it doesn't exist in the language today.

You could do something like
public interface IXyzable { void xyz(); }
public class MyGenericClass<T> : IXyzable where T : IXyzable {
T obj;
public void xyz() {
obj.xyz();
}
}
Edit: Now I understand the question

You'll need all your possible T's to implement some interface so that you know that obj.XYZ() makes sense, then you can do
public interface Ixyz
{
void XYZ();
}
public class MyGenericClass<T> : Ixyz where T:Ixyz, new()
{
T obj;
public MyGenericClass()
{
obj = new T();
}
public void XYZ()
{
obj.XYZ();
}
}
I've made MyGenericClass implement Ixyz too since it obviously does expose the right method, but maybe that's best left out since it allows
var x = new MyGenericClass<MyGenericClass<SomeClass>>();
which is unlikely to ever be a good idea.

This is pretty much duck-typing, but you could use reflection.
When you create the generic class with a reference to the obj, use reflection to try and find a method with the right signature. As long as you store a reference to the method, performance won't be too bad.
class BaseGeneric<T>
{
private T obj;
private MethodInfo mi;
private const string MethodNameOfInterest = "Xyz";
public BaseGeneric(T theObject)
{
this.obj = theObject;
Type t = obj.GetType();
mi = t.GetMethod(MethodNameOfInterest);
}
public void Xyz()
{
mi.Invoke(obj, null);
}
}
Of course, you would need to add a lot more for error checking and such, but that is the gist of what you could do. Also, don't forget to add the System.Reflection namespace to your using clause.

The .NET type system won't allow type declarations of the form you're attempting. One reason why this is disallowed should be intuitive: how would MyGenericClass<T> act when T is a sealed class (e.g. System.String)?
If you absolutely need this functionality (and you know that the type T you'll be using isn't sealed), you can generate proxies at runtime using the classes in the Reflection.Emit namespace. It may also be possible to achieve this effect using AOP tools like PostSharp.

What about this:
class BaseClass<T>
{
public T property { get; set; }
}
class GenericClass<T> : BaseClass<T>
{
}
class Program
{
static void Main(string[] args)
{
GenericClass<int> l = new GenericClass<int>();
l.property = 10;
}
}
This achieves what you want to do?