Я должен Предпочесть Закрытый или Открытый Список <> Система?
У меня есть класс в моем проекте, который хранит Список <> элементов. Я пытаюсь выяснить, должен ли я позволить пользователю добавлять к тому Списку непосредственно (например, Вызов собственного компонента добавляют/удаляют методы), или заблокируйте его вниз путем объявления частного Списка и только разрешения горстки методов, я принимаю решение на самом деле изменить Список.
Это - платформа, таким образом, я пытаюсь разработать его максимально надежно, но я также хочу сохранить его максимально простым и безошибочным.
Какова лучшая практика в этой ситуации?
Спасибо, Tyler
6 ответов
Для фреймворка я бы рекомендовал полностью инкапсулировать список и создать методы для извлечения и добавления в него элементов.
Если возникнет необходимость проверить добавленные элементы, или если для некоторых действий необходимо запустить события, вы сможете это сделать.
Если вы по какой-то причине предпочитаете хранить эти элементы по-другому, вы можете это сделать.
С другой стороны. если вы разрешите доступ к списку напрямую, будет сложно вернуться и инкапсулировать его или изменить это и использовать что-то еще. Код, использующий эту структуру, может зависеть именно от прямого доступа к списку.
Сохранение списка закрытым дает вам больше контроля и может сделать его более надежным (вы можете проверить значения, прежде чем принимать их в список)
Но сделать его общедоступным - это проще всего.
Вы всегда должны держать свои переменные приватными. См. совет Jon Skeets для подробностей. В основном потому, что вы хотите сохранить контроль над тем, как вы обрабатываете данные. Пользователю не нужно знать, список это или что-то другое.
Если вы используете .NET 3.5 или выше, вы можете приватно использовать List<> и сделать публичное свойство ReadonlyCollection. Это также безопасно для потоков, но может потребовать некоторой работы с вашей стороны.
Для такого рода вопросов я могу порекомендовать FxCop. Она анализирует ваш код и дает подсказки по дизайну, производительности и т.д.
Можно создать подкласс списка и переопределить методы, изменяющие содержимое списка. В переопределении вы можете либо выполнить дополнительную обработку, чтобы предотвратить изменение списка, либо вызвать событие, чтобы вы могли получить уведомление об изменении списка. Вы даже можете просто не вызывать базовую реализацию в переопределениях и бросать NotSupportedException, если хотите полностью отключить метод.
@ Дилан Вестер: Поскольку вы должны отдавать предпочтение композиции, а не наследованию, не наследуйте список. Возможно, вы захотите изменить его на другую структуру данных позже или выполнить какую-то проверку / проверку перед добавлением в свой список.
Это действительно зависит от того, что вы делаете.
Лично я, когда у меня есть список в пользовательском классе, и он предоставляет, скажем, список бизнес-сущностей элементу управления, привязанному к базе данных, я бы сделал его приватным и открыл пару простых публичных методов для его обновления, и я мог бы поместить туда дополнительный код, например, перемещение данных или что-то еще.
Однако, если список является результатом какого-то запроса, возможно, лучше раскрыть его целиком, и иметь возможность использовать все ваши методы расширения и т.д. для работы с ним.
На мой взгляд, это лучше для фреймворка в контексте
.