Хорошая ли идея - интерфейсы и абстрактный класс
Я бы хотел сделать что-то вроде следующего:
//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;
Было бы что-то вроде этого слишком много:
http://img81.imageshack.us/img81/427/diagramcm3.jpg
или было бы лучше:
http://img301.imageshack.us/img301/4136/presentation1nh9.jpg
Извините, если мне трудно понять, что я пытаюсь понять, в основном у меня есть два объекта, которые будут иметь общие свойства, за исключением коллекций строк, которые будут общими. Я бы хотел сделать это максимально чисто.
Простите за дрянные схемы, сделанные в powerpoint :)
Ответы 3
Я бы сказал, что второй дизайн лучше. Меньше элементов и более простой путь наследования.
Первый дизайн имеет ненужные интерфейсы, которые вам действительно не нужны, если вы не реализуете что-то еще, что реализует интерфейс, но не наследуется от базового класса.
В чем разница между Table и Table<string>? Другими словами, нельзя ли просто использовать Table<string> в качестве неуниверсальной формы?
Если вы делать выберете второй вариант, я бы посоветовал переименовать одно из ваших свойств Rows - возможно, вам удастся избежать использования двух свойств разных типов путем скрытия и т. д., Но это будет неприятно.
Какое поведение на самом деле будет у вашего типа Table? Если это на самом деле просто контейнер, вам может не понадобиться интерфейс, но если он имеет значительную логику, вы можете захотеть иметь интерфейс, чтобы вы могли имитировать таблицу при тестировании класса, который его использует.
Я бы использовал универсальные шаблоны в строках, не используя строку в базовом классе, и имел бы неуниверсальные наследования класса Table. Не используйте абстрактный класс.
Table<T> -> Table:Table<string>
Кстати: это отличный инструмент для создания диаграмм в Интернете: yuml.me/diagram/scruffy/class/samples