Здравствуйте, lomeo, Вы писали:

L>Здравствуйте, LaPerouse, Вы писали:

LP>>ООП показал в корпоративном секторе хорошие результаты. Будете спорить?

L>Я буду! Масса проваленных проектов, куча дизайн-заплаток типа паттернов — это хороший результат?

Проваленные проекты всегда будут. Паттерны — а ты думаешь, что в ФП их не будет? Это вещь, отвязанная от конкретной идеологии и существует вне ее. К тому же никак не понятно, каким образом существование паттернов может судить о пригодности/непригодности.

Здравствуйте, lomeo, Вы писали:

L>Здравствуйте, LaPerouse, Вы писали:

LP>>Тут уж был спор по этому поводу. Меня тогда не убедили — если предметная область связана с реальными физ. объектами, то ОО-дизайн приводит к лучшим результатам.

L>Ты тогда описал структуру, вместо того, чтобы описать функциональность системы. Давай я тебе тоже опишу какую нибудь функциональную структуру и скажу — вот эта структура очень плохо ложится на ОО. Ты задачу то опиши.

Паспортная система — т е информация об энергетических объектах, в виде таблиц, диаграмм и графиеских схем (редактируемых интерактивно). Т е в качестве простейшего случая — это информация об объектах, о которых я уже говорил — взаймосвязанных линиях и подстанциях.

LP>>Вот скажем, возвращаясь к теме того спора, есть у нас объект — линия электрических сетей. Начинается она с подстанции. Проблема в том, что с этой же подстанции могут начинаться много других линий. И много линий могут на ней заканчиваться. В этом случае естественно воспользоваться ОО-декомпозицией. И без ссылок тут не обойтись.

L>Естественно для кого? Возьми тот же зиппер.

Я еще не настолько хорошо разбираюсь в Хаскеле, чтобы изысками заниматься. Вот если б ты пояснил в двух словах, что это такое и как он мне может помочь сделать ОО-декомпозицию?

В общем, что мне нравится в ООП вообще и ОО-декомпозиции в часности? Это возможность быстро смоделировать предметную область стой степенью детализации. которая необходима в конкретном случае. Вот если б ФП позволил мне это сделать, да еще и декларативно, то цены б ему не было. Может ли оно это или нет — вопрос для меня.

Здравствуйте, LaPerouse, Вы писали:

LP>В общем, что мне нравится в ООП вообще и ОО-декомпозиции в часности? Это возможность быстро смоделировать предметную область стой степенью детализации. которая необходима в конкретном случае. Вот если б ФП позволил мне это сделать, да еще и декларативно, то цены б ему не было. Может ли оно это или нет — вопрос для меня.

Какая-то у тебя странная позиция, будто все тебя убеждают, что ООП — это страшное зло и ни в коем случае нельзя использовать эту каку
Скажем, вот мы с lomeo на яве пишем на своих работах и ничего — нормально
Никто же не пытается обратить тебя в Великую Веру Лямбды, если будет желание, то сам разберёшься по-моему. А если не хочешь — пользуйся ООП, если оно тебе нравится. По сути это всё лишь инструмент для решения конкретных задач и определяется выбор не абстрактной крутостью, а удобностью и выгодностью в свете конкретной ситуации.

Здравствуйте, LaPerouse, Вы писали:

LP>Проваленные проекты всегда будут.

Я даже не знаю, что на это ответить. Т.е. этот аргумент мы отметаем, как неорганизованный так что ли?
Если ФП позволит снизить (или наоборот приведёт к повышению) количество провальных проектов — разве это совсем-совсем неважно?

LP>Паттерны — а ты думаешь, что в ФП их не будет? Это вещь, отвязанная от конкретной идеологии и существует вне ее. К тому же никак не понятно, каким образом существование паттернов может судить о пригодности/непригодности.

Элементарно! Паттерны разрешают какие-то недостатки, а значит самим своим существованием высвечивают проблемы. И в ФП тоже есть паттерны, но пока не могу сказать, какие недостатки хуже "в корпоративном секторе".

А ты уже можешь?

Здравствуйте, LaPerouse, Вы писали:

LP>Паспортная система — т е информация об энергетических объектах, в виде таблиц, диаграмм и графиеских схем (редактируемых интерактивно). Т е в качестве простейшего случая — это информация об объектах, о которых я уже говорил — взаймосвязанных линиях и подстанциях.

