Но я подозреваю что «примеры слишком маленькие, мощь ООП раскрывается на масштабных проектах» и «просто автор примеров плохо знает ООП и его код плох».
Я не говорил что любая штука на ООП многословна и запутана. Но исходя из опыта я считаю что чаще всего это так. Как минимум ещё несолько человек считают так же. При желании посмотрите ссылки что привели комментаторы выше, очень интересный материал.
— Жизнь похожа на чашку чая.
— Почему?
— Хрен его знает, я же не философ (с)
Я думаю это плохо если в основе технической дисциплины лежат философские рассуждения.
Я не разделяю их, но это уже не существенно.
Может меня и окружают «объекты». Но моя кружка с чаем не может питься сама. И дверь не может открываться сама. И справочник не может искать сам в себе.
И кружка у меня в уме не наследуется от «общего класса посуда». Скорее зависимости от ситуации она обладает свойствами посуды, керамического изделия, хрупкого предмета (type classes).
> ИМХО, скрыть состояние пытается ФП а не ООП. ООП только разделяет его на части, структурирует. Но не скрывает. А вот ФП да — скрывает, и делает вид, что состояния нет.
Как раз ФП кардинально от него избавляется везде, где это возможно. А где нельзя делает состояние более явным.
Про MVC ничего не могу сказать. Пожалел я своё время чтобы разобраться с этой штукой. Поэтому интерфейс рендерил библиотекой на MVC, а вот прикладную задачу решал по-простому. Рендерил рабочий экран САПР с железками, динамическими размерами и прочими объектами.
Очень правильно излагаете мысли. Не могу не согласиться со всеми пунктами, кроме двух.
> Изменяемое состояние, видимо, появилось впервые в ООП (-:
Но именно ООП пытается скрыть это состояние. Оно не просто пытается бороться с этими побочными эффектами, оно предлагает просто прикрыть эти побочные эффекты, чтобы было «незаметно».
> В общем описании получается действительно нелепая задача — зачем, например, просить объект класса DocumentBuilder — т.е. XML parser — отрендерить себя в HTML? Что вообще требовалось достичь?
В теж же случаях, когда в задаче есть смысл — например мы хотим отобразить в HTML тот же календарь — мы опять вспоминаем об MVC.
Именно в задаче рендеринга лично я однажды остро ощутил слабость ООП. Предположим у нас есть несколько объектов, которые нужно рендерить. Для рендеринга есть специальное api — система рендеринга. Делать методы render() для всех объектов как-то неправильно, т.к. объект «календарь» или «граф связей» ничего не должны знать о том, как рендеринг происходит. Но если создавать класс «система рендеринга», то на вход ему нужно передавать все поля отрисовываемых объектов. Либо эти объекты целиком, но давать системе рендеринга доступ ко всем полям этих объектов. Оба этих способа оставляют ощущение «неправильности».
В общем, эта задача вырождается в типично функциональную. Есть значения разных типов(сложные значения в виде структур) — передаём их на вход функции рендеринга. И все счастливы.
Ещё общая мысль, не связанная с сабжем. Зачем объединять данные и функции в классы и объекты? Никогда этого не понимал и не понимаю до сих пор. Просто набор структур и обрабатывающие их функции прекрасно себя чувствуют просто сгруппированными вместе в одном модуле. Или даже не в одном модуле. Почему-то не видел чтобы этот простой вопрос где-то поднимался. Новичкам в программировании сразу предлагают руководства в стиле «ООП это круто. Итак, ООП это ...». Вопрос «почему круто?» остаётся без ответа и потихоньку забывается к тому моменту, когда программист добирается до template <class AtomicType, template class Unit> class GenScatterHierarchy: public Unit…
Я вот тоже от него хочу отойти но не получается сделать это там где оно навязывается.
Что мешает?
Как правило, парадигмы и подходы в компаниях налагаются техническими руководителями. И тут действительно против не пойдёшь. Но есть же другие компании.
Я думаю, стоит уходить из компаний где не нравится в те, которые нравятся. Пока в России такое не очень возможно. Так как за работу очень сильно держатся и частая смена работы не приветствуется.
Но в Долине, например, смена работы раз в год это норма. Так, выбором компании, можно косвенно проголосовать за парадигму или за определённый ЯП.
Я бы поддержал своей работой компанию, занимающуюся разработкой на Haskell. Но, пока приходится просто не программировать =)
Любая штука работает на ООП. Проблема в том, что код при этом многословен и запутан. По сравнению с другими парадигмами. Нет ни одного примера «тут не работает, а вот тут работает».
Заглянул в шкаф и уже не нашёл своей первой книги по паскалю.
Там во введении было написано «выдвинутый в 70-х лозунг 'программирование — вторая грамотность' теперь уже не актуален, т.к. этот вид деятельности переходит исключительно к профессионалам».
Самое сложное в этом редакторе это установить его.
> cabal update
> cabal install yi
…
cabal: Error: some packages failed to install:
hint-0.3.3.4 failed during the building phase. The exception was:
ExitFailure 1
yi-0.6.5.0 depends on hint-0.3.3.4 which failed to install.
Но я подозреваю что «примеры слишком маленькие, мощь ООП раскрывается на масштабных проектах» и «просто автор примеров плохо знает ООП и его код плох».
— Почему?
— Хрен его знает, я же не философ (с)
Я думаю это плохо если в основе технической дисциплины лежат философские рассуждения.
Я не разделяю их, но это уже не существенно.
Может меня и окружают «объекты». Но моя кружка с чаем не может питься сама. И дверь не может открываться сама. И справочник не может искать сам в себе.
И кружка у меня в уме не наследуется от «общего класса посуда». Скорее зависимости от ситуации она обладает свойствами посуды, керамического изделия, хрупкого предмета (type classes).
Я считаю редко. Надо каждые полгода постить.
Как раз ФП кардинально от него избавляется везде, где это возможно. А где нельзя делает состояние более явным.
Про MVC ничего не могу сказать. Пожалел я своё время чтобы разобраться с этой штукой. Поэтому интерфейс рендерил библиотекой на MVC, а вот прикладную задачу решал по-простому. Рендерил рабочий экран САПР с железками, динамическими размерами и прочими объектами.
> Изменяемое состояние, видимо, появилось впервые в ООП (-:
Но именно ООП пытается скрыть это состояние. Оно не просто пытается бороться с этими побочными эффектами, оно предлагает просто прикрыть эти побочные эффекты, чтобы было «незаметно».
> В общем описании получается действительно нелепая задача — зачем, например, просить объект класса DocumentBuilder — т.е. XML parser — отрендерить себя в HTML? Что вообще требовалось достичь?
В теж же случаях, когда в задаче есть смысл — например мы хотим отобразить в HTML тот же календарь — мы опять вспоминаем об MVC.
Именно в задаче рендеринга лично я однажды остро ощутил слабость ООП. Предположим у нас есть несколько объектов, которые нужно рендерить. Для рендеринга есть специальное api — система рендеринга. Делать методы render() для всех объектов как-то неправильно, т.к. объект «календарь» или «граф связей» ничего не должны знать о том, как рендеринг происходит. Но если создавать класс «система рендеринга», то на вход ему нужно передавать все поля отрисовываемых объектов. Либо эти объекты целиком, но давать системе рендеринга доступ ко всем полям этих объектов. Оба этих способа оставляют ощущение «неправильности».
В общем, эта задача вырождается в типично функциональную. Есть значения разных типов(сложные значения в виде структур) — передаём их на вход функции рендеринга. И все счастливы.
Ещё общая мысль, не связанная с сабжем. Зачем объединять данные и функции в классы и объекты? Никогда этого не понимал и не понимаю до сих пор. Просто набор структур и обрабатывающие их функции прекрасно себя чувствуют просто сгруппированными вместе в одном модуле. Или даже не в одном модуле. Почему-то не видел чтобы этот простой вопрос где-то поднимался. Новичкам в программировании сразу предлагают руководства в стиле «ООП это круто. Итак, ООП это ...». Вопрос «почему круто?» остаётся без ответа и потихоньку забывается к тому моменту, когда программист добирается до template <class AtomicType, template class Unit> class GenScatterHierarchy: public Unit…
Большинство разработчиков Haskell работают в Microsoft Research.
И всё функциональное, что можно прикрутить к .Net, они прикручивают в языке F#. Не имею дел с .Net, но мне кажется что F# не такая уж плохая штука.
Что мешает?
Как правило, парадигмы и подходы в компаниях налагаются техническими руководителями. И тут действительно против не пойдёшь. Но есть же другие компании.
Я думаю, стоит уходить из компаний где не нравится в те, которые нравятся. Пока в России такое не очень возможно. Так как за работу очень сильно держатся и частая смена работы не приветствуется.
Но в Долине, например, смена работы раз в год это норма. Так, выбором компании, можно косвенно проголосовать за парадигму или за определённый ЯП.
Я бы поддержал своей работой компанию, занимающуюся разработкой на Haskell. Но, пока приходится просто не программировать =)
Сравните бенчмарки бинарников, генерируемых ghc, с производительностью программ на java, python, c. Будете удивлены.
Если мы копируем большую структуру, а потом никогда не пользуемся оригинальной, компилятор сам где-то там внутри просто меняет ссылки.
Если мы копируем большую структуру, а потом изменяем чуть-чуть, копилятор сохраняет для новой структуры только эти маленькие изменения.
Реализации намного эффективнее чем можно представить. Сравните бенчмарки бинарников(!), генерируемых ghc с java, python, c. Будете удивлены.
Там во введении было написано «выдвинутый в 70-х лозунг 'программирование — вторая грамотность' теперь уже не актуален, т.к. этот вид деятельности переходит исключительно к профессионалам».
Даже если этот продукт сделан неправильно, никому не нужен и намного хуже аналогов.
«Как же так, столько пахать и всё равно автор не я?»
> cabal update
> cabal install yi
…
cabal: Error: some packages failed to install:
hint-0.3.3.4 failed during the building phase. The exception was:
ExitFailure 1
yi-0.6.5.0 depends on hint-0.3.3.4 which failed to install.
Попробую ещё через годик другой, а пока vim…