Должна ли коллекция бизнес-объектов наследовать от Collection <T>, если она не расширяется?

Question

У меня есть коллекция бизнес-объектов (представляющая данные из базы данных), которая наследуется от Collection и имеет статический метод, который вызывает сохраненный процесс, а затем заполняет его свойства возвращенными данными.

Мой вопрос; это неправильно наследовать от коллекции, так как она не расширяет класс? или было бы лучше не наследовать от чего-либо, а вместо этого поддерживать закрытую переменную типа Collection?

Answer 1

Трудно дать ответ на этот вопрос, не видя гораздо больше подробностей о том, что вы пытаетесь сделать. Тем не менее, я бы обычно не наследовал от Collection, поскольку он не дает достаточно виртуальных методов для переопределения. Это может сделать изменение поведения вашего класса немного сложным в будущем.

Проблема с наследованием заключается в том, что если вы используете его, вы застрянете с поведением базового класса Collection навсегда или столкнетесь со сложным рефакторингом. Например, вы можете добавить операции фильтрации, поиска и сортировки, после чего вам нужно будет переключиться на Список из коллекции. Возможно, вы даже захотите сделать привязку данных, где вам понадобится BindingList вместо Collection.

Другой план будет наследовать от ICollection или, еще лучше, IList , а затем делегировать частному члену Коллекции. Это дает вам максимальный контроль и позволяет изменять внутреннее представление вашего класса, не затрагивая общедоступный интерфейс. Проблема в том, что вам нужно больше времени, чтобы развивать ваши классы.

Таким образом, перед вами стоит компромисс между более быстрым развитием и будущей гибкостью, и, как я уже сказал в начале, немного сложно судить о том, какой путь выбрать из информации, приведенной в исходном посте.

PS: Чтобы сделать реализацию IList доступной только для чтения, просто верните true из IsReadOnly и затем сгенерируйте исключение NotSupportedException для всех методов, которые изменяют список.

Answer 2

Если ваш бизнес-объект может предоставить миру обычные методы сбора данных, то вполне нормально наследовать от Collection<T>. И, как я полагаю, на самом деле вы что-то добавляете к этому - вы указываете T.

Udate:
Согласно комментариям автора, публикация всех методов коллекции сделает объект редактируемым, что недопустимо. Поэтому вместо наследования он сделал бы приватное поле и сделал бы класс перечислимым.

Answer 3

Да, это неправильно. У вас должен быть просто объект, который возвращает коллекцию. Кроме того, не делайте метод статичным, если нет острой необходимости. В новом Blah (). Foo () нет ничего плохого. Любой приличный JIT встроит создание объекта.

Кроме того, я думаю, что расширение Collection является неправильным в 99% случаев :) Обычно, когда люди расширяют Collection, то, что им действительно нужно делать, это просто составлять List и выставлять только то, что на самом деле нужно клиентам или просто использовать простой List.

Answer 4

На самом деле, самый "чистый" подход - это , а не , чтобы добавить что-либо, когда вы наследуете объект. Вряд ли кто-то пытается быть таким чистым, но это считается более чистым. Идея состоит в том, что вы могли бы переопределить некоторые методы, чтобы «заполнить пробелы» в отношении поведения вашего объекта, но не добавляли бы не закрытых членов.

Я не защищаю стремление быть таким чистым. Дело в том, что то, что вы делаете, не является «нечистым» в любом случае. (Примечание: я совсем не использую «чистый» и «нечистый» в том смысле, в каком они используются с функциональными языками. Просто в общем смысле словарных определений слов).