Ну и? Действия то какие ты будешь проводить с линиями и подстанциями, потому что просто информация — это тупая декларация, которую ты уже писал. Ты же натыкался на referential transparency, значит, решал какую то конкретную задачу, отличную от просто информации. Расскажи.

LP>Я еще не настолько хорошо разбираюсь в Хаскеле, чтобы изысками заниматься. Вот если б ты пояснил в двух словах, что это такое и как он мне может помочь сделать ОО-декомпозицию?

Про зиппер тут уже писали, это чистая функциональная структура для обхода, например, дерева.
www.st.cs.uni-sb.de/edu/seminare/2005/advanced-fp/docs/huet-zipper.pdf

Нужна ли она — зависит от задачи, ты её пока не описал

Во-вторых (и это важно) — ФП не поможет тебе сделать ОО-декомпозицию. Никак. Вот ФП-декомпозицию — запросто!

LP>В общем, что мне нравится в ООП вообще и ОО-декомпозиции в часности? Это возможность быстро смоделировать предметную область стой степенью детализации. которая необходима в конкретном случае. Вот если б ФП позволил мне это сделать, да еще и декларативно, то цены б ему не было. Может ли оно это или нет — вопрос для меня.

ФП ничего не может. Могут программисты. Как ФП моделирует предметную область — я тебе уже давал несколько ссылок, если ты задаёшь вопросы — может ли оно, значит ты их не читал, нес па?

Здравствуйте, LaPerouse, Вы писали:

LP>Тут уж был спор по этому поводу. Меня тогда не убедили — если предметная область связана с реальными физ. объектами, то ОО-дизайн приводит к лучшим результатам. Вот скажем, возвращаясь к теме того спора, есть у нас объект — линия электрических сетей. Начинается она с подстанции. Проблема в том, что с этой же подстанции могут начинаться много других линий. И много линий могут на ней заканчиваться. В этом случае естественно воспользоваться ОО-декомпозицией. И без ссылок тут не обойтись.

здесь как раз обсуждается задача К. когда её решают ООП-minded люди, они представляют решение как систему объектов (таблица, ячейка, выражение), взаиможействующих некоторым образом. когда эту задачу решают fp-minded people, задача предсатвляется как набор преобразований входного формата данных в выходной, используя механизмы композиции функций, итерации коллекции, выявления циклов в графе и т.д.

далее, ОО-декомпозиция как ты её здесь используешь — это всего лишь использование ссылок для описания сложной структуры данных. пионером в этой области были как раз лисп и ipl и она не прседставляет проблемы ни для какого современного языка, включая паскаль или скажем перл

насколько я понимаю, единственная твоя загвоздка — ты привык описывать алгоритмы на эти структурах данных императивно, опираясь на понятие текущего состояния, и не умеешь их представлять как отображение входной структуры в выходную целиком. но это противоречие между императвиным и pure fp программированием, а не fp vs oop

Здравствуйте, LaPerouse, Вы писали:

LP>Здравствуйте, Курилка, Вы писали:

К>>Здравствуйте, LaPerouse, Вы писали:

К>>[cut]

LP>>>element1 и element2 имеют ссылку на один объект и обновление этого объекта приведет к актуальному обновлению зависимых объектов. В Хаскеле, не имеющим побобочных эффектов, такое невозможно (без монад). Приходится самому думать о зависимостях.

К>>А вот тут вопрос — а нужно ли такое? Чтоб были неявные зависимости, усложняющие логику нехило?

LP>Нужны. Бизнес-объекты имеют сложные зависимости by design. В корпоративке это сплошь и рядом.

Любые объекты (не только "бизнес") всегда имеют сложные зависимости по identity. В этом суть объектов — они скрывают изменяемое состояние и доступны по identity. Означает ли это, что бизнес-процессы могут быть описаны только в терминах объектов с изменяемым состоянием? Разумеется, нет. Более того, значительная часть артефактов бизнес-процесса в реальной жизни не являются мутабельными — например, все первичные документы и бухгалетрские проводки. Они делаются один раз, их провка — нештатная ситуация.

LP>Для представления любой более-менее полноценной реляционной модели в объектном виде нужны такие зависимсоти.

Выше высказывание — тафтология, для представления объектной модели лучше всего разумеется подходит объектная модель, а не какая-либо другая.

Вопрос другой — а так ли необходимо представлять полноценную реляционную модель в объектном виде? Что кроме вашей привычки (не канает) и тупости оппонентов (не советую) вы можете назвать в качестве аргумента?

