c# - Interface implementation overrides, etc -

here's simplest form of question:

iapple requires, among other things, property flavor itoffeeapple requires property flavor

the problem is, want itoffeeapple implement iapple (public interface itoffeeapple : iapple), both have same property requirement. becomes problem when, 1 purpose need collection of sweets (only itoffeeapple) itoffeeapple can recognised iapple.

is ok use "new" keyword in interface, implementers have 2 flavor properties?

have explained myself poorly? :\

edit: have. actual context geometry:

• iline requires start , end point ipoint.
• icurve requires start , end point icontrolpoint.

icurve functionality on top of iline, yet means want return start , end icontrolpoint rather ipoint, either implement both , have return of both icontropoint , ipoint of start , end, or ignore ipoint/iline , throw dry out window.

this elaboration of david culp's answer. it's quite long, i'm not posting comment.

while generic interface ilist<tpoint> looks solution, recommend elaborate semantics bit further. also, it's advisory consider introducing both generic , non-generic versions of interface (like ienumerable plus ienumerable<t>).

in clarified example should introduce term describing finite entity has starting , ending point. curve not line line curve. however, since curve uses controlpoints describe start , end, while line uses plain points instead, in specific case line is not curve. instead, both line , curve shape.

// interface denote shape has starting , ending point public interface ishape {     ipoint start { get; set; }     ipoint end { get; set; } }  // interface allow specialization of staring end ending points' type public interface ishape<tpoint> : ishape {     // note 'new' required here probably, didn't compile     tpoint start { get; set; }     tpoint end { get; set; } }  // line shape descibed pair of points; sake of  public interface iline : ishape<point> { }  // curve shape described pair of control points public interface icurve : ishape<controlpoint> { } 

then, actual implementations of iline , icurve can use explicit implementations of start , end properties coming non-generic ishape interface. favor strongly-typed access delimiting points, while preserving ability work them plain ishapes.

 public class curve : icurve   {      public controlpoint start { get; set; }      public controlpoint end { get; set; }      ishape.start       {          { return start; }          set           {               if (!(value controlpoint)) ... error handling ...;                start = (controlpoint)value;           }      }      ishape.end { ... ishape.start ... }  }   public class line : iline { ... curve ... } 

note in respect possible error scenario shown above improvement limiting ishapes properties getters only. or, setter passing value strongly-typed version of start or end kind of conversion of point control point. right solution domain-specific of course.