# Generics: Is this improper use?

I have a class library in which I'm using generics as below. I'm not sure if it's an improper use or not. So aside from the fact that it works and everything "depends", id like some specific critique on how this usage might fall apart. In particular In wondering about the shadowing of non generic properties with generic counterparts. Is this an accepted practice?

 public interface IPickOrder
{

ERPListBase<IPickOrderLine> Lines { get; }
}

public interface IPickOrder<TPickOrderHeader, TPickOrderLine> : IPickOrder
where TPickOrderLine : class, IPickOrderLine
{

new ERPListBase<TPickOrderLine> Lines { get; }
}

public class PickOrder : IPickOrder
{

public ERPListBase<IPickOrderLine> Lines { get; protected set; }

public PickOrder() { }
}

where TPickOrderLine : class, IPickOrderLine, new()
{
{
protected set { base.Header = value; }
}

public new ERPListBase<TPickOrderLine> Lines { get; protected set; }

/// <summary>
///
/// </summary>
public PickOrder() : base() { }
}

• As you say, it "depends" - in this case, it depends on the purpose of these types. Why do you need to have both generic and non-generic IPickOrder and PickOrder? Perhaps try to write more about what are you trying to achieve with these types - how are they going to be used? – Nikola Anusev Jul 12 '12 at 8:07
• My reasons are more due to preference than need. Non generic means I can sling very simple types around in the core of the program re: work flow and routing. Then also having the generic types means at the periphery I can have strongly type objects so i do not have to recast everywhere i need more specific functionality... which at the periphery is often tho in the core assembly almost never... just a simple type interface will do. I also find that if i leave out a non generic type at the core, I can often get "type trapped" at the periphery. So at the core i like a very simple model. – rism Jul 12 '12 at 8:14
• just a quick note - when I see myself using "new" to hide members from a base class I take a step back and rethink the approach... – jl. Jul 12 '12 at 8:43
• If you have only instances of the PickOrder<T> class, then you only use the non-generic PickOrder as a conceptual 'interface' class. In that case, make PickOrder an abstract class. – Aphelion Jul 12 '12 at 9:25

I feel you on the "My reasons are more due to preference than need." comment but the inheritance from PickOrder and public new ERPListBase<TPickOrderLine> Lines { get; protected set; } will confuse somebody best case and really mess things up worst case. While it may still give you that feeling of impending doom here are some suggestions to make this safer while keeping the look and feel you prefer.

Consider implementing the property like so (also for Header)

public new ERPListBase<TPickOrderLine> Lines {
get {
// note that you can't control base.Lines so some values may not be of TPickOrderLine
return new ERPListBase<TPickOrderLine>(base.Lines.OfType<TPickOrderLine>());
}
protected set { base.Lines = new new ERPListBase<IPickOrderLine>(value.Cast<IPickOrderLine>()); }
}


Consider not reusing the base class and using explicit interface implementation:

public class PickOrder<TPickOrderHeader, TPickOrderLine> :
where TPickOrderLine : class, IPickOrderLine, new()
{

• Also be careful not to confuse new with override. – Dandy Mar 25 '13 at 18:32