Пользователь
0,0
рейтинг
16 июля 2012 в 16:41

Разработка → Почему объектно-ориентированное программирование — это отстой

Когда я первый раз услышал об объектно-ориентированном программировании — сразу отнёсся к нему скептически. Честно говоря, даже не знаю, почему. Просто оно показалось мне каким-то неправильным. Но ООП очень быстро стало популярным (почему — я объясню ниже) и критика в его адрес превратилась в этакую «ругань в церкви». А объектно-ориентированность стала обязательной составляющей любого уважаемого языка программирования.

С ростом популярности Erlang часто стали задавать вопрос «— А Erlang — объектно-ориентированный?». Правильный ответ был бы «— Да что вы, нет!». Но мы не могли так заявлять в полный голос, поэтому пришлось выкручиваться. Мы придумали несколько достаточно нетривиальных ответов, которые бы представляли Erlang типа-объектно-ориентированным языком (для тех, кто больше всего тянет руку с этим вопросом), но при этом и не объектно-ориентированным для тех, кто на самом деле в теме.

Тут мне хотелось бы вспомнить тезисное выступление директора французского IBM на 7 конференции IEEE по логическому программированию. Он рассказал о том, что IBM добавило в Prolog достаточно много объектно-ориентированных расширений. На вопрос о причинах этого он ответил:
«— Наши покупатели хотели объектно-ориентированный Prolog, поэтому мы сделали объектно-ориентированный Prolog»

Помню, я думал «Как хорошо! Просто, никаких угрызений совести, никакого самоанализа, никаких метаний по поводу того, правильно ли так делать.»

Почему объектно-ориентированное программирование — это отстой



Мои ЛИЧНЫЕ возражения по теме ООП — это претензии к его основным положениям. Я выделю некоторые из этих положений и суть моих претензий.

Возражение №1. Структуры данных и функции не должны быть привязаны друг к другу


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

Потому что функции выполняют действия. У них есть входные и выходные значения. Входные и выходные значения — это структуры данных, которые изменяются функциями. Во многих языках функции — это последовательности императивов: «сделай то, потом сделай это». Для понимания сути функции необходимо понять порядок выполнения этих императивов (в ленивых функциональных и в логических языках порядок может значения не иметь).

Структуры данных же просто существуют. Они не выполняют никаких действий. Они исключительно декларативны. «Понимание» структуры данных в разы проще «понимания» функции.

Функции представляются чёрными ящиками, трансформирующими входы в выходы. Если я понимаю вход и выход, то я могу понять и функцию (хотя это вовсе не означает то, что я смог бы эту функцию написать).

Функции обычно «понимаются» как части вычислительной системы, передающие данные из структуры данных типа T1 в структуру данных типа T2.

Поскольку функции и структуры данных — это совершенно разные виды животных, то решение содержать их в одной «клетке» фундаментально неверное.

Возражение №2. Всё должно быть объектом


Рассмотрим «время». В объектно-ориентированном языке программирования «время» должно быть объектом. Но в необъектно-ориентированном языке «время» — это экземпляр типа данных. Для примера, в Erlang есть много разных видов «времени», каждый из которых может быть строго и однозначно определён. Например, с помощью таких определений типов:

-deftype day() = 1..31
-deftype month() = 1..12.
-deftype year() = int().
-deftype hour() = 1..24.
-deftype minute() = 1..60.
-deftype second() = 1..60.
-deftype abstime() = {abstime, year(), month(), day(), hour(), min(), sec()}.
-deftype hms() = {hms, hour(), min(), sec()}.
... 


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

Кроме того, у них нет никаких связанных методов.

Возражение №3. В объектно-ориентированных языках определения типов размещаются повсеместно


В объектно-ориентированных языках программирования определения типов данных принадлежат объектам. Поэтому я не могу найти все определения типов данных в одном месте. В Erlang или в C я могу определить все мои типы данных в одном-единственном включаемом файле или в словаре данных. В объектно-ориентированных языках программирования я этого сделать не могу — определения типов данных размещаются повсеместно.

Я приведу пример. Предположим, я хочу определить глобально видимый тип данных.

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

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

В объектно-ориентированном языке программирования я должен выбрать некоторый базовый класс, в котором я определю общеиспользуемую структуру данных. Все остальные классы, которые хотели бы использовать эту структуру данных, должны наследовать этот класс. Предположим, теперь я хочу создать объект типа «время», которому принадлежит эта структура, и в котором объект типа «время», которому… ну, вы поняли.

Возражение №4. У объектов есть скрытое состояние.


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

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

Что могут предложить языки программирования для работы с этим состоянием из реального мира?

  • Объектно-ориентированные языки программирования скажут «— Надо спрятать состояние от программиста». Состояния скрываются, доступ к ним можно получить только с помощью специальных функций;
  • Обычные языки программирования (C, Pascal) скажут, что видимость переменных состояния должна регулироваться правилами областей видимости языка;
  • Декларативные языки скажут, что состояния нет.


Глобальное состояние системы хранится во всех функциях и вытекает изо всех функций. Используются механизмы навроде монад (для функциональных языков) и DC-грамматик (для логических языков). Эти механизмы прячут состояние от программиста, позволяя ему программировать не принимая состояние во внимание, но при этом позволяя ему и получать доступ к состоянию, если в этом возникнет необходимость.

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

Почему ООП так популярно?


  • Причина 1 — все думают, что его легко изучить;
  • Причина 2 — все думают, что с его помощью можно повысить степень повторного использования кода;
  • Причина 3 — хайп вокруг ООП;
  • Причина 4 — оно создаёт Новую Индустрию Программирования.


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

Вот это — то, что реально движет объектно-ориентированным программированием.

От переводчика.
Оригинал: Joe Armstrong, взято отсюда.

