Is short:
How come that adding a derived type to collection passes but when trying to add a generic of the derived type it fails?
The "short" code:
//a generic repository
public class EfRepository<T> : IRepository<T> where T: BaseCatalogModel{...}
public CatalogRepository(IRepository<Product> productRepository, IRepository<Category> categoryRepository)
{
//This passes
Dictionary<int, BaseCatalogModel> dic1 = new Dictionary<int, BaseCatalogModel>();
dic1.Add(1, new Product());
dic1.Add(2, new Category());
dic1.Add(3, new BaseCatalogModel());
//This not.
//The error: cannot convert from 'YoYo.Core.Data.Repositories.EfRepository<YoYo.Commerce.Common.Domain.Catalog.Product>'
//to 'YoYo.Core.Data.Repositories.EfRepository<YoYo.Commerce.Common.Domain.Catalog.BaseCatalogModel>'
Dictionary<int, EfRepository<BaseCatalogModel>> dic2 = new Dictionary<int, EfRepository<BaseCatalogModel>>();
dic2.Add(1, new EfRepository<Product>());
dic2.Add(2, new EfRepository<Category>());
}
The long deal:
Working on an on-line store, I would like to hold in a catalog repository a collection of all repositories relevant to managing the catalog.
The idea is to manage the entire catalog from one repository.
The repositories collection is of type Dictionary)
I fail to add any BaseCatalogModel derived type repository to the collection.
I will be happy to get any assistance on the above or suggestions for better implementations.
public class BaseCatalogModel
{
public int Id { get; set; }
...
}
public class Category:BaseCatalogModel
{
...
}
public class Product : BaseCatalogModel
{
...
}
public class CatalogRepository : ICatalogRepository
{
private readonly Dictionary<Type, IRepository<BaseEntity>> _repositoriesCollection= new Dictionary<Type, IRepository<BaseEntity>>();
public CatalogRepository(IRepository<Product> productRepository, IRepository<Category> categoryRepository)
{
_repositoriesCollection.Add(typeof(Category), categoryRepository); //==> this fails
_repositoriesCollection.Add(typeof(Product), productRepository); //==> this fails
}
public T GetCatalogItem<T>(int id) where T : BaseCatalogModel
{
//returns a catalog item using type and id
}
public IEnumerable<T> GetCatalogItem<T>() where T : BaseCatalogModel
{
//returns the entire collection of catalog item
}
}
So this is a fairly common problem with generics.
imagine 2 classes class Base and class A. class A descends from Base.
public class Base { }
public class A : Base { }
Now consider List<T>. You can make classes from List<T> to hold Base or A:
List<Base> x = new List<Base>();
and
List<A> y = new List<A>();
It is a common misconception that the class of y must be a descendant of the class of x, but this cannot be true because x has a methods like Add(Base item) and y has a methods like Add(A item) and it is not possible for the compiler to guarantee that on y the interface will be compatible with the interface of x. this is because if you treat an instance of List<A> as an instance of List<Base> there is nothing to stop Add being called with an instance of Base or another subclass of Base.
Now there are some parts of the interface that can be guarantee as compatible. They are any parts that return an instance of class A, since A can always take the place of Base.
If your interface only output the generic and you are using .net 4 there is an easy solution. The out generic modifier:
public class Example
{
private readonly Dictionary<Type, IRepository<Base>> _repositoriesCollection =
new Dictionary<Type, IRepository<Base>>();
public void DoSomething()
{
_repositoriesCollection.Add(typeof(A), new Repository<A>());
}
}
interface IRepository<out T> where T : Base
{
T MakeSomeItem(string info);
//void AddSomeItem(string info, T itemToAdd); <- this will not
// work because T
// is out - so can't
// go in...
IEnumerable<T> MakeSomeListOfItems(); // This is OK because
// IEnumerable<T> is declared as IEnumerable<out T> in the fx
//List<T> Something(); <- not ok because List<T> is not List<out T>
}
public class Repository<T> : IRepository<T> where T : Base
{
public T MakeSomeItem(string info)
{
throw new NotImplementedException();
}
public IEnumerable<T> MakeSomeListOfItems()
{
throw new NotImplementedException();
}
}
public class Base { }
public class A : Base { }
This solution will not work for 2 cases; when you need to pass an item into you interface and when you are not using .net 4.
There are numerous different solutions for both of those case also.
1) I need to pass an item into the interface too and I am using .net 4 - just pass it as Base, if you need to maintain type safety wrap it with a generic method somewhere else.
interface IRepository<out T> where T : Base
{
T MakeSomeItem(string info);
void AddSomeItem(string info, Base itemToAdd);
}
public class Repository<T> : IRepository<T> where T : Base
{
public T MakeSomeItem(string info){ throw new NotImplementedException(); }
public void AddSomeItem(string info, Base itemToAdd)
{
T castedItem = (T) itemToAdd; //fails here at
//run time if not
// correct type
AddSomeItem(info, itemToAdd);
}
public void AddSomeItem(string info, T itemToAdd)
{
/// do it for real...
}
}
2) If you are not working with .net 4 then there are other things that you can do too, force the repository to implement the Base version of your interface:
interface IRepository<T> where T : Base
{
T MakeSomeItem(string info);
void AddSomeItem(string info, T itemToAdd)
}
public class Repository<T> : IRepository<Base>, IRepository<T> where T : Base
{
public T MakeSomeItem(string info) { throw new NotImplementedException(); }
public void AddSomeItem(string info, Base itemToAdd)
{
T castedItem = (T) itemToAdd; //fails here at
//run time if not
// correct type
AddSomeItem(info, itemToAdd);
}
public void AddSomeItem(string info, T itemToAdd)
{
/// do it for real...
}
Base IRepository<Base>.MakeSomeItem(string info)
{
return MakeSomeItem(info);
}
}
There is still yet more that you can do if you want to keep your input strongly typed - but I think my answer is long enough for now.
Related
i need to help with solving Covariant situation in my Code.
Let me show the situation on example:
abstract class BaseSource { }
abstract class BaseTarget { }
class SourceEntityA : BaseSource { }
class TargetEntityB : BaseTarget { }
interface IEntityMapper { }
interface IEntityMapper<in TSource, out TTarget>: IEntityMapper
{
TTarget Map(TSource entity);
}
abstract class BaseEntityMap<TSource, TTarget> : IEntityMapper<TSource, TTarget>, IEntityMapper
{
public abstract TTarget Map(TSource entity);
}
class OrderEntityMapper : BaseEntityMap<SourceEntityA, TargetEntityB>
{
public override TargetEntityB Map(SourceEntityA entity)
{
//do some map stuff
return null;
}
}
class GoodsEntityMapper : BaseEntityMap<SourceEntityC, TargetEntityD>
{
public override TargetEntityD Map(SourceEntityC entity)
{
//do some map stuff
return null;
}
}
class Workflow
{
IDictionary<Type, IEntityMapper> MappersMap = new Dictionary<Type, IEntityMapper>();
public MappingArchestrator()
{
MappersMap.Add(typeof(SourceEntityA), new OrderEntityMapper());
MappersMap.Add(typeof(SourceEntityC), new GoodsEntityMapper());
//....more mappers
}
private IEnumerable<BaseSource> GetSourceEntities()
{
//return source data
return null;
}
public void Execute()
{
foreach (var m in MappersMap.Keys)
{
var mapper = MappersMap[m];
var entities = GetSourceEntities();
foreach (var entity in entities)
{
//Need to handle this situations with correct covariations.
var target = (IEntityMapper<BaseSource, BaseTarget>mapper).Map(entity);
//.... code continues
}
}
}
}
Shortly i need Dictionary of different types of mappers and use them Execute method in common code to handle workflow.
Could you guide me to a better code or fix an existing solution? Is it even possible?
Or i have to forget generics here and use BaseClasses in Map method and cast them to type what i need.
Something like this
abstract class BaseEntityMap : IEntityMapper
{
public abstract BaseTarget Map(BaseSource entity);
}
Thank you
You can apply generic constraints in BaseEntityMap<TSource, TTarget> class to your BaseSource and BaseTarget classes (or apply constraints in IEntityMapper<in TSource, out TTarget> interface and get rid of base abstract class)
abstract class BaseEntityMap<TSource, TTarget> : IEntityMapper<TSource, TTarget>
where TSource : BaseSource
where TTarget : BaseTarget
{
public abstract TTarget Map(TSource entity);
}
Then declare mappers dictionary like below, using Func<BaseSource, BaseTarget> delegate. It should be fine, since you've constrained your BaseEntityMap<TSource, TTarget> and Func<in T, out TResult> declaration supports contravariance for the input parameter and covariance for the result
IDictionary<Type, Func<BaseSource, BaseTarget>> MappersMap = new Dictionary<Type, Func<BaseSource, BaseTarget>>();
public Workflow()
{
var orderMapper = new OrderEntityMapper();
MappersMap.Add(typeof(SourceEntityA), source => orderMapper.Map((SourceEntityA)source));
var goodsMapper = new GoodsEntityMapper();
MappersMap.Add(typeof(SourceEntityC), source => goodsMapper.Map((SourceEntityC)source));
//....more mappers
}
The usage example
foreach (var entity in entities)
{
var target = mapper(entity);
//.... code continues
}
I have the following classes
public abstract class BaseViewPresenter { }
public abstract class BaseView<T> : UserControl
where T : BaseViewPresenter { }
public class LoginPresenter : BaseViewPresenter { }
public partial class LoginView : BaseView<LoginPresenter> { }
I have a method that looks like this (simplified)
public BaseView<BaseViewPresenter> Resolve(BaseViewPresenter model)
{
var type = model.GetType();
var viewType = _dataTemplates[type];
// Correctly creates BaseView object
var control = Activator.CreateInstance(viewType);
// Fails to cast as BaseView<BaseViewPresenter> so returns null
return control as BaseView<BaseViewPresenter>;
}
When I call this using an instances of LoginPresenter
var login = new LoginPresenter();
var ctl = Resolve(login);
The line Activator.CreateInstance(viewType) correctly resolves into a new instances of my LoginView, however control as BaseView<BaseViewPresenter> can't do the cast correctly so returns null.
Is there a way to correctly cast the control into BaseView<BaseViewPresenter> without using specific type generics?
Since LoginView inherits from BaseView<LoginPresenter>, and LoginPresenter inherits from BaseViewPresenter, I would assume there's a way to convert LoginView to BaseView<BaseViewPresenter>.
I am stuck with using .Net 3.5
This is a very frequently asked question. Let's rename your types:
abstract class Fruit { } // was BaseViewPresenter
abstract class FruitBowl<T> where T : Fruit // was BaseView
class Apple : Fruit { } // was LoginPresenter
class BowlOfApples : FruitBowl<Apple> { } // was LoginView
Your question now is:
I have a BowlOfApples, which inherits from FruitBowl<Apple>. Why can I not use it as a FruitBowl<Fruit>? An apple is a fruit, so a bowl of apples is a bowl of fruit.
No, it isn't. You can put a banana in a bowl of fruit, but you can't put a banana in a bowl of apples, and therefore a bowl of apples is not a bowl of fruit. (And by similar argument, a bowl of fruit is not a bowl of apples either.) Since the operations you can legally perform on the two types are different, they cannot be compatible.
Here is a photo of StackOverflow legend Jon Skeet demonstrating this fact:
The feature you want is called generic contravariance, and it is supported only on interfaces and delegate types when the compiler can prove that the variance is safe, and when the varying type is a reference type. For example, you can use an IEnumerable<Apple> in a context where IEnumerable<Fruit> is needed because the compiler can verify that there is no way that you can put a Banana into a sequence of fruit.
Do a search on "C# covariance and contravariance" on this site or on the web and you'll find many more details about how this feature works. In particular, my series of articles on how we designed and implemented this feature in C# 4 starts here: http://blogs.msdn.com/b/ericlippert/archive/2007/10/16/covariance-and-contravariance-in-c-part-one.aspx
I accepted Eric's answer since it provides a great explanation of why what I wanted wasn't possible, but I also thought I'd share my solution in case anyone else runs into this same problem.
I removed the generic type parameter from my original BaseView class, and created a 2nd version of the BaseView class that included the generic type parameter and specifics for it.
The first version is used by my .Resolve() method or other code that doesn't care about the specific types, and the second version is used by any code that does care, such as the implentation of a BaseView
Here's an example of how my code ended up looking
// base classes
public abstract class BaseViewPresenter { }
public abstract class BaseView : UserControl
{
public BaseViewPresenter Presenter { get; set; }
}
public abstract class BaseView<T> : BaseView
where T : BaseViewPresenter
{
public new T Presenter
{
get { return base.Presenter as T; }
set { base.Presenter = value; }
}
}
// specific classes
public class LoginPresenter : BaseViewPresenter { }
public partial class LoginView : BaseView<LoginPresenter>
{
// Can now call things like Presenter.LoginPresenterMethod()
}
// updated .Resolve method used for obtaining UI object
public BaseView Resolve(BaseViewPresenter presenter)
{
var type = model.GetType();
var viewType = _dataTemplates[type];
BaseView view = Activator.CreateInstance(viewType) as BaseView;
view.Presenter = presenter;
return view;
}
You're expecting to treat the type as being covariant with respect to the generic argument. Classes can never be covariant; you'd need to use an interface rather than (or in addition to) an abstract class to make it covariant with respect to T. You'd also need to be using C# 4.0.
My usual solution to this problem is to create an intermediary class that has access to the type-parametric class's methods through delegates. Fields can also be accessed through getters/setters.
The general pattern goes:
public abstract class Super {}
public abstract class MyAbstractType<T> where T : Super {
public MyGeneralType AsGeneralType() {
return MyGeneralType.Create(this);
}
// Depending on the context, an implicit cast operator might make things
// look nicer, though it might be too subtle to some tastes.
public static implicit operator MyGeneralType(MyAbstractType<T> t) {
return MyGeneralType.Create(t);
}
public int field;
public void MyMethod1() {}
public void MyMethod2(int argument) {}
public abstract bool MyMethod3(string argument);
}
public delegate T Getter<T>();
public delegate void Setter<T>(T value);
public delegate void MyMethod1Del();
public delegate void MyMethod2Del(int argument);
public delegate bool MyMethod3Del(string argument);
public class MyGeneralType {
public Getter<int> FieldGetter;
public Setter<int> FieldSetter;
public MyMethod1Del MyMethod1;
public MyMethod2Del MyMethod2;
public MyMethod3Del MyMethod3;
public static MyGeneralType Create<T>(MyAbstractType<T> t) where T : Super {
var g = new MyGeneralType();
g.FieldGetter = delegate { return t.field; };
g.FieldSetter = value => { t.field = value; };
g.MyMethod1 = t.MyMethod1;
g.MyMethod2 = t.MyMethod2;
g.MyMethod3 = t.MyMethod3;
return g;
}
public int field {
get { return FieldGetter(); }
set { FieldSetter(value); }
}
}
The above exemplifies getting all the methods and fields but normally I only need a few of them. This is a general solution to the problem and one could feasibly write a tool to generate these intermediary classes automatically, which I might at some point.
Try it here: https://dotnetfiddle.net/tLkmgR
Note that this is enough for all my cases, but you can be extra hacky with this:
public abstract class MyAbstractType<T> where T : Super {
// ... Same everything else ...
// data fields must become abstract getters/setters, unfortunate
public abstract int field {
get;
set;
}
public static implicit operator MyAbstractType<Super>(MyAbstractType<T> t) {
return MyGeneralType.Create(t);
}
}
public class MyGeneralType : MyAbstractType<Super> {
// ... same constructors and setter/getter
// fields but only keep method fields
// that contain the method references for
// implementations of abstract classes,
// and rename them not to clash with the
// actual method names ...
public MyMethod3Del myMethod3Ref;
// Implement abstract methods by calling the corresponding
// method references.
public override bool MyMethod3(string argument) {
return myMethod3Ref(argument);
}
// Same getters/setters but with override keyword
public override int field {
get { return FieldGetter(); }
set { FieldSetter(value); }
}
}
And there you go, now you can literally cast a MyAbstractType<Sub> where Sub : Super to a MyAbstractType<Super>, although it's no longer the same object anymore, but it does retain the same methods and data, it's sort of a complex pointer.
public class Sub : Super {}
public class MySubType : MyAbstractType<Sub> {
public int _field;
public override int field {
get { return _field; }
set { _field = value; }
}
public override bool MyMethod3(string argument) {
Console.WriteLine("hello " + argument);
return argument == "world";
}
}
public class MainClass {
public static void Main() {
MyAbstractType<Sub> sub = new MyAbstractType<Sub>();
MyAbstractType<Super> super = sub;
super.MyMethod3("hello"); // calls sub.MyMethod3();
super.field = 10; // sets sub.field
}
}
This isn't as good in my opinion, the other version of MyGeneralType is a more straighforward layer over the concrete types, plus it doesn't require rewriting the data fields, but it does actually answer the question, technically. Try it here: https://dotnetfiddle.net/S3r3ke
Example
Using these abstract classes:
public abstract class Animal {
public string name;
public Animal(string name) {
this.name = name;
}
public abstract string Sound();
}
public abstract class AnimalHouse<T> where T : Animal {
List<T> animals;
public AnimalHouse(T[] animals) {
this.animals = animals.ToList();
}
public static implicit operator GeneralAnimalHouse(AnimalHouse<T> house) {
return GeneralAnimalHouse.Create(house);
}
public List<string> HouseSounds() {
return animals.Select(animal => animal.Sound()).ToList();
}
}
We make this "general" variant:
public delegate List<string> HouseSoundsDel();
public class GeneralAnimalHouse {
public HouseSoundsDel HouseSounds;
public static GeneralAnimalHouse Create<T>(AnimalHouse<T> house) where T : Animal {
var general = new GeneralAnimalHouse();
general.HouseSounds = house.HouseSounds;
return general;
}
}
And finally with these inheritors:
public class Dog : Animal {
public Dog(string name) : base(name) {}
public override string Sound() {
return name + ": woof";
}
}
public class Cat : Animal {
public Cat(string name) : base(name) {}
public override string Sound() {
return name + ": meow";
}
}
public class DogHouse : AnimalHouse<Dog> {
public DogHouse(params Dog[] dogs) : base(dogs) {}
}
public class CatHouse : AnimalHouse<Cat> {
public CatHouse(params Cat[] cats) : base(cats) {}
}
We use it like this:
public class AnimalCity {
List<GeneralAnimalHouse> houses;
public AnimalCity(params GeneralAnimalHouse[] houses) {
this.houses = houses.ToList();
}
public List<string> CitySounds() {
var random = new Random();
return houses.SelectMany(house => house.HouseSounds())
.OrderBy(x => random.Next())
.ToList();
}
}
public class MainClass {
public static void Main() {
var fluffy = new Cat("Fluffy");
var miu = new Cat("Miu");
var snuffles = new Cat("Snuffles");
var snoopy = new Dog("Snoopy");
var marley = new Dog("Marley");
var megan = new Dog("Megan");
var catHouse = new CatHouse(fluffy, miu, snuffles);
var dogHouse = new DogHouse(snoopy, marley, megan);
var animalCity = new AnimalCity(catHouse, dogHouse);
foreach (var sound in animalCity.CitySounds()) {
Console.WriteLine(sound);
}
}
}
Output:
Miu: meow
Snoopy: woof
Snuffles: meow
Fluffy: meow
Marley: woof
Megan: woof
Notes:
I added names so it's clear that the method references carry their owner's data with them, for those unfamiliar with delegates.
The required using statements for this code are System, System.Collections.Generic, and System.Linq.
You can try it here: https://dotnetfiddle.net/6qkHL3#
A version that makes GeneralAnimalHouse a subclass of AnimalHouse<Animal> can be found here: https://dotnetfiddle.net/XS0ljg
I want a base class method to return the type of the derived class.
according to Can a Base Class Method return the type of the derived class?
base class
public class BaseClass<T>
{
}
extension
public static class ExtensionMethods
{
public static U Project<U, T>(this U node)
where U : BaseClass<T>
{
// do something
return node;
}
}
child class
public class ChildClass: BaseClass<string>
{
}
usage
var child= new ChildClass();
var projected = child.Project(); // error: can't infer type T
var projected = child.Project<ChildClass, string>(); // ok
Question:
One solution is How to return a derived class using only code in the base class?, but class inherit from child class won't work.
How can I use method without specifying T?
The answer is that you need to provide all the piping to clone objects manually and let the compiler decide the correct overload.
public interface ICSGNode<T> where T:ICSGNode<T>
{
T Clone();
void Invert();
}
public class NodeList<T> : Collection<T>
where T : ICSGNode<T>
{
public NodeList(params T[] items) : base(items) { }
public static implicit operator NodeList<T>(T[] array) { return new NodeList<T>(array); }
public T[] Clone() { return this.Select((n) => n.Clone()).ToArray(); }
}
public class PolygonNode : ICSGNode<PolygonNode>, ICloneable
{
public PolygonNode()
{
// create a unique object
}
public PolygonNode(PolygonNode other)
{
// create a copy
}
public void Invert()
{
throw new NotImplementedException();
}
public PolygonNode Clone() { return new PolygonNode(this); }
object ICloneable.Clone() { return Clone(); }
}
public class PolygonList : NodeList<PolygonNode>, ICloneable
{
public PolygonList(params PolygonNode[] items) : base(items) { }
public static implicit operator PolygonList(PolygonNode[] array) { return new PolygonList(array); }
public new PolygonList Clone() { return new PolygonList(base.Clone()); }
object ICloneable.Clone() { return Clone(); }
}
class Program
{
static void Main(string[] args)
{
var list = new PolygonList
{
new PolygonNode(),
new PolygonNode(),
new PolygonNode(),
};
var clone = list.Clone();
// clone is of `PolygonList` type
}
}
Tricks Used:
Apply the ICloneable interface to the derived classes only.
Overwrite the default behavior of returning object with a strongly typed Clone() method.
Implement copy constructors that copy objects properties within the constructor only.
Lastly avoid returning a concrete or generic collection type from any base Clone() method. Return an array and let the derived class assembly the strongly typed clone from the array of items.
I have this class working as my repository:
public class Repository<T> where T : class, new()
{
public T GetByID(int id)
{
//Code...
}
}
But there a few cases where I don't want to leave a class' default public constructor (such as some specific model properties that require some logic), like this:
public class Person
{
public CPersonID PersonID { get; private set; }
//This shouldn't exist outside Person, and only Person knows the rules how to handle this
public class CPersonID
{
internal CPersonID() { }
}
}
This makes the Repository template class invalid because of the new() constraint.
I'd like to make something like this:
public class Repository<T> where T : class
{
//This function should be created only when the T has new()
public GetByID(int id) where T : new()
{
}
//And this could be the alternative if it doesn't have new()
public GetByID(T element, int id)
{
}
}
Is there any way I can accomplish this?
Edit: Example of a Get method:
public IList<T> GetAll()
{
IList<T> list = new List<T>();
using(IConnection cn = ConnectionFactory.GetConnection())
{
ICommand cm = cn.GetCommand();
cm.CommandText = "Query";
using (IDataReader dr = cm.ExecuteReader())
{
while(dr.Read())
{
T obj = new T(); //because of this line the class won't compile if I don't have the new() constraint
//a mapping function I made to fill it's properties
LoadObj(obj, dr);
list.Add(obj);
}
}
}
return list;
}
As Lasse V. Karlsen already answered, this is not directly possible. However, you can get very close, close enough for practical purposes.
Given public class Repository<T> where T : class, you cannot define instance methods that only exist when T has a parameterless constructor. You don't need that. You just need repository.GetByID(3) to work. That can work if GetByID is an instance method, but also if it is an extension method, and extension methods can add requirements to T.
public static class RepositoryExtensions
{
public T GetByID(this Repository<T> repo, int id) where T : class, new()
{
...
}
}
Note that extension methods don't work if an instance method of the same name already exists, so if you go with this, you need both overloads of GetByID to be extension methods, not just this one.
The actual logic belongs in the Repository class, but you can forward to that:
public class Repository<T> where T : class
{
internal T GetByIDImpl(int id, Func<T> factory)
{
...
}
}
public static class RepositoryExtensions
{
public T GetByID(this Repository<T> repo, int id) where T : class, new()
{
return repo.GetByIDImpl(id, () => new T());
}
public T GetByID(this Repository<T> repo, T element, int id) where T : class
{
return repo.GetByIDImpl(id, () => element);
}
}
No, you can't do it this way.
All constraints have to be specified the place where you introduce the generic parameter, in this case at the class level.
As such you have two options:
Add , new() as a constraint, limiting the use of the repository class to use types that have a public parameterless constructor
Not add it as a constraint, and use reflection to try to construct the object at runtime
Note that point 2 there may fail (at runtime) if the type does not have a valid constructor.
There is no way you can ask the compiler to create a class where the ability to call a specific method is conditional, ie. "Only let me call GetByID if the type has a constructor".
If you want it as a compile-time constraint, you can do
public class Class<T> where T : class
{
public void Method<U> where U : T, new()
{
// ...
}
}
but this has the disadvantage that you'd have to do
new Class<HasConstructor>().Method<HasConstructor>();
as the type won't be implicitly picked up. The advantage is that the following won't compile:
new Class<NoConstructor>().Method<NoConstructor>();
Consider the following code:
abstract class Foo<T>
where T : Foo<T>, new()
{
void Test()
{
if(Bar != null)
Bar(this);
}
public event Bar<T> Bar;
}
delegate void Bar<T>(T foo)
where T : Foo<T>, new();
The line Bar(this) results in the following compiler Error:
Argument type Foo<T> is not assignable to parameter type T
T is constrained to Foo<T> as I want derived classes to basically tell the base class their type, so that the type can be used in the event callback in order to save the implementor from having to cast the callback argument to the derived type.
I can see the code doesn't quite work but I'm having a bit of a blockage as to how to do this correctly without ending up with a generic delegate that can be used for any old thing. I'm also not quite sure why the T constraint doesn't create a compiler error considering it seems to be recursive.
EDIT
I need to clarify this I think! Here's a new example which, I hope will be much clearer. Note below that the OnDuckReady event handler below generates a compiler error.
How do I get the event to pass in the correct type?
abstract class Animal<T>
where T : Animal<T>, new()
{
void Test()
{
if(AnimalReady != null)
AnimalReady(this);
}
public event AnimalHandler<T> AnimalReady;
}
delegate void AnimalHandler<T>(Animal<T> animal)
where T : Animal<T>, new();
class Duck : Animal<Duck>
{
public void FlyAway()
{
}
}
class Test
{
void Main()
{
Duck duck = new Duck();
duck.AnimalReady += OnDuckReady; // COMPILER ERROR
}
void OnDuckReady(Duck duck)
{
duck.FlyAway();
}
}
You can cast 'this' to T:
Bar((T)this);
This however will fail if you have the following:
public class MyFoo : Foo<MyFoo> { }
public class MyOtherFoo : Foo<MyFoo> { }
Because 'MyOtherFoo' is not an instance of 'MyFoo'. Take a look at this post by Eric Lippert, one of the designers of C#.
The code would be clearer if you didn't use "Bar" for two purposes. That having been said, I think what's needed is to use a generic with two parameters (e.g. T and U) such that T derives from U, and U derives from Foo. Alternatively, it's possible to do some nice things with interfaces. A useful pattern is to define:
interface ISelf<out T> {T Self<T> {get;}}
and then, for various interfaces that one might want to combine in an object:
interface IThis<out T> : IThis, ISelf<T> {}
interface IThat<out T> : IThat, ISelf<T> {}
interface ITheOtherThing<out T> : ITheOtherThing, ISelf<T> {}
If classes that implement IThis, IThat, and ITheOtherThing also implement ISelf<theirOwnTypes>, one can then have a routine whose parameter (e.g. "foo") has to implement both IThis and IThat accept the parameter as type IThis. Parameter "foo" will be of type IThis (which in turn implements IThis) while Foo.Self will be of type IThat. Note that if things are implemented this way, one may freely typecast variables to any desired combination of interfaces. For example, in the above example, if the object passed as "foo" was a type which implemented IThis, IThat, ITheOtherThing, and ISelf<itsOwnType> it could be typecast to ITheOtherThing>, or IThis, or any other desired combination and arrangement of those interfaces.
Really a pretty versatile trick.
Edit/Addendum
Here's a somewhat more complete example.
namespace ISelfTester
{
interface ISelf<out T> {T Self {get;} }
interface IThis { void doThis(); }
interface IThat { void doThat(); }
interface IOther { void doOther(); }
interface IThis<out T> : IThis, ISelf<T> {}
interface IThat<out T> : IThat, ISelf<T> {}
interface IOther<out T> : IOther, ISelf<T> {}
class ThisOrThat : IThis<ThisOrThat>, IThat<ThisOrThat>
{
public ThisOrThat Self { get { return this; } }
public void doThis() { Console.WriteLine("{0}.doThis", this.GetType()); }
public void doThat() { Console.WriteLine("{0}.doThat", this.GetType()); }
}
class ThisOrOther : IThis<ThisOrOther>, IOther<ThisOrOther>
{
public ThisOrOther Self { get { return this; } }
public void doThis() { Console.WriteLine("{0}.doThis", this.GetType()); }
public void doOther() { Console.WriteLine("{0}.doOther", this.GetType()); }
}
class ThatOrOther : IThat<ThatOrOther>, IOther<ThatOrOther>
{
public ThatOrOther Self { get { return this; } }
public void doThat() { Console.WriteLine("{0}.doThat", this.GetType()); }
public void doOther() { Console.WriteLine("{0}.doOther", this.GetType()); }
}
class ThisThatOrOther : IThis<ThisThatOrOther>,IThat<ThisThatOrOther>, IOther<ThisThatOrOther>
{
public ThisThatOrOther Self { get { return this; } }
public void doThis() { Console.WriteLine("{0}.doThis", this.GetType()); }
public void doThat() { Console.WriteLine("{0}.doThat", this.GetType()); }
public void doOther() { Console.WriteLine("{0}.doOther", this.GetType()); }
}
static class ISelfTest
{
static void TestThisOrThat(IThis<IThat> param)
{
param.doThis();
param.Self.doThat();
}
static void TestThisOrOther(IThis<IOther> param)
{
param.doThis();
param.Self.doOther();
}
static void TestThatOrOther(IThat<IOther> param)
{
param.doThat();
param.Self.doOther();
}
public static void test()
{
IThis<IThat> ThisOrThat1 = new ThisOrThat();
IThat<IThis> ThisOrThat2 = new ThisOrThat();
IThis<IOther> ThisOrOther1 = new ThisOrOther();
IOther<IThat> OtherOrThat1 = new ThatOrOther();
IThis<IThat<IOther>> ThisThatOrOther1 = new ThisThatOrOther();
IOther<IThat<IThis>> ThisThatOrOther2a = new ThisThatOrOther();
var ThisThatOrOther2b = (IOther<IThis<IThat>>)ThisThatOrOther1;
TestThisOrThat(ThisOrThat1);
TestThisOrThat((IThis<IThat>)ThisOrThat2);
TestThisOrThat((IThis<IThat>)ThisThatOrOther1);
TestThisOrOther(ThisOrOther1);
TestThisOrOther((IThis<IOther>)ThisThatOrOther1);
TestThatOrOther((IThat<IOther>)OtherOrThat1);
TestThatOrOther((IThat<IOther>)ThisThatOrOther1);
}
}
}
The thing to note is that some classes implement different combinations of IThis, IThat, and IOther, and some methods require different combinations. The four non-static classes given above are all unrelated, as are the interfaces IThis, IThat, and IOther. Nonetheless, it is possible for method parameters to require any combination of the interfaces provided that implementing classes follow the indicated pattern. Storage locations of a "combined" interface type may only be passed to parameters which specify the included interfaces in the same order. An instance of any type which properly implements the pattern, however, may be typecast to any "combined" interface type using any subset of its interfaces in any order (with or without duplicates). When used with instances of classes that properly implement the pattern, the typecasts will always succeed at run-time (they could fail with rogue implementations).
delegate void Bar<T>(Foo<T> foo) where T : Foo<T>, new();
It works great. I tested it.
here is the test code
public abstract class Foo<T> where T :Foo<T> {
public event Bar<T> Bar;
public void Test ()
{
if (Bar != null)
{
Bar (this);
}
}
}
public class FooWorld : Foo<FooWorld> {
}
public delegate void Bar<T>(Foo<T> foo) where T : Foo<T>;
class MainClass
{
public static void Main (string[] args)
{
FooWorld fw = new FooWorld ();
fw.Bar += delegate(Foo<FooWorld> foo) {
Console.WriteLine ("Bar response to {0}", foo);
};
fw.Test ();
}
}