Здравствуйте, AndrewVK, Вы писали:
A>>Насчёт неизменяемости — да, это хороший выход, но в нашем случае речь шла о редакторе
AVK>А если речь о редакторе, то надо сразу определиться, может ли круг стать эллипсом. Если может — никакого класса Круг не должно быть в принципе. За ненадобностью.
Это не обход. В статически типизированных языках классификация может быть осуществлена только по статическим признакам. Если тебе нужна динамика — возьми динамический язык и все будет хорошо.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, Wolverrum, Вы писали:
W>Если так уж очень хочется именно развесистой клюквы иерархии — абстрактную фабрику, мост, интерпретатор (+ повторное использование кода) в зубы — и вперед! Задачи по этим 4 понятиям можно до пенсии сочинять, и все будут.
Понимаешь, нужно не просто продемонстрировать ООП, а продемонстрировать его преимущество над другими подходами. И тут возникает некоторый проблем — ООП хорошо рулит совсем не в задачах симуляции (это тут вообще не причем), а там где нужна сложная архитектура. А архитектура, тем более сложная, придумывается не ради самое себя, а чтобы удешевить кодирование. Удешевление же кодирования тем критичнее, чем больше размер проекта. Отсюда — ООП тем лучше себя проявляет, чем больше размер этого самого проекта. Исходя из этого, придумать маленький пример, который бы продемонстрировал преимущества ООП ох как непросто. И отталкиваться нужно, наверное, не от преимуществ ООП, а от недостатков ФП, коль скоро это основной предмет сравнения. Например ФП очень "не любит" долгоживущего изменяемого стейта. Или ввода/вывода на реальные устройства.
P.S. Разумеется, это было мое сугубое ИМХО.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
, или монады в ООП и, скажем, крестах, в частности), и посему нет особого смысла рассуждать, искать задачу в ключе "достоинства-недостатки"; кажется, важнее показать основные приемы использования, чем пытаться выяснить какой из способов написать программу лучше... Бо народ не то что в ООП/ФП — в структурном программировании "плавает" (и я, похоже, не исключение )...
Здравствуйте, andy1618, Вы писали:
A>Насчёт неизменяемости — да, это хороший выход, но в нашем случае речь шла о редакторе: "Классический пример: векторный редактор — круги, прямоугольники, эллипсы. Переопределяется рисование, изменение масштаба, повороты и т.д...".
Если фигуры изменяемые, то наследовать круг от эллипса нельзя; но дело в том, что парадокса и в этом случае нет, поскольку этот самый якобы парадокс выводится из утверждения, что "в математике круг это эллипс", а в математике фигуры неизменяемые.
Re[2]: Прав vdimas, не наследованием единым жив человек. :)
Здравствуйте, Klapaucius, Вы писали:
K>А чем описание dataflow на несколько экранов менее удобно, чем ООП код на несколько экранов?
ООП на несколько экранов тоже скорее исключение. В принипе, в графическом виде, да еще с автоматической кодогенерацией — ничем.
Ну разве что малым пока количеством устоявшихся общепризнанных примитивов, т.е. черевато потенциально слабой инкапсуляцией/декомпозицией (раздутием ф-сти слоев) и изобретением велосипедов.
Опять же — гонки! Без обрубания потоков вычислений явными состояниями все очень усложняется. Почему в электронике те же асинхронные автоматы, несмотря на их потрясающую эффективность отношения функциональность/вентиль, используются крайне редко? Просто даже среди спецов их умеют проектировать 1%, если не меньше, остальные делают "по старинке", на тактах. На тактах есть мощные мат.аппараты верификации/эмуляции, а пространство состояний асинхронного автомата, включая все возможные неустойчивые, куда как больше. На тактах ведь и проще и надежней. 99.99% всей автоматики сейчас работает потактово, а это потеря до более половины эффективности в общем случае, т.к. м/у фронтами тактовых импульсов железо тупо простаивает, "устаканивается".
А программа в общем виде (кроме случаев явного эмуляция автоматных состояний) — именно асинхронный автомат. И вот на это все навернуть автоматическое, т.е. слабоконтроллируемое распространение сигнала? Что-то мне подсказывает, что всерьез пользоваться этой технологией смогут очень немногие.
V>>Без полноценного графического инструмента, типа как редактора схем электрических функциональных, решать на этой технологии даже задачи среднего уровня — утопия.
K>Ну, если так нужен графический инструмент — это проблема чисто техническая. Визуализировать dataflow даже легче. K>Кроме того, электрические схемы ведь тоже сейчас на языках программирования описывают, разве нет?
Более-менее большие схему полностью "вручную" в тексте — такая же утопия. Обычно спец втыкает в сложную графическую схему из нескольких десятков компонентов и кучей связей за считанные минуты, парсить с той же скоростью текстовый исходник нереально (описание связей — самое нагрузочное в информационном плане). Сами редакторы обычно двусторонние или имеют ср-ва туда-сюда перегонять (ф-сть import/export), т.к. многие повторяющиеся вещи действительно быстрее набить в тексте, чем в графике, через copy&paste и edit->replace.
Ну это как набивка HTML, даже если набиваешь полностью в блокноте, то контроллируешь его постоянно в процессе работы обязательно в рендеренном виде, в выделенном суть.
Re[18]: На базе чего лучше всего продемонстрировать ООП?
Здравствуйте, vdimas, Вы писали:
V>Ну разве что малым пока количеством устоявшихся общепризнанных примитивов, т.е. черевато потенциально слабой инкапсуляцией/декомпозицией (раздутием ф-сти слоев) и изобретением велосипедов.
О, например, в узких кругах (функциональных) реактивных программистов примитивы вполне устоялись, так что с декомпозицией и инкапсуляцией все в порядке.
Это, собственно, те же примитивы, что и в ФП: аппликативные функторы, монады, стрелки.
V>Опять же — гонки! Без обрубания потоков вычислений явными состояниями все очень усложняется. Почему в элек6тронике те же асинхронные автоматы, несмотря на их потрясающую эффективность отношения функциональность/вентиль, используются крайне редко? Просто даже среди спецов их умеют проектировать 1%, если не меньше, остальные делают "по старинке", на тактах. На тактах есть мощные мат.аппараты верификации/эмуляции, а пространство состояний асинхронного автомата, включая все возможные неустойчивые, куда как больше. На тактах ведь и проще и надежней. 99.99% всей автоматики сейчас работает потактово, а это потеря до более половины эффективности в общем случае, т.к. м/у фронтами тактовых импульсов железо тупо простаивает, "устаканивается".
Ну, собственно, в ФРП первоначально была, в каком-то смысле, аналогичная модель: pull каждые x секунд, с понятными сложностями в виде низкой производительности (не все так страшно, все же: x меньше единицы) и тайм-ликов. Сейчас разрабатывают более совершенные подходы.
V>А программа в общем виде (кроме случаев явного эмуляция автоматных состояний) — именно асинхронный автомат. И вот на это все навернуть автоматическое, т.е. слабоконтроллируемое распространение сигнала? Что-то мне подсказывает, что всерьез пользоваться этой технологией смогут очень немногие.
Что-то мне подсказывает, что всерьез пользоваться этой технологией смогут очень немногие. 