LP>Конечно, если в качестве persistence layer выступает база данных, то без этого можно вроде бы как обойтись, но дизайн все равно хорошим не получится.

Пример.

Здравствуйте, LaPerouse, Вы писали:

LP>Паспортная система — т е информация об энергетических объектах, в виде таблиц, диаграмм и графиеских схем (редактируемых интерактивно). Т е в качестве простейшего случая — это информация об объектах, о которых я уже говорил — взаймосвязанных линиях и подстанциях.

во-первых, это чисто графическая система без сложных алгоритмов. удобство её реализации зависит не от языка, а от наличия удобной граф. библиотеки, средств генерации программ и т.д. лучше говорить о рещшении какой-то сложной информационной задачи, типа вычисления макс. нагрзуки для сети или оптимального распределения нагрузки и т.п.

во-вторых, я вижу здесь пару небольших, но всё же преимуществ ФП языков типа хаскела — возможность описать каждое ред-ние чистой функцией (их проще описывать и проще проверять чем update state процедуры); второе — "бесплатный undo" за счёт хранения предыдущих версий структуры данных (это дёшево, поскольку её не надо целиком копировать; кол-во копируемых при каждом ред-нии элементов — O(log N))

ну и в третьих, мой опыт говорит, что реализация польз. интерфейса — задча больше нудная, нежели сложная. реальная сложность пояавляется именно в алгоритмах обработки данных. поэтому хороший язык должен рещать именно эту проблему — облегчать написание сложных алгоритмов обработки информации, всё остальное — семечки

кстати, вспаомгнилось, что есть такая универсадбная система ред-ния графов — Graphviz. по идее вещей, нужно просто написать преобразование данных туда/сюда и правила ред-ния и перевадлить эту заботу на её плечи. как видишь, я свёл даже твою задачу к сложному алгоритму обработки данных

Здравствуйте, lomeo, Вы писали:

L>Здравствуйте, LaPerouse, Вы писали:

LP>>Проваленные проекты всегда будут.

L>Я даже не знаю, что на это ответить. Т.е. этот аргумент мы отметаем, как неорганизованный так что ли?
L>Если ФП позволит снизить (или наоборот приведёт к повышению) количество провальных проектов — разве это совсем-совсем неважно?

LP>>Паттерны — а ты думаешь, что в ФП их не будет? Это вещь, отвязанная от конкретной идеологии и существует вне ее. К тому же никак не понятно, каким образом существование паттернов может судить о пригодности/непригодности.

Паттерны не разрешают недостатки. Паттерны представляют собой наработанные шаблоны и схемы проектирования, позволяющие с минимальными издержками реализовать необходимую функциональность/поведение. Да, существование некоторых из них можно объяснить отсутствием соотвествующих возможностей в языке (сопоставление с образцом. двойная диспетчеризация). Но ведь не это главное?

L>Элементарно! Паттерны разрешают какие-то недостатки, а значит самим своим существованием высвечивают проблемы. И в ФП тоже есть паттерны, но пока не могу сказать, какие недостатки хуже "в корпоративном секторе".

L>А ты уже можешь?

Я же уже писал об этом. Только практика может все прояснить.

Здравствуйте, Курилка, Вы писали:

К>Какая-то у тебя странная позиция, будто все тебя убеждают, что ООП — это страшное зло и ни в коем случае нельзя использовать эту каку
К>Скажем, вот мы с lomeo на яве пишем на своих работах и ничего — нормально
К>Никто же не пытается обратить тебя в Великую Веру Лямбды, если будет желание, то сам разберёшься по-моему. А если не хочешь — пользуйся ООП, если оно тебе нравится. По сути это всё лишь инструмент для решения конкретных задач и определяется выбор не абстрактной крутостью, а удобностью и выгодностью в свете конкретной ситуации.

С чего ты решил, что я так думаю? Мне вообще не нравится, что ООП как парадигма основана на объектах, имеющих состояние. Вот если бы можно разложить предметную область на объекты без состояния, т е избавиться от императивности, которая вытекают от играний с состоянием, я был бы только рад. Проблема в том, что не знаю, возможно ли такое — провести четкую декомпозицию задачи на объекты без ООП. Если вы заметили, все мои сообщения как раз сводятся к этому.

Здравствуйте, lomeo, Вы писали:

L>Здравствуйте, LaPerouse, Вы писали:

LP>>Паспортная система — т е информация об энергетических объектах, в виде таблиц, диаграмм и графиеских схем (редактируемых интерактивно). Т е в качестве простейшего случая — это информация об объектах, о которых я уже говорил — взаймосвязанных линиях и подстанциях.

