Не хочу продолжать и усуглублять дискуссию, вроде бы пришедшую к консенсусу. Но нельзя в общем случае заменять потомка на его родителя. Никто не будет гарантировать корректность результата.
Ну дык весь сыр-бор из-за "… предположим, один из членов команды пытается реализовать интерфейс IListofT в классе DoubleListofT таким образом, чтобы ...". Откуда же читателям знать, что «У автора в листингах DoubleList наследуется от ICollectionofT»? Это ж принципиально!
Про Человека: я проводил аналогию с туалетом и Человеком. Туалет не зря есть М и Ж. И женщинам будет некомфортно пользоваться М. Поэтому в реализации конкретного туалета нельзя опираться на абстрактного Человека.
Я просто толкую о том, что заменить IList на ICollection без риска сломать программу — нельзя. Не знаю почему вы с этим так упорно спорите. Посмотрите хотя бы MSDN и увидьте, что у списка есть свои личные методы. Программа, использующая их, если ей на вход подсунуть ICollection — банально не скомпилируется.
В обратную же сторону, если программа оперирует ICollection, то подсунув ей IList — поведение не изменится.
Мужчина, кстати, свою мочеполовую систему наследует от класса Человек. Но при этом, для облегчения после пары литров пива, ему не обязательно нужно садиться и спускать штаны — хватит и забора да расстёгнутой ширинки. Почему же тогда женщине будет так некомфортно пользоваться писсуаром?
Про поведение: ну допустим, у программы есть спецификация :))) И «изменится» — это поведение, отличное от данной спецификации. Для примера можно взять хоть те же тесты. Про «кто-то рассчитывает на то, что метод Add» — понимаю, странно. Скорее всего, программист делает что-то не так. Но он же всё-таки имеет на это право? Ему дали список и опираться на стандартное поведение списка — разумно.
Про ICollection: я не спорю что в BCL список является наследником коллекции. Но также стоит понять, что список — это коллекция с дополнительными условиями, более узкое понятие, более строгое. Нельзя просто так скормить программе объект с менее строгим поведением. Найдётся случай, когда всё упадёт. Который как раз и описан в статье :) А вот заменить IList на более специализированный список — можно. Принцип Лисков как раз об этом и говорит. И заменив IList на ICollection вы уже его и нарушили! DoubleList уже перестал играть здесь свою роль.
Пока не прочитал что? Статью прочитал, иначе как я буду её комментировать :)
Раз так, давайте вместо необоснованных нападок ещё раз внимательно прочтём написанное: один член команды решил реализовать свою версию IListOfT. Окей. Что это значит? Есть некий метод, берущий на вход объект (ссылку на объект) типа IListOfT и проводящий с ним некие операции. Что такое IList? Список. Что я ожидаю от его метода Add? Добавление в него 1го элемента. Читаем статью дальше: «если для каждого объекта o1 типа S существует объект o2 типа T такой, что для всех программ P, определенных в контексте T, поведение P не изменяется при замене o1 на o2, то S является базовым типом для T». Если мы подменим IList на DoubleList, поведение нашей программы изменится. Опа! Контрпример для определения! Делаем логичный вывод — принцип нарушен. Разве нет?
И не нужно здесь тыкать носом в ICollection. В данном случае это самый настоящий софизм. По условию задачи мы работаем со списком. Если же коллекция будет менее строгого типа, такого как ICollection — здесь реально уже совсем другой разговор. Мы не можем знать её природу, делать предположения о поведении и тем более опираться на то, что после добавления элемента, кол-во увеличится на один. Потому что множество — это тоже коллекция. Но дубли оно не позволяет.
А кто занимается созданием и удалением (размазыванием) снапшотов? Ведь операция (особенно удаления) не атомарная и растянутая во времени, а запросы к виртуальному диску идти будут, причем и на запись — тоже. И необходимо обеспечить консистентность данных (в т.ч. и метаданных).
Очень распространенное заблуждение, что женщины — многозадачны. Это они так думают, когда во время оплаты на кассе пытаются говорить по телефону и в это же время ощутимо тормозят очередь.
А хотя нет, беру свои слова обратно — отличный пример многозадачности :-)
Если верить комментам, то походу я тут единственный, кого устраивает и кому кристально понятен столь удобный и простой тул — RVM. Но ведь нас на самом деле много? :-)
Про Человека: я проводил аналогию с туалетом и Человеком. Туалет не зря есть М и Ж. И женщинам будет некомфортно пользоваться М. Поэтому в реализации конкретного туалета нельзя опираться на абстрактного Человека.
В обратную же сторону, если программа оперирует ICollection, то подсунув ей IList — поведение не изменится.
Про ICollection: я не спорю что в BCL список является наследником коллекции. Но также стоит понять, что список — это коллекция с дополнительными условиями, более узкое понятие, более строгое. Нельзя просто так скормить программе объект с менее строгим поведением. Найдётся случай, когда всё упадёт. Который как раз и описан в статье :) А вот заменить IList на более специализированный список — можно. Принцип Лисков как раз об этом и говорит. И заменив IList на ICollection вы уже его и нарушили! DoubleList уже перестал играть здесь свою роль.
Раз так, давайте вместо необоснованных нападок ещё раз внимательно прочтём написанное: один член команды решил реализовать свою версию IListOfT. Окей. Что это значит? Есть некий метод, берущий на вход объект (ссылку на объект) типа IListOfT и проводящий с ним некие операции. Что такое IList? Список. Что я ожидаю от его метода Add? Добавление в него 1го элемента. Читаем статью дальше: «если для каждого объекта o1 типа S существует объект o2 типа T такой, что для всех программ P, определенных в контексте T, поведение P не изменяется при замене o1 на o2, то S является базовым типом для T». Если мы подменим IList на DoubleList, поведение нашей программы изменится. Опа! Контрпример для определения! Делаем логичный вывод — принцип нарушен. Разве нет?
И не нужно здесь тыкать носом в ICollection. В данном случае это самый настоящий софизм. По условию задачи мы работаем со списком. Если же коллекция будет менее строгого типа, такого как ICollection — здесь реально уже совсем другой разговор. Мы не можем знать её природу, делать предположения о поведении и тем более опираться на то, что после добавления элемента, кол-во увеличится на один. Потому что множество — это тоже коллекция. Но дубли оно не позволяет.
В принципе, в этом всём проблемы никакой и нет.
Но меня терзает вопрос: а в чём смысл статьи то? :)) Просто очень странный топик и выбранный пример.
А хотя нет, беру свои слова обратно — отличный пример многозадачности :-)