Is it appropriate to have multiple identical classes with different names?

Question

I have a question about naming multiple classes that share similar functionality. I am working on a scientific API and have the following classes/interfaces:

public interface IRange<T>{
    T Minimum {get;}
    T Maximum {get;}
    // A few other methods that aren't important
}

public class Range<T> : IRange<T> where T: IComparable<T> {
    public T Minimum {get; protected set;}
    public T Maximum {get; protected set;}

    public Range(T minimum, T maximum) {
        Minimum = minimum;
        Maximum = maximum;
    }
}

For my API, I work with double ranges a lot (i.e., Range<double>), so I made an another class called MassRange. This class also has a few new constructors and properties shown below:

public class MassRange : Range<double>, IRange<double> {
    public double Width { get { return Maximum - Minimum;} }
    public double Mean { get { return (Maximum + Minimum) / 2.0;} }

    public MassRange(double mean, MassTolerance width) {
        Minimum = mean - width.Value;  // pseudo-code
        Maximum = mean + width.Value;
    }
}

Conceptually, I also have another type of Range<double> called a MzRange, that shares all the same structure and functionality as MassRange but I want to keep separate in the API. They act exactly the same and store the same types of data, but in terms of the science, they are different and distinct.

So I considered renaming the MassRange class to a more generic name of DoubleRange and then have both MassRange : DoubleRange and MzRange : DoubleRange designed like so:

public MzRange : DoubleRange, IRange<double> {}

public MassRange : DoubleRange, IRange<double> {}

But I don't really care for the name DoubleRange, and would rather not expose it publicly through my API. Is exposing two distinct types with the same functionality even appropriate? Should I just come up with a better name for DoubleRange and forgo MzRange and MassRange? Can I make DoubleRange internal or something so that it is not exposed through the API but can still be used?

This seems to be a case for Extension Properties but I know they don't currently exist.

Answer 1

There doesn't seem to be any reason you can't accomplish this with standard extension methods:

public static double GetWidth(this IRange<double> range) {
    return range.Maximum - range.Minimum;
}

public static double GetMean(this IRange<double> range) {
    return (range.Maximum + range.Minimum) / 2.0;
}

And then you can call it from any implementation of IRange:

var massRange = ...
var mean = massRange.GetMean();

I know it may not have the syntactic appeal of extension properties, but it's a clean solution that gets around having to create that DoubleRange class.

Answer 2

This is absolutely appropriate. Besides the logical distinction, it gives you the possibility to evolve the two classes independently from each other in future.

Even if elephants and birds are animals (both inherit from animals) and both have the same set of properties (they don't add or override members), you might want to add a Fly method to birds in future. I assume that elephants named Dumbo do not exist in real world scenarios :-)

Answer 3

Having two types with the exact same functionality isn't appropriate as any change made to one type will need to be made to the other.

Unless you know that MassRange and MzRange will be differentiated at some point in the future, providing a better name for DoubleRange and forgoing MassRange/MzRange is the way to go. And even then, any shared functionality would need to be put in a parent type.

You can always provide some syntactic sugar to help users. For instance, you could create "dumb" classes called MassRange and MzRange, which simply extend DoubleRange. I'd keep the original, well named class exposed, to encourage users to use it, but if you really want to hide it, just use the protected accessor instead of public.