Зачем использовать «ICollection<T>»?
Я неопытный любитель С#, который пытается немного изучить С#, когда у меня остается немного времени, как сейчас в последнее время.
Я пытаюсь понять, когда использовать ICollection<T>.
Я искал на YouTube и онлайн-документации. Но они рассказывают о том, «как это использовать», а не о том, почему и когда его использовать. Например, заголовок, подобный приведенному ниже, был бы для меня гораздо полезнее:
«Эй, ты всегда используешь
List<T>? Узнайте, какICollection<T>может будь полезнее!"
Кажется, что снаружи ничего нет. Я предполагаю, что этому нужно научиться каким-то косвенным образом. В любом случае, может ли кто-нибудь предоставить и ответить и даже, возможно, пример, почему можно использовать это вместо одного из списков, массивов и многого другого?
Редактировать: я даже не знаю, как задать вопрос, потому что я не знаю, о чем говорю. Вот код, который вызвал мой интерес:
ICollection<ValidationResult> validationResultList = new List<ValidationResult>();
Что здесь происходит?
Тот же принцип, который применяется ко всем интерфейсам, также применим к этому конкретному интерфейсу... Вы используете его, когда хотите использовать параметр коллекции, тип реализации которого вам не важен (но на котором вы собираетесь получить доступ к присутствующим членам на этом интерфейсе) или когда вы хотите вернуть его.
Когда вы используете List<T>, вы используете ICollection<T>
Позвольте мне попробовать по-другому: можно использовать список, массив и массив. Очень гибкий. Тем не менее, кто-то предпочитает реализовать свою собственную коллекцию (я полагаю) с помощью ICollection<T>. Почему? Какую проблему это решает?
Нет, вам не нужно реализовывать свою собственную коллекцию при ее использовании. Вы просто говорите: «Этот метод возвращает ICollection<string>, и какую реализацию этого интерфейса он вернет, вас не должно волновать». Вот что делает интерфейс. Это не означает, что вы должны реализовать его в своем собственном типе. Заявление о том, что ваш метод принимает или возвращает ICollection<T>, является гибким. Это позволяет вам реорганизовать свой код, чтобы однажды он возвращал массив вместо списка, и вызывающим объектам не придется ничего менять, и он позволяет вашим вызывающим объектам передавать любую коллекцию, пока он реализует этот интерфейс.
Это наиболее полезно в качестве входного параметра. Мне не нужно знать, дается ли мне List<T> или T[], чтобы изменить содержимое. Зачем мне заставлять вызывающих абонентов всегда преобразовывать свой список в массив, чтобы вызвать мой метод «Обратный»?
@CodeCaster Да, я могу показать код. Это в (с отметкой времени): youtu.be/Bu-4WXFcMkc?t=695
Извините, я перемотал минуту назад и посмотрел две, и я кричу на его опечатки, отступы, его щелчки мышью для установки каретки, общий дизайн пользовательского валидатора (включая имя класса «Проверить», правда?), (отсутствие) скорости и объяснения и плавающего проводника решений. Я физически и морально не могу смотреть обучающие видео.
При этом: объявление локальной переменной в качестве интерфейса обычно не требуется. В данном случае это не так, потому что он передается методу, который принимает ICollection<T>, поэтому экземпляра любого класса, реализующего этот интерфейс, будет достаточно.
CodeCaster + Эндрю Уильямсон спасибо. Объединенная информация, а также ответ @chart решает это для меня. Спасибо всем! Теперь я понимаю.
Именно это был последний бит, который ответил на все мои вопросы на данный момент: При этом: объявление локальной переменной в качестве интерфейса обычно не требуется. В данном случае это не так, потому что он передается методу, который принимает ICollection<T>, поэтому экземпляра любого класса, реализующего этот интерфейс, будет достаточно.
Ответы 1
Простой ответ: используйте ICollection<T>, когда вам нужно что-то более абстрактное, чем List<T> (или другой набор, например HashSet<T>).
Вы используете интерфейс, потому что вы можете не заботиться о получении List конкретно. Вы заботитесь о получении объекта, который реализует методы, заключенные интерфейсом. Вы просто хотите знать, что когда что-то передается в ваш метод, а затем вы вызываете myArgument.neededMethod(), вы точно знаете, что этот метод будет реализован.
см. небольшой фрагмент кода в моем исходном (отредактированном) сообщении. Что достигается этим кодом? Спасибо.
В вашем примере вы создаете новый экземпляр List<ValidationResult>. Причина, по которой вы можете использовать ICollection<ValidationResult> в качестве типа, связана с полиморфизмом. Если это не то, с чем вы знакомы, посмотрите и потратьте некоторое время, пытаясь понять концепцию, и она действительно лежит в основе объектно-ориентированного программирования (ООП), C# и Java, в частности.
На практике для вашего примера фактически нет разницы между: ICollection<ValidationResult> validationResultList = new List<ValidationResult>(); и List<ValidationResult> validationResultList = new List<ValidationResult>();
Да спасибо. Я узнал об этом из комментариев. Это был просто неправильный код для этого универсального интерфейса коллекции. Если бы это было в параметре, его использование было бы более понятным для меня. Спасибо брат.
CodeCaster нет, но спасибо за ответ. Я знаю, для чего нужен интерфейс. Мой вопрос в том, зачем использовать указанную коллекцию, а не для чего нужен интерфейс.