Contrary to many (perhaps most) object-oriented design tutorials out there, inheritance hierarchies should not necessarily match up with a domain’s real-world taxonomy. In other words, just because all your objects are shapes in the real world doesn’t necessarily mean they should all inherit from IShape in your program. Even if they do all share an interface, just because they have similar methods doesn’t mean those methods need to be part of that interface.

The trick is to look at the calling code to see what operations you really need at that point. For example:

for shape in shapes:
  shape.doSomething()

Are you really going to call AddValue in a loop like that? I doubt it. More likely, it’s going to be something like Draw or GetEditControl, and AddValue will be called before it’s even put into shapes, or by a dimension-aware EditControl. In other words, IShape should only have methods that don’t care about dimension, and operations that care about dimension should be handled by other interfaces.

Your shapes shouldn’t hold their values through the interface. The interfaces are things you need to be able to do with them. The classes are the various ways you can fulfill those same things.

If your effort is to draw these shapes to the screen your interface is going to have nothing to do with values of any kind directly.

public interface IDrawable {
    void Draw(Graphics g);
}

This way you can invent completely new shape ideas you never thought of without having to change the signatures of how they interact. That is all the OO is for. Isolate the interaction to a single thing that will work for everything. (hint: You will often be abstracting a function, not a value.)

Now when you decide you need to be able to write these shapes to a data storage you can add.

public interface IWritable {
    void Write(Stream s);
}

Now there is place for these values to be typed, everything works better if its typed. Notice you can pretty much put anything here now, and freely mix-and-match.

public class Line : IDrawable , IWritable {
    public Point Start { get; set; }
    public Point End { get; set; }
    public void Draw(Graphics g) { }
    public void Write(Stream s) { }
}

public class ThreePointTriangle : IDrawable , IWritable {
    public Point First { get; set; }
    public Point Second { get; set; }
    public Point Third { get; set; }
    public void Draw(Graphics g) { }
    public void Write(Stream s) { }
}

public class SinRightTriangle : IDrawable , IWritable {
    public Point AngleA { get; set; }
    public Line Opposite { get; set; }
    public Line Hypotenuse { get; set; } 
    public void Draw(Graphics g) { }
    public void Write(Stream s) { }
}

public class Car : IDrawable {
    public void Draw(Graphics g) { }
}

The answer is simply, these aren’t similar objects. Inheritance is about shared behaviour, not shared values. Just because these objects are made up of points doesn’t mean they are related in terms of behaviour.

Leaving aside that getters and setters aren’t really behaviour and should be avoided if at all possible*, even in this case the getters and setters are doing different things, as hinted by the different signatures. This should make it clear, these objects do not share behaviour beyond the most meaningless sense of storing points.

(this is a good example of why to avoid getters and setters, as they can cloud the true behaviour of an object, and make it appear that unrelated objects are related because they all have getter and setter methods)

How about something like this:

public interface ICoordinateValue {}

public class Value1D : ICoordinateValue {}
public class Value2D : ICoordinateValue {}
public class Value3D : ICoordinateValue {}


public interface IShape
{
    IEnumerable<ICoordinateValue> GetValues();
    void AddValue(ICoordinateValue value);
}