Use a system class with a different name?

I need a way to track the numbers of rows and columns in a grid. If I use System.Point, I am always going to be forgetting whether "x" is the number of rows or columns. So I have the class below.

But I'm wondering if there is a way to use System.Point, with a different naming skin? In other words, I do not want to define a general "NRows" or "NColumns" method on System.Point. But I do want to be able to return an object that code will see as an "NRowsColumns" object, but in fact compiles to System.Point. When accessing an "NRowsColumns" object, we use the fields "NRows" and "NColumns" instead of "x" and "y". But under the hood, it actually compiles to a System.Point.

Ideally, this definition would not be restricted to a single file.

public class NRowsColumns
{
  public int NRows {get;set;}
  public int NColumns {get;set;}
  public NRowsColumns(int nRows, int nColumns)
  {
    this.NRows = nRows;
    this.NColumns = nColumns;
  }
}
Jon Skeet
people
quotationmark

No, you can't "rename" members like that. You can refer to System.Point as NRowsColumns if you really want, as

using NRowsColumns = System.Point;

... but it would still have the same members as System.Point.

It would be simpler to just implement NRowsColumns by composing a System.Point though:

public class NRowsColumns
{
    private Point point;

    public int NRows
    {
        get { ... } // Code using point
        set { ... } // Code using point
    }

    ...
}

Having said that:

  • I can't see that a Point really has anything to do with a number of rows and columns. Why not just have two integers?
  • I would revisit your naming here... the N prefix is unconventional. I would probably call it GridSize with Rows and Columns - although even this seems unnecessary as a separate type, in general. (Why does your grid itself not expose its size via Rows and Columns properties?)

people

See more on this question at Stackoverflow