C# property exactly the same, defined in two places

Question

I have the following classes:

1. Defect - represents a type of data that can be found in a database
2. FilterQuery - provides a way of querying the database by setting simple Boolean filters

Both Defect and FilterQuery implement the same interface: IDefectProperties. This interface specifies particular fields that are in the database. Different classes have methods that return lists of Defect instances. With FilterQuery, you specify some filters for the particular properties implemented as part of IDefectProperties, and then you run the query and get back a list of Defect instances.

My problem is that I end up implementing some properties exactly the same in FilterQuery and Defect. The two are inherently different classes, they just share some of the same properties. For example:

public DateTime SubmitDateAsDate
{
    get { return DateTime.Parse(SubmitDate); }
    set { SubmitDate = value.ToString(); }
}

This is a property required by IDefectProperties that depends on a different property, SubmitDate, which returns a string instead of a DateTime. Now SubmitDate is implemented differently in Defect and FilterQuery, but SubmitDateAsDate is exactly the same. Is there a way that I can define SubmitDateAsDate in only place, but both Defect and FilterQuery provide it as a property? FilterQuery and Defect already inherit from two different classes, and it wouldn't make sense for them to share an ancestor anyway, I think. I am open to suggestions as to my design here as well.

Answer 1

No, there is no way to do this exactly as you describe.

But. The very fact that you have this problem means that your initial design is probably not optimal. I don't know your whole problem, so please don't take my advice too seriously, but what immediately comes to mind is get rid of interface implementation in FilterQuery, but rather make it accept (or expose) an instance of Defect, and use that Defect's properties for filtering. Another thing that might work is to have a "storage" structure, which would have all the data fields, and both Defect and FilterQuery would incorporate it.

Answer 2

When inheritance doesn't make sense, composition usually does.

internal class DefectPropertyInternal
{
  private IDefectproperty dp
  public DefectPropertyInternal(IDefectproperty dp)
  {
     this.dp = dp;
  }

  public DateTime SubmitDateAsDate
  {
    get { return DateTime.Parse(dp.SubmitDate); }
    set { dp.SubmitDate = value.ToString(); }
  }

}

public class Defect : IDefectProperty
{
  private DefectPropertyInternal dpi;

  public Defect()
  {
     this.dpi = new DefectpropertyInternals(this);
  }

 public DateTime SubmitDateAsDate
 {
    get { return dpi.SubmitDateAsDate; }
    set { dpi.SubmitDateAsDate = value; }
 }

}

In this way, DefectPropertyInternals implements all the shared fucntionality for FilterQuery and Defect, without having to repeat that in each class.

Answer 3

If inheritance isn't appropriate and you want to reuse code, you have to use either composition (probably overkill for the simple case you've described) or extension methods.

Extension methods are a great way to simulate multiple inheritance in C#, though there are no extension properties ("maybe someday" says Eric Lippert). If you're willing to give up property semantics, you could do this:

public static DateTime GetSubmitDateAsDate(this IDefectProperties defectProperties) {
    return DateTime.Parse(defectProperties.SubmitDate);
}

public static void SetSubmitDateAsDate(this IDefectProperties defectProperties, DateTime dateTime) {
    defectProperties.SubmitDate = dateTime.ToString();
}

Answer 4

Why not implement SubmitDateAsDate in a utility class and call into that utility from each class?

Answer 5

I agree with @Fyodor Soikin. You should probably use a prototype Defect within the FilterQuery class. If that's not really feasible, you could always omit the ...AsDate properties from the interface and implement them as extensions. You'd have to either defer the implementations for each class-based extension to a common implementation or if you use an interface-based extension, cast to the interface before using the method. The former probably only makes sense if the methods/properties are complex or you're using more code than just reimplementing them for each class would.

public static class DefectExtensions
{
     public static DateTime SubmitDateAsDate( this IDefectProperties source )
     {
            return DateTime.Parse( source.SubmitDate );
     }

     public static void SetSubmitDateAsDate( this IDefectProperties source, DateTime date )
     {
           source.SubmitDate = date.ToString();
     }
}

Answer 6

Here's an idea. Instead of FilterQuery implementing IDefectProperties, it's constructor or search method can accept an object that implements this interface.

Constructor option:

class FilterQuery{
    IDefectProperties defectProperties;
    FilterQuery(IDefectProperties dp){
        defectProperties=dp;
    }
}

You set up a FilterQuery object with the search properties (instead of setting up the properties in FilterQuery) and pass it into FilterQuery. You can use a Defect object or something inherits from it or something else (this design opens a lot of possibilities) This would make FIlterQuery more coherent too, leaving it with only the responsibility of searching and getting back the resuls.