Is this design a good idea - Interfaces and Abstract class

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 1

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.

Answer 2

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.

Answer 3

I would use generics in the rows, without involving string in the base class, and have the non generic inherit the Table class. Consider not using the abstract class.

Table<T> -> Table:Table<string>