L>Ну и? Действия то какие ты будешь проводить с линиями и подстанциями, потому что просто информация — это тупая декларация, которую ты уже писал. Ты же натыкался на referential transparency, значит, решал какую то конкретную задачу, отличную от просто информации. Расскажи.

Какие действия? Но ведь я уже все описал. Вот есть б д. В ней — информация об энергетических объектах в сети. Нужно тупо прочитать и тупо отобразить. Способы отображения — разные — от простейшей таблицы, до сложной схемы, редактируемой в специальном редакторе. Какого-бы то не было состояния иметь не планируется — ни на клиенте, ни на сервере (не считая, само-собой, граф. объектов в редакторе). ООП здесь нужен не столько для обеспечения долгоживущих объектов, сериализуемых время от времени, а для создания именно объектной декомпозиции.

L>ФП ничего не может. Могут программисты. Как ФП моделирует предметную область — я тебе уже давал несколько ссылок, если ты задаёшь вопросы — может ли оно, значит ты их не читал, нес па?

Не читал. Времени не было. Но прочитаю при возможности.

Здравствуйте, BulatZiganshin, Вы писали:

BZ>Здравствуйте, LaPerouse, Вы писали:

LP>>Паспортная система — т е информация об энергетических объектах, в виде таблиц, диаграмм и графиеских схем (редактируемых интерактивно). Т е в качестве простейшего случая — это информация об объектах, о которых я уже говорил — взаймосвязанных линиях и подстанциях.

BZ>во-первых, это чисто графическая система без сложных алгоритмов. удобство её реализации зависит не от языка, а от наличия удобной граф. библиотеки, средств генерации программ и т.д. лучше говорить о рещшении какой-то сложной информационной задачи, типа вычисления макс. нагрзуки для сети или оптимального распределения нагрузки и т.п.

Сложных алгоритмов нет. Но задача совсем не так проста, как кажется.

BZ>во-вторых, я вижу здесь пару небольших, но всё же преимуществ ФП языков типа хаскела — возможность описать каждое ред-ние чистой функцией (их проще описывать и проще проверять чем update state процедуры); второе — "бесплатный undo" за счёт хранения предыдущих версий структуры данных (это дёшево, поскольку её не надо целиком копировать; кол-во копируемых при каждом ред-нии элементов — O(log N))

Т е каждое редактирование — это функция, которая просто пишет напрямую в б д без всякой промежуточной модели?

Здравствуйте, LaPerouse, Вы писали:

LP>Паттерны не разрешают недостатки. Паттерны представляют собой наработанные шаблоны и схемы проектирования, позволяющие с минимальными издержками реализовать необходимую функциональность/поведение. Да, существование некоторых из них можно объяснить отсутствием соотвествующих возможностей в языке (сопоставление с образцом. двойная диспетчеризация). Но ведь не это главное?

Главное — понятие относительное Если в ФП та же задача решается естественно безо всяких паттернов, не говорит ли это о том, что в ОО это недостаток?

LP>Я же уже писал об этом. Только практика может все прояснить.

О том и речь! Поэтому не стоит так категорично

Здравствуйте, LaPerouse, Вы писали:

LP>Какие действия? Но ведь я уже все описал. Вот есть б д. В ней — информация об энергетических объектах в сети. Нужно тупо прочитать и тупо отобразить. Способы отображения — разные — от простейшей таблицы, до сложной схемы, редактируемой в специальном редакторе. Какого-бы то не было состояния иметь не планируется — ни на клиенте, ни на сервере (не считая, само-собой, граф. объектов в редакторе). ООП здесь нужен не столько для обеспечения долгоживущих объектов, сериализуемых время от времени, а для создания именно объектной декомпозиции.

А в чём там проблема с алгебраическими типами данных?

Здравствуйте, Gaperton, Вы писали:

LP>>Нужны. Бизнес-объекты имеют сложные зависимости by design. В корпоративке это сплошь и рядом.

G>Любые объекты (не только "бизнес") всегда имеют сложные зависимости по identity. В этом суть объектов — они скрывают изменяемое состояние и доступны по identity. Означает ли это, что бизнес-процессы могут быть описаны только в терминах объектов с изменяемым состоянием? Разумеется, нет.

Это вопрос меня сильно интересует. Я его уже задал в соседней теме про задачу К. Если бы кто-нибудь подсказал способ разрабатывать в терминах объектов, но без осточертевшего состояния, мне бы этого хватило. Сейчас читаю по ссылками lomeo, может, ситуация прояснится.

