Здравствуйте, beroal, Вы писали:
B>Давным давно, когда ООП для меня было в новинку, я прочитал в одной книжке, что объекты моделируют реальность (вроде бы Гради Буч). Я не могу привести ссылку, но хорошо помню, что это была не случайная мысль, а мощный разработанный тезис, который, в частности, выдвигался в поддержку самого ООП — якобы оно нужно программисту, чтобы моделировать реальность, с помощью него моделировать реальность очень хорошо. И до сих пор я замечаю, что иногда этот тезис проскакивает в общих размышления об ООП у его поклонников, типа "таким образом мы лучше моделируем реальность".
В науке часто используется следующий приём: что бы обяснить человеку то, чего он не знает, вместо того, что бы сразу обяснять ему модель, основанную на последних достижениях (часто черезвычайно сложную и противоречивую) — ему обясняют всё очень упрощённо и не правильно. Вспомните физику или химию в школе — мы как бы заново проходим путь, пройденный в своё время наукой — каждый раз узнавая, что то, что нам рассказывали раньше — это не совсем правда и, что на самом деле всё обстоит несколько сложнее — иначе.
То же самое сделал и Гради Буч. Думаю, что он прекрасно знал, что его пояснения мягко говоря не правильны. Но у них есть существенное достоинство — если не воспринимать их черезчур буквально, а воспринять из них лишь идею построении системы взаимодействующих объектов, некоторые аспекты поведения которой напоминают некоторые аспекты "предметной области" — то это позволяет воспринимать и развивать конепции ООП/ООА гораздо быстрее, чем если идти, например, снизу — от ассемблерного кода, пытаясь обяснить как из отдельных регистров и команд получить объект.
Эта метафора (о том, что объектная программа моделирует реальный мир) — это всего лишь взгляд на програмную систему "сверху" — полезный инструмент для того, что бы позволить соеденить программу и реальный мир — сделав возможным осмысленное проектирование и понимание программы.
Думаю, что вы знаете, что электроны в атоме не летают вокуг ядра по круговым орбитам — более того — у них вообще нет орбит пока они в составе атома, но не сетуете по этому поводу на школьную физику.
B>Я, однако, не поклонник, смотрю на ООП критически, и это одна из причин, почему. Я не думаю, что программы моделируют реальный мир. Таковыми являются только те программы, у которых в ТЗ прямо записано, что функция программы — моделирование. Например, предсказание погоды, компьютерные игры (стрелялки). Конечно, ПО для моделирования — важная и нужная часть ПО, но именно часть. А в ООП получается, что каждая программа неявно моделирует. Мне, честно говоря, тяжело это представить.
Программы НЕ моделируют реальный мир. Это делают разработчики программ для того, что бы облегчить себе проектирование. Сложную прогаммную систему гораздо легче представить и понять, если рассматривать её как набор объектов, уровней, модулей, служб и т.д. чем как алгоритм.
B>Мне могут привести конкретные примеры. Например, система учёта ТМЦ моделирует, собственно, ТМЦ, как там они перемещаются географически и пр. С этим я не спорю. А бухучёт что моделирует? Бумажный бухучёт? А если мы вспомним, что сами деньги — это не бумажки или драгоценные металлы, а условность. А компьютерная игра "Шахматы" что моделирует? Деревянные шахматы? Которые тоже условность, и в свою очередь моделируют что?.. К любой программе можно притянуть за уши какой-то физический объект, потому что компьютеры появились относительно недавно, и у многих программ должен быть хотя бы бумажный прототип.
Самое забавное как раз в том, что приведённые примеры как раз относятся к тем областям, где программа реализует как раз таки именно модели. Бухучёт — модель движения денежных потоков между счетами, а шахматы — так это построенная по чётким правилам модель сражения. Лучше сказали бы про компиляторы или линкеры — для них соответствие в реальном мире найти гораздо сложнее... Однако мысль ясна.
Но как мне кажется, всё станет на свои места, если мы примем за основу, что моделированием занимается не сама программа, а человек, который её создаёт.
B>Я не возражаю против того, что любая программа что-то моделирует. Это вопрос схоластики. Доказать можно. Меня интересует, насколько полезен такой взгляд программисту, насколько полезно ложить его как основу парадигмы программирования.
В этом и суть. Программы не моделируют. Моделируют их разработчики. Примеры Буча со стиральными машинами и сельхоз системами изначально критики не выдерживали, если пытаться воспринимать их как модели реальности, так как они даже близко не учитавали большинство важных свойств моделируемых объектов.
B>Я предпочитаю смотреть на программу как на машину — что она умеет делать, насколько удобно ей управлять. Возможно даже, тезис о моделировании — это хитрый ход конём, уход от пользователя. У нас есть объективная реальность, мы её в тиши кабинета с ретортами и колбами моделируем, а пользователь со своими предложениями пусть пока постоит за дверью. А ведь даже моделирование интересует не вообще, а в том аспекте, который интересует пользователя. Самолёты учитываются по-разному в бухгалтерии, КБ, аэропорту. B>Этот взгляд губителен хотя бы тем, что мы концентрируемся на предметной области, а не на тех преимуществах, которые даёт современная техника. Ведь компьютер может гораздо больше, чем делалось с помощью ручки и бумаги... Зачем же моделировать ручку и бумагу? B>Или я уделяю слишком много всему этому внимания?
Именно. Я не видел ни одного разработчика кто занимаясь бухгалтерскими системами додумался бы до моделирования бумажных папок и перьевых ручек.
Искусство и предназначение аналитика, который изучает предметную область как раз и заключается в том, что бы суметь выделить из предметной области то, что в ней следует моделировать. Врядли заказчика обрадует, если бухгалтерская система будет моделировать перьевые ручки, но не будет учитывать перемещение денег по счетам.
Кроме того, если рассмотреть такую программу, как компилятор — то получается, что реального объекта нет, а вот программа и объектная модель — есть.
Здравствуйте, Cyberax, Вы писали:
C>prVovik пишет:
>> B>Ещё можно назвать декомпозиция >> В этом то и вся "фишка". Декомпозиции бывают разные. Есть две >> совершенно ортогональные: алгоритмическия декомпозиция и объектная. >> Апологеты ООП утверждают, что объектная декомпозиция лучше, чем >> алгоритмическая, ну а поклонники структурного программирования, >> соответственно, агетируют за алгоритмическую.
C>Алгоритмическая и объектная декомпозиции — почти ортогональны, то есть C>почти не влияют друг на друга. Соответственно при проектировании ПО в C>ООП-стиле требуется сделать обе декомпозиции и совместить их.
Не совмещение, а последовательноть.
Вопрос только в последовательности. Что сначала — объектная или алгоритмическая? Гамлетовский вопрос.
А вообще, если помнить правила правильного дизайна который должен получиться в конце, то эта два пути к одной и той же цели. И в конце пути — результат может быть совершенно один и тот-же.
Здравствуйте, OpenMinded, Вы писали: OM> Кроме того, если рассмотреть такую программу, как компилятор — то получается, что реального объекта нет, а вот программа и объектная модель — есть.
Да, компиляторы и интерпретаторы — хороший пример. OM> Программы НЕ моделируют реальный мир. Это делают разработчики программ для того, что бы облегчить себе проектирование. Сложную прогаммную систему гораздо легче представить и понять, если рассматривать её как набор объектов, уровней, модулей, служб и т.д. чем как алгоритм.
Так всё-таки. Должен ли программист уметь моделировать? Входит ли это в его должностные обязанности?
Re[6]: Программирование есть моделирование реального мира
Здравствуйте, beroal, Вы писали:
OM>> Программы НЕ моделируют реальный мир. Это делают разработчики программ для того, что бы облегчить себе проектирование. Сложную прогаммную систему гораздо легче представить и понять, если рассматривать её как набор объектов, уровней, модулей, служб и т.д. чем как алгоритм. B>Так всё-таки. Должен ли программист уметь моделировать? Входит ли это в его должностные обязанности?
Да, как мне кажется, обязательно должен. С моей точки зрения, моделирование — суть есть умение адекватно выделять существенное и отбрасывать не существенное. Это должен уметь делать любой человек — и это основа успеха в любой деятельности.
И заметьте — это не имеет отношения к тому, моделирует ли реальный мир сама программа. Важно умение её разработчиков это делать. В действительности что мы называем "моделировать"? Ведь реально за этим стоит — понять, что у товара есть название и цена и что и то и другое придётся где то хранить, что бы отобразить на чеке. Многово ли стоит ожидать от разработчика неспособного додуматься до столь гениальных построений?
Здравствуйте, OpenMinded, Вы писали:
OM> Кроме того, если рассмотреть такую программу, как компилятор — то получается, что реального объекта нет, а вот программа и объектная модель — есть.
Это пять! Это дзен!
Объект не проcто нереален, даже невозможно представить себе степень его нереальности. Это нагромождение одного несуществования на другое, опирающееся на ничто... Зачастую в программировании именно так оно и есть.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, OpenMinded, Вы писали:
OM>> Кроме того, если рассмотреть такую программу, как компилятор — то получается, что реального объекта нет, а вот программа и объектная модель — есть.
MS>Это пять! Это дзен! MS>Объект не проcто нереален, даже невозможно представить себе степень его нереальности. Это нагромождение одного несуществования на другое, опирающееся на ничто... Зачастую в программировании именно так оно и есть.
Конечно дзен. В програмировании вообще очень много прямо-таки религиозных убеждений. Постоянные евангилистские споры в этом форуме по моему это только подтверждают...
Re[5]: Программирование есть моделирование реального мира
Здравствуйте, beroal, Вы писали: B>Но вы не так меня поняли. Я сравниваю подход "от пользователя" и "от реального мира". Разве сможем мы правильно учитывать самолёт в бухучёте, если будем руководствоваться общеизвестными представлениями о самолёте?
Вообще-то модель обычно представляет собой некоторое упрощенное описание моделируемого объекта. Все. Точка. Кирпич может быть смоделирован материальной точкой (и для расчета его траектории в вакууме этого более чем достаточно), а может — как параллелепипед из материала, обладающего некоторыми деформационными свойствами (которые нужны для расчета его напряженного состояния). Также он может моделироваться как объект материального учета, и тогда можно пренебречь всем, кроме стоимости и периода амортизации.
В чем проблема-то? Ты что, решил, что ООП требует от тебя моделировать кирпич как материальное тело?
Более того, в реальном программировании как правило применяются модели моделей. Сама концепция бухгалтерского счета представляет некоторую модель, описывающую экономическую деятельность. В бухгалтерской программе ты будешь моделировать эту модель, а не саму экономическую деятельность. Если от программы требуется не бухгалтерия, а что-то еще — флаг в руки и идем использовать другую модель.
Тем не менее, надо понимать, что с точки зрения самого процесса моделирования "банковский счет" ничуть не менее реален, чем самолет весом в 140 тонн.
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, beroal, Вы писали: B>Кажется, я начинаю понимать. После того, как мы оставили слово "модель", но отбросили "реального мира", и стали называть моделью всё, что может быть придумано, всё становится на свои места. Пишу ли я программу или поэму — я пишу модель.
Я совершенно не понимаю твоего стремления использовать нестандартную трактовку термина "модель".
Ты зачем-то приписываешь к термину "модель" слово "инженерная". А потом удивляешься, почему твои программы не имеют никакого отношения к моделированию машинок из картона.
Ты бы еще удивлялся тому, что ООП никак не применимо к Синди Кроуфорд, которая тоже вроде как модель, да еще какая
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, beroal, Вы писали:
B>Давным давно, когда ООП для меня было в новинку, я прочитал в одной книжке, что объекты моделируют реальность (вроде бы Гради Буч).
Это все, естественно, не так.
На самом деле, все было так:
1) Сначала программы писались в машинных командах. В этом смысле реальность моделировалась сонмищем машинных инструкций.
2) Изобрели императивные языки программирования "высокого" уровня. Реальность стали моделировать на этих языках. Кстати, языки программирования ограничили свободу программиста по сравнению со свободой машинных языков — то есть дисциплинировали его.
3) Изобрели структурное программирование (правильные управляющие конструкции IF THEN ELSE END, CASE, WITH и т.д., избавились от неструктурных: goto, break, continue). Реальность стали моделировать = описывать с помощью структурных языков. Заметьте, что свобода программиста ограничилась еще сильнее, а дисциплина, стало быть, выше.
4) Изобрели модульность и сборку мусора. Тут опять степень свободы программиста уменьшилась, а его дисциплина еще сильнее увеличилась. Реальность стали моделировать не просто на структурных языках высокого уровня, а на модульных структурных языках.
5) Изобрели то самое ООП. Оно вообще самым жесточайшим образом урезало свободу программиста — теперь программист был вынужден думать, то есть моделировать = описывать реальность в терминах объектов. Но зато дисциплина программирования опять повысилась.
6) Изобрели КОП (компонентно ориентированное программирование). КОП — являясь по своей сути тем же самым ООП налагает на него некоторые ограничения, тем самым еще сильнее ограничивая свободу программиста, но зато еще сильнее поднимает дисциплину программирования.
И так далее. Мы платим свободой в обмен получаем дисциплину и новые уровни абстракции.
Объекты, на самом деле, не моделируют реальность, точно так же как модули или процедуры ее тоже не моделируют, также как ее не моделируют сонмища машинных инструкций. Но ничего более лучшего у нас пока нет. Поэтому используем что есть.
Здравствуйте, McSeem2, Вы писали:
OM>> Кроме того, если рассмотреть такую программу, как компилятор — то получается, что реального объекта нет, а вот программа и объектная модель — есть.
MS>Это пять! Это дзен! MS>Объект не проcто нереален, даже невозможно представить себе степень его нереальности. Это нагромождение одного несуществования на другое, опирающееся на ничто... Зачастую в программировании именно так оно и есть.
Не могу с Вами согласиться.
Есть и реальный объект — язык.
Есть и соответствующая модель, предложенная Хомским.
Возможно, Вы имеете в виду, что ЯП — искусственные языки (то же можно сказать, к слову, и об эсперанто).
Но основываются они именно на моделировании естественного языка.
Так что дзеном здесь и не пахнет.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
... СГ>6) Изобрели КОП (компонентно ориентированное программирование). КОП — являясь по своей сути тем же самым ООП налагает на него некоторые ограничения, тем самым еще сильнее ограничивая свободу программиста, но зато еще сильнее поднимает дисциплину программирования.
Добавка
7) Затем изобрели Активные Объекты — более нет никаких процессов/потоков с мьютексами/мониторами и т.п., а просто есть "первородные" активности синхронизация которых описывается всего лишь двумя ключевыми словами EXCLUSIVE и AWAIT. С одной стороны это опять есть ограничение свободы программиста, но с другой стороны это еще более дисциплинированное программирование, еще более высокий уровень абстракции.
В будущем изобретут еще что-нибудь еще сильнее поднимающее дисциплину программирования (уровень абстракции) и так далее. Но, в качестве расплаты, на каждом последующем шаге мы будем терять свободу... — свободу в совершении глупых ошибок!
Здравствуйте, beroal, Вы писали:
B>Я не возражаю против того, что любая программа что-то моделирует. Это вопрос схоластики. Доказать можно. Меня интересует, насколько полезен такой взгляд программисту, насколько полезно ложить его как основу парадигмы программирования. B>Я предпочитаю смотреть на программу как на машину — что она умеет делать, насколько удобно ей управлять. Возможно даже, тезис о моделировании — это хитрый ход конём, уход от пользователя. У нас есть объективная реальность, мы её в тиши кабинета с ретортами и колбами моделируем, а пользователь со своими предложениями пусть пока постоит за дверью. А ведь даже моделирование интересует не вообще, а в том аспекте, который интересует пользователя. Самолёты учитываются по-разному в бухгалтерии, КБ, аэропорту. B>Этот взгляд губителен хотя бы тем, что мы концентрируемся на предметной области, а не на тех преимуществах, которые даёт современная техника. Ведь компьютер может гораздо больше, чем делалось с помощью ручки и бумаги... Зачем же моделировать ручку и бумагу? B>Или я уделяю слишком много всему этому внимания?
ИМХО, это очень интересная тема.
Собственно, для "Философии программирования" — основная.
Что такое программирование?
Моделирование? Или что-то другое, какое-нибудь "свободное творчество"?
К слову, вопрос не новый. Прежде он часто обсуждался математиками (что такое математика ).
Отчасти, вопрос действительно философский.
По существу же дела, я с Вами не во всем согласен.
Модели бывают разные. В программировании мы (ИМХО) имеем дело с математическими моделями (иногда говорят "структурами").
Это давно устоявшееся в математике понятие. Оно означает некоторое множество объектов и набор применимых к ним отношений и операций.
Я думаю, что такие модели и имеются в виду.
Математические модели, переходя из области математики в область программирования, естественным образом становятся абстрактными типами данных (АТД, ADT). Такой подход к программированию "проповедуется" в книге Ахо, Ульмана и Хопкрофта "Структуры данных и алгоритмы".
ООП есть следующий этап развития идей, связанных с абстрактными типами данных.
Главное назначение ООП — делать системы "расширяемыми" (extensible).
Там, где расширение системы не предполагается, ООП не нужно.
Что же касается книг Буча, то согласен с Вами полностью.
Возможно, я захожу слишком далеко, но, ИМХО, это — макулатура.
Достаточно сравнить "метод" Буча и, хотя бы, метод объектно-ориентированного анализа Шлаер и Меллора.
Со стороны первого — одни словеса (видимо, обращающиеся к нашей интуиции), со стороны вторых — математически строгий метод.
Идеи книги Шлаер и Меллора "Object lifecycles: modeling the world in states" я применял на практике при разработке сложных систем реального времени (в области безопасности). Этот метод хорошо работает.
Так что программирование — все-таки моделирование, но именно математическое.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, GlebZ, Вы писали:
C>>Алгоритмическая и объектная декомпозиции — почти ортогональны, то есть C>>почти не влияют друг на друга. Соответственно при проектировании ПО в C>>ООП-стиле требуется сделать обе декомпозиции и совместить их.
GZ>Не совмещение, а последовательноть. GZ>Вопрос только в последовательности. Что сначала — объектная или алгоритмическая? Гамлетовский вопрос.
Почему же "гамлетовский"?
ИМХО, этот вопрос имеет однозначный ответ.
Сначала "объекты" (а главное — их типы). Потом алгоритмы.
Алгоритм (даже предварительный, самый общий) всегда опирается на свойства модели.
Например, пишем (на псевдокоде): Выбрать первый элемент из множества.
Это значит, что в нашей модели (даже если она существует только в нашем воображении) множество позволяет выбрать первый элемент.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
AVC,
> ИМХО, этот вопрос имеет однозначный ответ. > Сначала "объекты" (а главное — их типы). Потом алгоритмы. > Алгоритм (даже предварительный, самый общий) всегда опирается на свойства модели.
А модель опирается на use cases, каковые вполне можно считать "алгоритмами". А use cases — на роли, выделение которых, в свою очередь, снова является как бы объектной декомпозицией. Яйцо и курица в чистом виде
> Например, пишем (на псевдокоде): > Выбрать первый элемент из множества. > Это значит, что в нашей модели (даже если она существует только в нашем воображении) множество позволяет выбрать первый элемент.
Вопрос смещается в сторону того, как мы попали в место, где написано "Выбрать первый элемент из множества". Если путем определения того, что мы хотим делать на этом уровне, и "уровни" ассоциированы с действиями (алгоритмами), то, наверное, можно сказать, что алгоритмическая декомпозиция предшествовала объектной. Правда, потом мы сможем найти еще какой-нибудь предшествовавший шаг, на котором мы в первую очередь оперировали данными, а не поведением, и снова заявим о первичности объектной декомпозиции. И так, наверное, до бесконечности, потому что, по-моему, эти процессы происходят одновременно, а не последовательно.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[3]: Программирование есть моделирование реального мира
Здравствуйте, beroal, Вы писали:
B>У вас я опять вижу "модель реального мира". Я лично пляшу от пользователя. Как главбух решил — так и будет. Предметная область не играет определяющей роли. Для программиста реальный мир — сущность виртуальная.
Поверь моему огромному опыту общения с бухгалтерами их лучше вообще не слушать (вернее выслушать, что они хотят, и учитывая, что в большинстве случаев это женьщины). Но предметную область ты должен знать в определенных аспектах лучше главбуха. Никуда не деться, да и не особо и сложно.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>AVC, >> ИМХО, этот вопрос имеет однозначный ответ. >> Сначала "объекты" (а главное — их типы). Потом алгоритмы. >> Алгоритм (даже предварительный, самый общий) всегда опирается на свойства модели. ПК>А модель опирается на use cases, каковые вполне можно считать "алгоритмами". А use cases — на роли, выделение которых, в свою очередь, снова является как бы объектной декомпозицией. Яйцо и курица в чистом виде
Можно и так посмотреть.
Последовательность может быть разной.
Но логически (и в программистской практике) что-то должно быть первым.
Для программиста — это компьютер, в составе команд которого может быть, например, целочисленная арифметика или арифметика с плавающей точкой и т.д.
Грубо говоря, то, что программист пишет на ассемблере — это алгоритм.
Но для этого должен существовать компьютер.
>> Например, пишем (на псевдокоде): >> Выбрать первый элемент из множества. >> Это значит, что в нашей модели (даже если она существует только в нашем воображении) множество позволяет выбрать первый элемент.
ПК>Вопрос смещается в сторону того, как мы попали в место, где написано "Выбрать первый элемент из множества". Если путем определения того, что мы хотим делать на этом уровне, и "уровни" ассоциированы с действиями (алгоритмами), то, наверное, можно сказать, что алгоритмическая декомпозиция предшествовала объектной. Правда, потом мы сможем найти еще какой-нибудь предшествовавший шаг, на котором мы в первую очередь оперировали данными, а не поведением, и снова заявим о первичности объектной декомпозиции. И так, наверное, до бесконечности, потому что, по-моему, эти процессы происходят одновременно, а не последовательно.
Согласен.
Но, все же, я имею в виду логическую последовательность, а не психологическую.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
GZ>>Не совмещение, а последовательноть. GZ>>Вопрос только в последовательности. Что сначала — объектная или алгоритмическая? Гамлетовский вопрос.
AVC>Почему же "гамлетовский"? AVC>ИМХО, этот вопрос имеет однозначный ответ. AVC>Сначала "объекты" (а главное — их типы). Потом алгоритмы.
В большинстве случаев, структура выводится из алгоритма. AVC>Алгоритм (даже предварительный, самый общий) всегда опирается на свойства модели. AVC>Например, пишем (на псевдокоде): AVC>Выбрать первый элемент из множества. AVC>Это значит, что в нашей модели (даже если она существует только в нашем воображении) множество позволяет выбрать первый элемент.
И в зависимости от алгоритма список это массив, деревья, хэш таблицы итд.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
AVC>>Почему же "гамлетовский"? AVC>>ИМХО, этот вопрос имеет однозначный ответ. AVC>>Сначала "объекты" (а главное — их типы). Потом алгоритмы.
S> В большинстве случаев, структура выводится из алгоритма.
Возможно. Но Вы говорите о реализации (=структуре данных).
А я говорю о типе (АТД).
Это разные понятия. И те же Ахо, Ульман и Хопкрофт их отчетливо различают.
AVC>>Алгоритм (даже предварительный, самый общий) всегда опирается на свойства модели. AVC>>Например, пишем (на псевдокоде): AVC>>Выбрать первый элемент из множества. AVC>>Это значит, что в нашей модели (даже если она существует только в нашем воображении) множество позволяет выбрать первый элемент. S> И в зависимости от алгоритма список это массив, деревья, хэш таблицы итд.
Вы опять же говорите о разных реализациях.
А тип (=интерфейс) — один и тот же.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Это дзен!