Нашумевший в определённых археологическо-программистских кругах текст, написанный Joe Armstrong, автором Erlang. Дату написания текста достоверно установить не удалось, но, судя по косвенным данным, это было в начале 90х.
@80x86
карма
83,2
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (136)

  • +6
    Почему объектно-ориентированное программирование — это отстой.
    А вот не подерётесь, а вот и не будет холивара.
    • +24
      А тут и не должно быть холивора. Это перевод статьи из достаточно далёкого прошлого.
      Статья показывает спираль времени, и не более.

      А ещё она показывает метастазы лор-синдрома на хабрахабре, где вместо чтения и обдумывания принято писать весёлые комментарии и плюсовать.
      • 0
        Я не вижу смысла коментировать такие статьи с такими «кричащими» заголовками. Беглого прочтения мне достаточно. Да и смысл то, если я не согласен по всем четырём пунктам? Тут, как говорится, «кесарю кесарево».
        • 0
          Я не про вас, я про холивор, ну.
          • 0
            Ну, пардоньте :)
      • +2
        >>лор
        >>плюсовать
        Ну ты понял. Плюсодрочерство присуще как-раз таки данному ресурсу.
        • +2
          Ведущим аналитикам виднее :)
  • +23
    4 сомнительных доводов против, нет ничего идеального, и я использую ООП потому что доводов «за» куда больше четырех.
    • +7
      А такие доводы можно про все что угодно привести: «Функции отстой, когда появился ассемблер, там были лишь регистры и операторы, больше ничего не нужно, все открыто и понятно! поэтому я считаю что функции — отстой, они слишком группируют код»
      • +3
        Не поверите, но у меня отец примерно такого мнения. Он по образованию инженер-конструктор, ему схемотехника ближе и больше по душе. Поэтому программировать он может исключительно на ассемблере, а обо всём выше уровнем отзывается примерно так вот :)
        • +1
          так всегда было и будет, когда придумали ассемблер, половина говорила что это тормознутое говно и вводить двоичные коды лучше, потом придумали процедурные языки, и половина говорила что ассемблер круто, а процедурные языки — тормознутое говно. И в итоге появилось ооп =)
  • 0
    Думать надо, а не пытаться думать, перед тем как что-либо делаешь. Если руки из сами знаете откуда, то самая лучшие инструменты не помогут.
  • +8
    ну как сказать.

    ООП — это порядок. в принципе,
    можно писать и на процедурах отличный код.

    но ООП учить мыслить структурно, и заставляет тех, кто потом дописывает проект, перенимать образ мышления.

    а тех, кто способен увидеть, что вы инкапсулируете реализацию, разделяете ответственности, в обычном хорошем коде на процедурах (или функциях в простом си), единицы.

    да и потом, объект — хорошая абстракция, хороший инструмент. нужно уметь его готовить :)
    • 0
      Поддерживаю! ООП учит декомпозиции, учит уменьшению связности между кусками кода. Да, это не серебряная пуля, но плюсов у такого подхода очень и очень много. Помнится, был в универе у нас Пролог, так к концу семестра отлаживать программы, которые состояли из ~50 правил было уже почти невозможно. У каждого языка своя фича, так вот у Erlang — масштабируемость (эта та, которая меня прям сразила) за счёт функциональности языка. Это его вотчина, не надо туда лезть с ООП, «приделывать ООП к Prolog», ИМХО, глупо и бесполезно.
      • 0
        Прошу прощения, но вы здесь неточны. У эрланга прежде всего масштабируемость за счёт агентской модели (и обмена сообщениями между агентами- как следствия) и хорошей инкапсуляции понятия «адрес процесса». Без FP это сделать вполне реально, в чем-нибудь вроде мозилловского Rust, например.
    • +8
      Понимаете, тут как. Структурное мышление, декомпозиция, системный подход — это всё межотраслевые дисциплины, которые ортогональны программированию (программированию вообще и ООП — в частности) в плане образа мышления.

      И(П)П, ООП, ФП, ДП, ЛП — это всего лишь способ записи модели, построенной в голове у программиста.

      Учиться структурному мышлению по конкретной парадигме — это как обучаться языку по политическим лозунгам, написанным на нём.

      В этом плане статья очень показательна — автор критикует те моменты ООП, которые в нынешнем мире так или иначе выправлены средствами языков, которые поддерживают эту парадигму. Просто потому, что Симула, в которой эта парадигма реализовывалась, так сказать, в виде стандарта, тупо не взлетела. И Смолток, тоже, де-факто, не взлетел.

      Тому есть обширный ряд причин со своими следствиями, но это надо обсуждать отдельно.
    • 0
      >а тех, кто способен увидеть, что вы инкапсулируете реализацию, разделяете ответственности, в обычном хорошем коде на процедурах (или функциях в простом си), единицы.

      А можно пример, пожалуйста?

      P.S. Не холивара ради. Для самообразования. Честно.
  • +15
    Статья из 90-х говорите. Бьюсь об заклад, что в свое время была статья, что двигатели внутреннего сгорания — отстой.
    • +21
      Так они и сейчас отстой. У них масса недостатков! Но это совсем не повод сейчас от них отказываться.
      • +1
        Электродвигатели вот по всем параметрам круче, но сколько там десятилетий прошло до тех пор, пока первый более менее успешный электромобиль сделали и сколько еще десятилетий пройдет прежде, чем они доминировать будут?
        Всему свое время! Сейчас вот функциональные фишки тоже в мейнстримовые ЯП шагают.
        • 0
          Электродвигатели далеко не по всем параметрам круче. Скорее даже наоборот: при равной мощности и долгоиграбельности (с учётом питания) они очень сильно проигрывают ДВСам по массе и габаритам.
          • +3
            Электродвигатели по всем показателям круче ДВС.
            А вопрос питания — это не к двигателям претензии.
            • 0
              Теоретический подход.

              Там, где вопрос питания ЭД не портит идею двигателя на корню, там, конечно, ЭД используются и в хвост и в гриву.

              А там, где жёстко стоит вопрос питания, по совокупности пока что ведут ДВС и ТРД. А иногда даже самые тупые ЖРД!
              • 0
                В карьерных самосвалах как обстоит вопрос с питанием?
                • 0
                  Я вас верно понимаю: вы спрашиваете как обстоят дела с питанием в повозке грузоподъёмностью 30-120 тонн?
                  • 0
                    Именно.
                    • 0
                      Хех. По каким параметрам ЭД лучше для повозок грузоподъёмностью 300-1000 кг?
                      • 0
                        Приёмистость. Высокий момент практически на любых оборотах. Отсутствие коробки передач и потерь энергии, связанных с ней.
                        • 0
                          Стало быть, вы в курсе и принципиальных недостатков ЭД? ;-)
                          • 0
                            По сравнению с ДВС это мелочи.
                            ЭД сам по себе отличный исполнительный механизм. Его слабое распространение связано исключительно с питанием, а не с его недостатками как двигателя.
                            • 0
                              Так можно сказать про что угодно — например ДВС на водороде тоже очень хороши — мощные, экологически чистые, только вот такой объём водорода на дороге не валяется, но это не проблема движка, ага? :)))
                              Какой смысл рассматривать движок без питания? Он работает без питания? — нет! Следовательно и сравнивать нужно в комплексе!
                            • 0
                              Это сфероконь.

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

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

                              По «разумно продолжительному времени» отсекается и ЭД, и гаубица, и фугас, и троллейбусы/трамваи, если разговор не идёт о карьерных самосвалах. И только.

                              Суда ходят на мазутных (дизель-газойльных) ДВС, к слову говоря. А грузоподъёмность ведь в десятки и сотни карьерных самосвалов.
                              • –1
                                Читнул освежить память.

                                Дизель-электроходы имеют основным двигателем высокооборотный ДВС и электрическую передачу. Карьерные самосвалы так же являются «дизель-электроходами» с ДВС и электрической передачей.

                                Так что звезда ЭД как самостоятельного источника энергии блекнет чегой-та.
                • 0
                  Caterpillar 797B грузоподъемность 345 тонн. Дизель.
                  Белазы и liebherr дизель-электрические, питание электроприводов обеспечивается как раз таки за счет ДВС.
                  Холиварить на тему ЭД vs ДВС можно долго, но пока нет достаточно эффективных аккумуляторов — ДВС будет лидировать. Ну или пока нефть не кончится.
                  Ну и еще один минус в сторону ЭД — пробой обмотки — довольно таки дорогостоящий ремонт выйдет.
                  • 0
                    Ничего, аккумуляторы скоро появятся.
                    Обмотка как раз ремонтируется (если пробой вообще случится). Перемотать обмотку проще, чем менять прогоревшие части ДВС.
                    • 0
                      Сомнительно что перемотать проще, чем заменить. На самом деле если ремонт осуществлять заменой — то тут оба на равных будут примерною
            • 0
              «Реактивные двигатели делают и те и те, а цистерна топлива рядом, это уже не к двигателям претензии.»
              • 0
                Неудачная аналогия. Если продолжать, можно ещё ионный двигатель привести в пример. Тоже неудачный.
  • +2
    Не убедили. Можно повторить все 4 пункта и сказать, что это достоинства.

    Хотя я больше всего люблю Pascal…
  • +7
    > Поскольку функции и структуры данных — это совершенно разные виды животных, то решение содержать их в одной «клетке» фундаментально неверное.

    Хммм, я б сказал, что функции — это животные, а структуры данных — это еда для животных, и в каждой клетке безусловно должна присутствовать пища, причём соответствующая. Не стоит кормить корову сырым мясом, а льва — сеном.
    • +1
      Правильно. А наследник — это функция, съевшая в прошлом порцию данных и ставший после этого другим животным. (И вообще правильнее — не наследование, а эволюция. В наследовании стремятся показать эволюцию — такая метафора ближе к сути.)
  • +9
    Читал я оригинал по ссылке с хакерньюс. Не согласился.
    Лично я как раз в процессе переписывания своего проекта, который был полностью сделан в процедурном стиле, на ООП.
    Разрешите поделиться своими ощущениями.
    Конечно, без базового образования крайне сложно перейти от процедурного мышления к ООП. Я очень долго пытался, читал книги и т.п. Но в какой-то момент пришло понимание.
    И теперь я делаю проект практически заново, к старому обращаясь только как к справочнику — большая часть кода переписывается.
    Зато — ощущение такое, что проект, сделанный по принципам ООП, более логичный и простой в понимании и изменении.
    Я в одном месте поменял что-то, раз — и всё работает. И мне не надо держать в голове, или искать каждый раз, откуда какая процедура вызывается, какие там параметры в каком порядке, не надо данные из одной процедуры в другую пихать, и можно ли поменять что-то так, чтобы в другом месте не сломалось…
    Преодолев определённый размер, процедурный проект стал лапшой, которую крайне сложно распутывать.
    Собственно, ради этого и придумано ООП — части проекта мало связаны меж собой и их проще обновлять и изменять. И это главное преимущество ООП, как я его понимаю — а оно как раз в статье никак не опровергнуто.
    Поэтому сейчас я за ООП. А недостатки можно везде найти — подумаешь, откровение какое. Попробуйте предложить что-нибудь другое.
    • +2
      >>Преодолев определённый размер, процедурный проект стал лапшой, которую крайне сложно распутывать
      Т.е. по вашему процедурный код в любом случае станет лапшой, а ООП никогда лапшой не станет?
      >>ради этого и придумано ООП — части проекта мало связаны меж собой и их проще обновлять и изменять.
      Т.е. по вашему декомпозиция в процедурном стиле вообще не доступна?
      • +3
        Я не знаю, почему вы обобщаете мои слова.
        Я написал про свой проект и про свои ощущения от него.
        Общих заявлений стараюсь не делать.
      • 0
        Лапша возможна и там и там.
        Но для ООП существуют методики организации порядка (те же шаблоны проектирования), а для процедурного подхода ничего такого нет кроме интуиции программера.
    • 0
      Хорошо структурированный и написанный код везде хорош, как и в процедурном, так и в ООП.

      Иногда я пишу ООП, иногда я пишу процедурами. Это все зависит от размера проекта и дальнейшего обслуживания.
      • 0
        При очень большом объёме проекта, к какому стилю вы будете склоняться — процедурному или ООП?
        • 0
          Зависит от проекта и языка.
          • +1
            Есть такая штука, как модули, блоки и комментарии к коду, которые позволяют разносить проект даже в процедурном программировании
    • +2
      вот только автор статьи противопоставляет ООП и функциональное программирование, а не процедурное ;)
  • +17
    С нетерпением жду, статей, продолжающих цикл: «Почему императивное программирование — отстой», «Почему функциональное программирование — отстой», и завершающей цикл статьи «Почему программирование — отстой».
    • +9
      Страуструп, типичные ошибки при разработке:
      24.2.1. Отказ от классов.
      24.2.2. Отказ от наследования.
      24.2.3. Отказ от статической проверки типов.
      24.2.4. Отказ от программирования.
      24.2.5. Использование исключительно иерархий классов.
      • 0
        А он там нигде не писал про типичные ошибки в проектировании языков? :)
  • 0
    В статье многовато философии, по моему мнению. А философия плоха тем, что отворачивает взор от практики.

    1е возражение — довольно спорно. Если юзается объект, значит у него есть некоторое внутреннее состояние. Внутреннее состояние (в виде структур данных) бесполезно, если оно никак не связано с внешним миром. А связано оно через методы. Так что получается, что структуры данных и функции для работы над ними не являются абсолютно разными вещами, а скорее частями одного целого.

    С остальными аргументами более-менее согласен. Вообще приятно видеть, когда возражения против ООП адекватны, а не вытекают из непонимания концепций ООП спорящим (как на знаменитом избиении ООПшников на их же конференции).
  • +11
    Тупой код и умные структуры данных проще в обслуживании и работают стабильнее чем умный код и тупые структуры данных. Пора уже с этим смириться.
    • –5
      А что хачить проще? Хачить проще тупые стуктуры. Для прикладного программирования must have фича :)
  • +2
    Немного эмоционально, но в целом — по делу.
  • 0
    Автор гиперболизирует. Настоящая проблема в том, что универсальные языки — это отстой.

    Каждый язык должен занять свою специализированную нишу и тогда будет порядок. То, что функциональные языки можно применять при сайтостроительстве, императивные при создании баз знаний, а логические при автоматизации процессов, как раз все это приводит к хаосу и вечным багам.
    • 0
      Уточните тогда: какие языки, на Ваш взгляд, наилучшим образом годятся для сайтостроения? И также ещё: какою, на Ваш взгляд, является ниша объектно-ориентированных языков?
      • 0
        >> какие языки, на Ваш взгляд, наилучшим образом годятся для сайтостроения

        Это очевидно. Те языки, которые изначально для этого создавались (а не приросли библиотеками по мере эволюции). Тот же всеми любимый PHP.

        >>И также ещё: какою, на Ваш взгляд, является ниша объектно-ориентированных языков?

        Вопрос с подвохом. Ниша очень широкая, так как можно весь мир представить в качестве объектов наделенных методами и свойствами. Но если брать за примеры упомянутые мною сайтостроение и проектирование баз знаний, то писать рабочий код на С++ можно, но затратно по ресурсам — кроме денег уйдет просто банально много времени на «изобретение велосипедов», которые уже есть в специализированных языках.
  • +3
    Автор однобоко подходит к виденью ООП. Дескать, «код и данные вместе», «состояния есть» и т.д. Достаточно чуть более глубоко взглянуть на процесс вызова метода класса, и мы увидим, что сам по себе этот метод никакого состояния не имеет — ему на вход неявно передаётся объект this и вот с этим объектом он все операции и делает. Вот вам и отдельно данные от методов. Не хотите иметь внутренних данных в классе с методами — ну, не создавайте их там. Делайте методы статическими. Храните данные в других структурах. Не храние их вообще нигде — вычисляйте на рантайме и гоняйте между статическими методами. Передавайте туда\сюда делегаты.

    ООП даёт возможность быстрее и нагляднее моделировать реальный мир, не углубляясь в дебри логических построений. Это вот как измерить объём воды в стакане. Можно вывести через интегралы формулу объёма цилиндра, а можно взять мерную тару и перелить воду туда.
    • +6
      >Делайте методы статическими. Храните данные в других структурах.

      И получите процедурный язык :)
    • –1
      Каким объектам в реальном мире соответствуют фабрики, декораторы, визиторы?
      • +1
        первым двум — линейка сотовых телефонов, с одинаковой печатной платой внутри и разными наборами кнопок и функций.
      • +3
        У вас нарушение в логике.

        Если «ООП даёт возможность быстрее и нагляднее моделировать реальный мир», то это ещё не означает, что «ООП может моделировать только реальный мир».
        • 0
          Ничего подобного я не заявлял. И даже привёл обратные примеры.

          Мысль в том, что не всё удаётся моделировать объектами один к одному, иногда приходится создавать «нереальные» объекты.
          • +2
            По-моему вы всё-таки не понимаете.

            Тот факт, что порой приходится создавать нереальные объекты, никак не опровергает тот факт, что ООП даёт возможность быстрее и нагляднее моделировать реальный мир.
    • 0
      Функциональные, процедурные и объектные языки — на любом из них, при желании, можно писать любой из парадигм. Но ООП превратить в функциональный или процедурный — проще.
  • +1
    ООП по большому счету используется только в создании библиотек. Прикладной код вы наверное сами видели: в основном stateless сервисы, гоняющие классы без поведения (классы, вырожденные в структуры). Иногда сокрытие используется конечно же в прикладном коде, как и наследование. Но все это не критично. Копья тут ломать не обо что.
    • 0
      Зависит от сложности прикладного кода и уровня прокаченности архитектора.
      • 0
        Зависит конечно. Только скорее не от сложности, а от природы. Есть толстые домены, а есть худые. Как пишет Эванс, толстые модели обычно применяются для небольших, но сложных доменов. Для больших и сложных он сам же рекомендует некоторое сочитание ООП и компонентного подхода. На практике такого правда не видел. В huge системах я обычно видел худые модели — из за гибкости (количество багов естественно больше, но лучше как-то написать систему и отладить, чем не написать или писать слишком долго)
  • –3
    Спор ниочем. ООП — это стиль. Смешивать стили программирования — это как заправлять шубу в трусы.
    • +1
      Посмотрите Nemerle, Ruby. В смешивании ничего плохого нет.
      • 0
        Вы же не станете утверждать что Ruby — это функциональный язык. Все базовые вещи там ООП.
        Например, длина строки это метод str.length, в Erlang же функция — len(String).
        • +1
          Как-то вы слишком грубо детектите ООПнутость/функциональность языка. В Ruby всё возвращает значение, есть ФВП, можно писать достаточно большие программы без единого разрушающего присваивания.
  • –3
    Вместо того, чтобы приоткрыть состояние и минимизировать его влияние на код,

    как раз состояние скрывают, чтобы минимизировать его влияние на код (чтобы состояние вручную не правили)
    • 0
      То, что ООП скрывает состояние — это только дает иллюзию того, что с большим и несвязанным состоянием можно как-то жить. Это только усугубляет проблемы, а не решает их.

      Яркий пример — сложный UI с кучей событий, которые меняют свойства, которые в ответ на это стреляют еще события и т.п. Все моргает, добавление одного функционала ломает другой через какие-то хитрые взаимосвязи по состоянию; добавить высокоуровневые фичи типа сохранения состояния формы или undo — гигантская боль, т.к. способов работы с состоянием как с единым целым не имеется.

      Яркий контр-пример — MVC в вебе, где вроде как ООП, а стейт — почти весь в базе и каких-то относительно простых и несвязанных между собой кэшах. Объекты если и мутируют, то только для того чтобы составить через это запрос на update в базе, а потом быть выкинутыми. Т.е. MVC — это подход в ФП-стиле. В противовес MVC можно посмотреть на ASP.NET webforms и оценить масштаб боли от ФП-подхода в той же самой задаче.
      • +2
        Это не сложный UI, а кривой. Если не мешать всё в одну кучу, то ничего не моргает.
        А на счёт состояния — MVC для этого и придумали, что бы путаницы не было. Правда, его мало кто реализует нормально.
        • 0
          MVC нормально реализуют в вебе, потому что там мало внутреннего стейта и даже с ООП можно как-то более-менее отделить предметную область и функции над ней (модель), контроллер (монадические операции) и view — однонаправленные (в вебе) чистые функции из модели в html.

          В дескопных приложениях это сделать трудно потому что классические ООП-языки плохо подходят для реализации своего же самого раскрученного паттерна. В десктопе ООП-библиотеки требуют копирования стейта в их объекты, через это требуется двунаправленная синхронизация этого стейта, которая почти всегда делается тупо руками. Есть датабиндинг, который упрощает это дело, и чем более он развит, тем более это все не ООП, а reactive programming, который гораздо больше уже про ФП.
          • +2
            Всё, что вы описали для веба, верно и для клиентского ООПшного UI. Но правильно этот паттерн мало кто реализует — обычно пишут, как проще — взять и руками поля с данными связать.
            • –3
              Правильно, мало пишут. Потому что геморно, нет нормальных для этого инструментов.
      • 0
        Яркий контр-пример — MVC в вебе

        Пример некорректен. В вебе не приживаются stateful-подходы (тот же webforms), потому что сама по себе натура веба (http) — stateless. А вот в толстых клиентах подходы с состоянием как раз прекрасно работают (тот же WPF с его MVVM).

        MVC — это подход в ФП-стиле

        Это вы говорите сейчас про привычный нам всем mvc в вебе. А настоящий первый MVC — это вполне себе ООП.
        • 0
          Я специально разделил вебовский и обычный MVC, потому что это вообще две разные вещи.

          Так вот вебовский прекрасно пашет из-за того что там размазанное ООП-приемами состояние не доживает до краха несогласованности.

          А классический MVC, хоть и пытаются делать, нифига не получается. И чем дальше там уходят от ООП в сторону реактивного программирования (тот же WPF-ный датабиндинг) — тем всем становится легче. Это, конечно, обзывают свежепридуманными ООП-терминами, но это дорога в ФП-сторону.
          • 0
            Это, конечно, обзывают свежепридуманными ООП-терминами, но это дорога в ФП-сторону.

            Я, если честно, с трудом понимаю, как модель с весьма существенным количеством внутреннего состояния (и перманентными побочными эффектами) можно называть движением в сторону функционального программирования.
            • 0
              В MVVM значимое состояние отделяют от всяких button.TextColor, а состояние UI привязывают декларативно к модели. Это движение в сторону более атомарного стейта, который сложнее рассинхронизовать, и всяких декларативных замутов, усложняющих отстреливание себе конечностей.

              Если продолжить в этом направлении еще немного — получится чисто Functional Reactive Programming. Который обзовут как-нибудь типа «LINQ to DataBinding», скажут что сами это все придумали, и продолжат рассказывать какое ФП говно :)
              • 0
                … а я все равно не понимаю, как вы можете говорить о чистом ФП при наличии побочных эффектов (и не просто состояния — а общего разделенного состояния).
                • 0
                  А я не говорю о чистом ФП. Я говорю о переползании рожденных в ФП-сообществе подходов в мейнстрим.

                  Мой поинт в том, что люди говорят что ООП — это круто, тогда как все улучшения ООП-методологии с момента его изобретения заключаются в адаптации ФП-идей и послаблении всяких ООП-шных догм. Что хорошего придумали на основе прекрасной ООП-парадигмы за время ее существования?
                  • 0
                    Что хорошего придумали на основе прекрасной ООП-парадигмы за время ее существования?

                    Программирование на основе контрактов.
                    • +1
                      Роль контрактов в ФП выполняют развитые системы типов. Которые, кстати, реально работают и повсюду применяются.

                      А вот в ООП я за 7 лет промышленного программирования контракты не видел чтобы применялись.
                      • 0
                        Роль контрактов в ФП выполняют развитые системы типов.

                        И вот как развитая система типов определяет, какой набор операций может и должен совершать некий компонент?

                        А вот в ООП я за 7 лет промышленного программирования контракты не видел чтобы применялись.

                        Весь SOA, вообще-то. WSDL — это контракт. Даже интерфейс — это контракт.
                        • +1
                          Интерфейсы — это часть системы типов вообще-то. А wsdl описывает структуру данных, что тоже является частью системы типов.

                          Но в C# мы даже не можем на уровне системы типов сказать что параметр метода не может быть null. А в Хаскеле — можем. И можем даже написать имеет ли право функция делать IO. А в какой-нибудь AGDA мы даже можем сказать что функция не может возвращать не отсортированный список.

                          Да, многое чего не хватает системе типов в C#, можно проверить в рантайме. Чем и занимаются всякие контрактные библиотеки. Но это, очевидно, дает гораздо более слабые гарантии.
                          • 0
                            Интерфейсы — это часть системы типов вообще-то.

                            И что, в системе типов ФП можно определять операции над типом?

                            А wsdl описывает структуру данных, что тоже является частью системы типов.

                            Э нет. WSDL описывает операции как раз.

                            Но в C# мы даже не можем на уровне системы типов сказать что параметр метода не может быть null.

                            Это недостаток языка, а не парадигмы. Что успешно доказано наличием большого количества статических анализаторов.
                            • 0
                              >И что, в системе типов ФП можно определять операции над типом?
                              Разумеется можно, нужно, и оно именно для этого и сделано.

                              >Это недостаток языка, а не парадигмы. Что успешно доказано наличием большого количества статических анализаторов.

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

                              А в ФП это все явно, и через это просто. И в этом как раз одна из сильнейших сторон ФП. Пока люди, с переменным успехом, пытаются прикрутить хитрые статические анализаторы для обнаружения null-ов и т.п., в ФП языках оно уже есть из коробки и прекрасно пашет.
                              • 0
                                Разумеется можно, нужно, и оно именно для этого и сделано.

                                Можете привести пример, как определить набор операций для конкретного компонента (т.е., не всех операций с типом, а только необходимых компоненту)?

                                Проблема в том, что в языке, в котором парадигма допускает неявные параметры и побочные эффекты, очень сложно давать сильные гарантии на уровне системы типов.

                                Повторяю еще раз: это проблема языка, а не парадигмы. И да, неявные параметры и побочные эффекты — это не объективные недостатки, а вещи, которые не рекомендуются в ФП. И в ФП вообще они прекрасно существуют (я знаю как минимум один язык, где это можно сделать).

                                Ну и да, например в WSDL можно указать, что передаваемый объект не может быть null.
                                • 0
                                  >Можете привести пример, как определить набор операций для конкретного компонента (т.е., не всех операций с типом, а только необходимых компоненту)?

                                  В Хаскеле это позволяют делать классы типов. В C# и Java — интерфейсы.

                                  >Повторяю еще раз: это проблема языка, а не парадигмы.

                                  Неявные параметры и сайд-эффекты прямо вытекают из императивной парадигмы. А их них уже вытекает сложность статического анализа кода и куча других проблем.

                                  Идея ФП не в том, чтобы запретить стейт и побочные эффекты совсем. Без них ничего не сделать же. Идея в том, чтобы максимально локализовать их, и через это сделать предсказуемыми и управляемыми. Любая ФП-программа имеет императивный кусок, вопрос в его размере.
                                  • 0
                                    В Хаскеле это позволяют делать классы типов. В C# и Java — интерфейсы.

                                    Как это делать в ООП-языках, я понимаю. А в ФП? Я бы хотел именно пример увидеть (в идеале, конечно, на F#).
                                    • 0
                                      F# я не шарю, но там вроде те же самые интерфейсы что и в остальном дотнете.

                                      В Хаскеле похожая система:

                                      есть тип:
                                      data Person = { name :: String, age :: Integer }

                                      есть классы типов (что-то вроде интерфейсов):
                                      class Eq a where — класс типов, которые можно сравнивать на равенство
                                      equals :: a -> a -> Bool

                                      class (Eq a) => Ord a — класс типов, которые можно сравнивать на больше/меньше (от типа «наследует» Eq)
                                      lessThan :: a -> a -> Bool

                                      Мы можем реализовать Eq для Person:
                                      instance Eq Person where
                                      equals (Person name1 age1) (Person name2 age2) = (name1 == name2 && age1 == age2)

                                      Дальше мы можем требовать в любых операциях, для любых операндов, принадлежность к одному или более классов типов:

                                      printSorted :: (Ord a, Show a) => [a] -> IO() — чтобы напечатать сортированный список, надо его элементы уметь сравнивать и выводить в строку.

                                      Это очень похоже на ООП-интерфейсы, но гибче.
                                      • 0
                                        А теперь объясните мне, чем это не ООП.
                                        • 0
                                          А ты мне скажи определение ООП для начала. Так-то можно все к ООП свести.
                                          • 0
                                            Ну, так не интересно. Возьмем вики.

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

                                            instance Person — сущность, ей можно послать сообщение equals с двумя параметрами и получить ответ. Данных у нее нет, но так бывает вообще.

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

                                            Наследование есть, как мы видим на примере Eq и Ord.

                                            Но даже наличие инкапсуляции и наследования не делает язык программирования в полной мере объектным с точки зрения ООП. Основные преимущества ООП проявляются только в том случае, когда в языке программирования реализован полиморфизм; то есть возможность объектов с одинаковой спецификацией иметь различную реализацию.

                                            Это, очевидно, тоже есть — может быть больше одного instance для одного класса Eq, и они могут иметь разную реализацию.

                                            Так что формально это ООП, и от бытия ТРУ ООП его отделяет только наличие внутренних данных.
                                            • 0
                                              Хочешь я тебе точно также докажу что ассемблер — ООП-язык?
                                              • 0
                                                Не хочу. Потому и говорю, что это уже не интересно, потому что к содержанию дискуссии отношения особого не имеет.
  • –1
    > Почему объектно-ориентированное программирование — это отстой?

    А почему бы вместо того, чтоб 20 лет сотрясать воздух, не взять бы и не написать какую-нибудь вшвенькую 1С-бухгалтерию без объектов, зато на функциональном языке? Или игрушку какую в 3D?
    Сразу бы все вопросы отпали, и у тех и у других :)
    • +1
      Почему бы не построить безупречно и безотказно работающую телекоммуникационную платформу на императивном языке с ООП? :)

      Наверное потому, что каждому инструменту — своё предназначение. В этом мире даже general-purpose-языки на поверку оказываются достаточно узко заточенными.

      Ну и надо делать скидку на то, что те самые 20 лет назад стеки технологий были абсолютно другими, а ООП было на уровне концепций, местами сырых инструментов и нескольких фейлов типа современных Dart и Go.
      • –2
        > Почему бы не построить безупречно и безотказно работающую
        > телекоммуникационную платформу на императивном языке с ООП? :)

        Если Android — это платформа, а Java — это ООП, то почему бы и нет :)
        • +2
          Потому что а) вы ответили на риторический вопрос, чего делать нельзя; б) вы на него не ответили.
          • –3
            То ответил, то не ответил… Топик, вроде, не про нечёткую логику был ;)
    • –2
      Игрушку? В 3D? На функциях? Да пожалуйста!

      old.siteszone.ru/games.html

      Все кроме последней 3Dшные написаны на Делфи-движке DGLE, который правда использует кое-где классы (вроде бы внутри него таки есть классы, но я то их не использую!). Пакмэн 3дшный тоже написан без классов.

      Так что энто… уточняйте требования ;)
  • +1
    Где-то функциональный подход рулит (алгоритмы обработки потоковых данных к примеру, которые должны хорошо масштабироваться на N тредов и никакого состояния внутри особо не содержать). А есть сложные десктопные приложения, где состояние — это основное, и нужны какие-то абстракции, чтобы хранить это состояние. Не представляю себе WPF, реализованный в функциональном стиле. ООП просто сложнее приготовить правильно (зато проще сделать неправильно), это и приводит к тому, что библиотеки точатся и допиливаются годами, добиваясь смысловой целостности абстракций.
    • +2
      WPF во-первых весьма декларативен (XAML), во-вторых уже сильно ближе к ФП-стилю построения интерфейсов. Скажем развитый data binding — это движение в направлении reactive programming. А reactive programming — это как раз про то, как строить интерфейс в чистом ФП.

      Или тот же MVVC-паттерн — это попытка выделить минимально возможное состояние и положить одним куском, не размазывая по коду, что тоже весьма в ФП-духе.

      Просто ООП-шники все переназывают своими терминами, через это создается видимость что это ООП развивается и прекрасен. На деле все последние удачные движухи по поводу ООП-архитектур — это в основном перенятие кусочков ФП в ООП-мир.
      • +1
        Что ж в этом плохого? Как раз за гибридными вещами будущее и есть. Никто не будет писать десктопные приложения на чистом функциональном языке. Программистам хочется делать не только функциональные абстракции, но еще и абстракции объектов, хранящих состояние. А уж чего больше в MVC и databinding'ах — ООП или функциональщины — это еще вопрос :) Реактивное программирование, судя по вики, к функциональному программированию не относится и является обособленной парадигмой, которую использует и ООП, и ФП. Выделение минимально необходимого это не есть изобретение ФП, это перифраз бритвы Оккама, методологического принципа, используемого повсеместно.
        • +2
          Ничего плохого нет.

          Я бы даже сказал бы что термин «ООП-программирование» сейчас понимается больше как «прагматичный подход», а «ФП-программирование» — это больше даже не про ФП, это больше фронт научной мысли о программировании.

          Новые интересные идеи в основном рождаются и оттачиваются во втором, а потом те, которые себя хорошо зарекомендовали переползают в «ООП-мир», где бережно и с поправкой на реальный мир реализуются.

          Рано или поздно какой-нибудь опопсенный хаскель придет даже в enterprise-программирование, но промышленному программированию все равно придется пройти этот путь через гибридные языки.
  • –4
    ООП — не отстой, но и не панацея. ООП — всего лишь способ создания и разделения абстракций. Главные понятия — классы и объекты. Классы бывают двух видов: тип данных и средства обработки/модификации. Объекты — это экземпляры типов данных. ООП — идея о том, что можно написать код и использовать в дальнейшем. Но все учесть невозможно, поэтому и есть скрытое состояние объекта — чтобы программист не мог случайно поломать класс.
    • +3
      > Классы бывают двух видов: тип данных и средства обработки/модификации.

      Еще раз: это вырожденный случай ООП (на 90% это процедурное программирование) хоть и вполне мейнстримовый.

      > ООП — идея о том, что можно написать код и использовать в дальнейшем.

      В том, что вы описали вообще нет никакой идеи по сравнению с процедурным программированием. Хотя процедурное программирование тоже позволяет переиспользование, в этом отношении я согласен.
  • –3
    Эту тему лучше переименуйте так: Почему такие темы на хабре — это отстой?
    • +5
      Потому что 95% пользователей хабрахабра не знают Эрланг и, соответственно, не понимают, что имеет в виду товарищ Армстронг, говоря про описание типов, например.

      Потому что 70% пользователей хабрахабра про ФП знают только, что «ну, там есть функции, монады и какое-то каррирование».

      Потому что 50% пользователей хабрахабра находятся в состоянии аффекта под воздействием хайпа и всяких баззвордов с серебряными пулями.
      • 0
        Не умешь? Не нравится? Не хочешь? — Не пользуйся!
        И да, ваша статистика говно, мистер.
  • 0
    > Мы придумали несколько достаточно нетривиальных ответов, которые бы представляли Erlang типа-объектно-ориентированным языком (для тех, кто больше всего тянет руку с этим вопросом), но при этом и не объектно-ориентированным для тех, кто на самом деле в теме.

    При этом те, кто НА САМОМ ДЕЛЕ в теме, прекрасно понимают, что Эрланг — язык именно что объектно-ориентированный.
    • +2
      Эрланг использует свой своебразный ООП только на крупном масштабе, а на мелком он чисто ФП-язык. Такой подход неплохо показывает себя.

      Вообще ООП — неплохая парадигма для архитектуры приложения в крупном масштабе.

      Есть и другие подходы, когда на крупном масштабе применяются монады, data-flow, reactive programming, message bus-ы, какие-нибудь DSL или еще что-то. Тут на вкус и цвет.

      В ФП это либо эмулируется прямо в ФП-стиле, либо встраивается в язык. Но так или иначе в любой крупной функциональной программе что-то такое есть — на чистом ФП же нельзя сделать сколько-нибудь сложное приложение.

      Вопрос тут только в том, от чего начинать плясать.

      На мелком же масштабе ООП подталкивает плодить кучу ненужных сущностей, и кучу несвязанного, зачастую некогерентного стейта, а это хреново.
      • +1
        > Эрланг использует свой своебразный ООП только на крупном масштабе, а на мелком он чисто ФП-язык.

        Согласен.

        > на чистом ФП же нельзя сделать сколько-нибудь сложное приложение.

        Не согласен.
        • 0
          На ФП все так или иначе себе стейт, монады, ООП, dataflow, и т.п. Называть ли это чистым ООП потому что оно сделано на чистом ООП — вопрос риторический.
          • 0
            опечатался. «Чистым ФП потому что сделано на чистом ФП» конечно
        • +2
          >> на чистом ФП же нельзя сделать сколько-нибудь сложное приложение.
          > Не согласен.

          Чистый ФП == отсутствие побочных эффектов вообще. В частности, I/O на идеальном чистом ФП уже невозможно.
  • 0
    Алан Кей не заслужил, чтобы его изобретение называли отстоем.
    Извинитесь сейчас же!
    • +1
      Вообще говоря, «отстой» — это смягчение оригинального оборота «something sucks».
      Так что мне, например, перед Аланом Кеем точно извиняться не за что.
    • +4
      «Когда я придумал ООП, я точно не имел в виду С++» © Алан Кей

      Процессы и сообщения в Erlang'е вполне точно соответсвуют именно ООП Кея
  • –3
    У меня создалось впечатление, что автор статьи программировал в основном разнообразные вычисления и расчёты, где вся мощь ООП действительно не нужна.
    • +2
      Когда вы говорите «вся мощь ООП», что вы имеете ввиду? Для чего вам понадобилась «вся мощь ООП»?
    • +2
      Какая невнимательность, вообще то статью написал создатель языка эрланг, глупо выглядите.
  • –2
    Мне кажется, автор не программировал сколь-нибудь сложных структур данных. Красно-черное дерево это структура или функции, которые заставляют его делать свою работу и не нарушать целостность?
    • +3
      Какая невнимательность, вообще то статью написал создатель языка эрланг, глупо выглядите.
      • –1
        Был неправ, пропустил абзац об авторе.
        Впрочем автор эрланга и статьи выглядит не менее глупо, так что на сей счет я не слишком переживаю.
        Есть подозрение, что в некоторых пунктах (например в пункте про объявления типов и про популярность ООП) он говорит ООП, а имеет ввиду Java. Кто ж виноват, что не все реализации ООП прекрасны во всех отношениях? Но в конечном счете, джава не единственный ООП-язык.
        Кстати, могли бы сказать что-нибудь и по сути. Разделение структуры данных и функций с ним работающих имеет какие-то «бонусы» кроме уязвимости целостности данных?
        • +1
          Да я вообще не программист, но статью прочитал, если хотите знать моё мнение я просто Армстронгу верю больше, я за развитием эрланга слежу давно, мне он просто интересен как технология.
  • 0
    Я правильно понимаю, что в пункте 2 abstime=2012 02 31 24 60 60 является валидной датой?
    • 0
      Да, потому что они не zero-based.
  • 0
    А -то думаю, что меня в сон клонит, когда работаю с объектами! :) Спасибо за статью.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.