Question: I would like to be able to do somthing like the following:

```
//non-generic
var MyTable = new Table();
string name = MyTable.Name;
IEnumerable<String> rows = MyTable.Rows;

//generic
var MyTableGeneric = new Table<MyType>();
string name = MyTableGeneric.Name;
IEnumerable<MyType> rows = MyTableGeneric .Rows;

```

Would something like this be to much:

<http://img81.imageshack.us/img81/427/diagramcm3.jpg>

or would this be better:

<http://img301.imageshack.us/img301/4136/presentation1nh9.jpg>

Sorry if this hard to understand what I am trying to get at, basically I have two objects will share comman properties except for there row collections which will be generic. I would like to do this in cleanest way.

Sorry for my crappy diagrams, made in powerpoint :)

Answer: 
I'd say the second design is better. Less items and easier inheritance path. 

The first design has unnecessary interfaces, which you don't really need unless you're implementing something else which implements the interface, but doesn't inherit from the base class.
What's the difference betweeen a `Table` and a `Table<string>`? In other words, can you not just use `Table<string>` as your nongeneric form?

If you *do* go for the second option, I'd suggest renaming one of your `Rows` properties - you may be able to get away with having two properties of different types through hiding etc, but it's not going to be pleasant.

How much behaviour will your `Table` type actually have? If it's really just a container, you may not need an interface - but if it's got significant logic behind it, you may want to have an interface so that you can mock out the table when testing a class which uses it.