Более того, значительная часть артефактов бизнес-процесса в реальной жизни не являются мутабельными — например, все первичные документы и бухгалетрские проводки. Они делаются один раз, их провка — нештатная ситуация.

Мотивов для использования ООП может быть в этом случае 2
1. Наличие мутабельных объектов. которые интенсивно меняются/взаймодействуют с пользователем-средой-внешним миром.
2. Проведение декомпозиции с целью представления исходных физических объектов в виде объектной модели.

В случае с документами первое вроде бы как отпадает (хотя тоже не факт). Но вот со вторым что будем делать?

LP>>Для представления любой более-менее полноценной реляционной модели в объектном виде нужны такие зависимсоти.

G>Выше высказывание — тафтология, для представления объектной модели лучше всего разумеется подходит объектная модель, а не какая-либо другая.

G>Вопрос другой — а так ли необходимо представлять полноценную реляционную модель в объектном виде? Что кроме вашей привычки (не канает) и тупости оппонентов (не советую) вы можете назвать в качестве аргумента?

Ну люблю я объекты. Может, программистом-то я стал из-за того, что мне нравится переводить физ. объекты из предметной области в работающую модель? Если бы я еще получил способ отправить на свалку сопутствующую этому императивность, жить стало бы легче А при виде процедуры, которая колбасит черт-знает-что в хрен-знает-что мне тошно становится. Объекты нужны.

LP>>Конечно, если в качестве persistence layer выступает база данных, то без этого можно вроде бы как обойтись, но дизайн все равно хорошим не получится.

G>Пример.

Я бы залил сюда половину проекта, который поддерживаю, да только тогда рассуждать о проблемах пограммирования уже придется в другом месте... Там как раз применен грубый способ — трансформация представления документа напрямую в реляционную модель (и наоборот) посредством наборов ф-ций с sql и алгоритмами преобразования данных из одного формата в другой. Без всякого ОО-прослойки. Так вот, любой, кто увидел бы эту хрень, восстал бы против этого. Заметь. в качестве альтернативы я совсем не предлагаю отказываться от б д и вносить еще какое-то висящее состояние. ООП я хочу применить собственно для составления фреймворка, который будет осуществлять эту перегонку, функциональным, по сущетсву способом.

PS проект — J2EE.

Здравствуйте, lomeo, Вы писали:

L>Здравствуйте, LaPerouse, Вы писали:

LP>>Какие действия? Но ведь я уже все описал. Вот есть б д. В ней — информация об энергетических объектах в сети. Нужно тупо прочитать и тупо отобразить. Способы отображения — разные — от простейшей таблицы, до сложной схемы, редактируемой в специальном редакторе. Какого-бы то не было состояния иметь не планируется — ни на клиенте, ни на сервере (не считая, само-собой, граф. объектов в редакторе). ООП здесь нужен не столько для обеспечения долгоживущих объектов, сериализуемых время от времени, а для создания именно объектной декомпозиции.

L>А в чём там проблема с алгебраическими типами данных?

Да вроде бы оно самое то. Только вот невозможность иметь на один и тот же объект ссылки из разных мест объектов мешает. Неужто, если бы эти ссылки разрешили, но сделали немутабельными, это привело бы к императивности? По-моему, нет. Могу примеры привести. как я это себе представляю.

PS За ссылки спасибо, сейчас читаю.

Здравствуйте, LaPerouse, Вы писали:

LP>Сложных алгоритмов нет. Но задача совсем не так проста, как кажется.

и что в этой задаче сложного?

BZ>>во-вторых, я вижу здесь пару небольших, но всё же преимуществ ФП языков типа хаскела — возможность описать каждое ред-ние чистой функцией (их проще описывать и проще проверять чем update state процедуры); второе — "бесплатный undo" за счёт хранения предыдущих версий структуры данных (это дёшево, поскольку её не надо целиком копировать; кол-во копируемых при каждом ред-нии элементов — O(log N))

LP>Т е каждое редактирование — это функция, которая просто пишет напрямую в б д без всякой промежуточной модели?

ага. бд. реляционка? действительно, без ООП лекомпозиции здесь никак не обойтись

в таком варианте, каждое ред-ние отображается в sql-операцию

кстати, вспомнил, как я в 90-х годах принимал участие в разработке очередной бух.системы. её дизайн был просто верхом искусства — каждый реестр представлялся sql-запросом, которые могли включать и десяток таблиц, и все операции сводились либо к добавлению данных в эти (обновляемые) запросы, либо к показу выборок из них. вся система была чётко структурирована на три уровня — системный, которым я занимался, обеспечивал открытие нужных запросов/формочек. прикладной, которые делали люди, разбирающиеся в бухучёте — описание соответствующих sql-запросов. и "украшательский" — рисование формочек и отчётов на базе готовых запросов.

единственным недостатком этой системы, написанной на access, была её чудовищная медлительность. проводка (перевод денег со счёта на счёт) вносилась в базу 2 минуты!

думаю, это как раз отличный пример того, как работа с состояниями была отображена в высокоуровневый sql-based подход, а сама система разделена на независимые уровни, разработчикам которых не требуется ни лишней квалификации, ни зависимости от разработчиков других уровней

Здравствуйте, lomeo, Вы писали:

L>Здравствуйте, <Аноним>, Вы писали:

А>>Как только я увижу такой редактор, сразу же на него перейду. Проблема в том, что пока не знаю такого редактора, который поддерживал бы хаскель, был и под windows, и в nix-ах. Банальная расцветка кода не устраивает, нужно, чтобы был оутлайн, как в haskell-mode. Или go to definition (что даже лучше). Вот Visual Haskell (плагин к студии) по возможностям как нельзя более устроил бы.

L>Сходу приходит в голову
L>Эклипс + eclipsefp

Я видел эту штуку, но не понравилась. Еклипс — слишком неповортливая среда для того, чтобы терпеть тормоза при столь низкой функциональности плагина — это раз. Там есть глюки в синтаксическом анализаторе (antlr) — это два. И поскольку функциональность этого тула не выше, чем у haskell-mode, а удобство работы с последним удалось довести до приемлего состояния, то дергаться в его сторону пока не стоит.

Кстати, в новой версии haskell-mode тоже нет пo to definition? А то я использую старую версию плагина, где этой возможности нет, очень неудобно.

Здравствуйте, Gaperton, Вы писали:

G>Вопрос другой — а так ли необходимо представлять полноценную реляционную модель в объектном виде? Что кроме вашей привычки (не канает) и тупости оппонентов (не советую) вы можете назвать в качестве аргумента?

Кроме того, при условии осуществления декомпозиции на некотором уровне детализации, нам становятся с помощью полученного фреймворка доступны вариации в поведениях объектов. Давайте рассмотрим предельный случай — нам удалось реализовать модель подстанции с с точностью до элементарных частиц, ее образующих. Само собой, что такая наша модель в случае чего и споет, и спляшет. Она абсолютно устойчива к изменяющимся условиям — до той поры, разумеется, пока эти условия не вступают в противоречие с самой природой объекта. Осуществление детализации на таком уровне невозможно, а самое главное, не нужно. Достаточно подобрать какой-то определенный уровень детализации представления объекта, и нам становятся доступен определенный диапазон возмущений, которые наша модель выдержит без тотального рефакторинга. Это напоминает работу супергетеродинного приемника — чем выше селективность, тем ниже мощность приема.
В случае же ваших процедур — когда одна непонятная хрень преобразуется по черт-те знает каким правилам в другую непонятную хрень — о какой устойчивости к возмущениям вообще может идти речь? Стоит только измениться, скажем, способу питания катушек трансформаторов — как придется разгребать кучу говнокода, причем еще непонятно, изменение какой функции приведет к требуемому результату. А в случае модели я просто дергаю нужное оборудование и делаю примерно тоже самое, что делает в жизни электромонтер. Наивный ООП, скажете? Но черт возьми, это реально работает. Проверено на практике.

Здравствуйте, LaPerouse, Вы писали:

LP>В случае же ваших процедур — когда одна непонятная хрень преобразуется по черт-те знает каким правилам в другую непонятную хрень — о какой устойчивости к возмущениям вообще может идти речь? Стоит только измениться, скажем, способу питания катушек трансформаторов — как придется разгребать кучу говнокода

а теперь ты путаешь ООП и энкапсуляцию. исторически же как раз функциональный подход был одним из первых способов изолирования частей программы и разбиения её на соабо-связанные куски кода. ООП — частный случай ФП, когда некий набор функций и данных объявляется объектом, и все остальные способы декомпозиции эмулируются через объекты — модульность через синглетоны, higher-order funcs — через функторы, фабрики, делегаты, акторы и т.д.