Pull to refresh

Comments 67

Судя по всему, потому что для дяди Боба полиморфизм — это прежде всего удобство не возиться с указателями. Думаю, чтобы прочувствовать эту точку зрения, нужно написать много кода на чистом C.
Так-то понятно, что он имел в виду. Но зря не уточнил, как мне кажется. Особенно странно выглядит на фоне сравнения с динамически-типизированными языками, где полиморфизм (в смысле применения одного и того же кода к объектам разного типа) получается сам.
Зависит от языка. В кложуре к примеру не было. Там вообще типов нет, есть что-то типа свича на паттерн матчинге. Там это гордо называют полиморфизмом, но к классической дефиниции полиморфизма (запуск разных функций в зависимости от типа данных) это отношения мало имеет. Настоящий полиморфизм там сделан через интерфейсы (протоколы) но эта фича там недавно появилась.
Не знаю, будет ли для вас это определение достаточно классическим, но я его не сама придумала, а взяла из книжки Б. Пирса «Типы в языках программирования» (перевод на русский, с. 354):

Термин полиморфизм (polymorphism) обозначает семейство различных механизмов, позволяющих использовать один и тот же фрагмент программы с различными типами в различных контекстах.

У вас же та же самая ошибка, что и у дяди Боба в статье: вы считаете только один из видов полиморфизма «настоящим». То, какой именно полиморфизм дядя Боб имеет в виду, понятно из контекста, так что это больше занудство. Но то, что он это не уточнил, глаз сразу режет.

Там вообще типов нет, есть что-то типа свича на паттерн матчинге.

Звучит примерно как «да у них денег нет, они карточкой заплатят». Есть в Clojure типы, просто они не проверяются статически.
Это вы тоже самое мне сказали про полиморфизм что и я, только со с точки зрения пользователя полиморфизма а не реализации.

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

Если бы не одно но — они, напару с Фаулером, этот свой гуманитарный рак мозга, на целую индустрию распространили.
Гуманитарии — это классные ребята, которые хорошо понимают в лингвистике, философии, истории, литературе и других соответствующих областях. Не понимаю, за что вы их так.
Видимо, имеется в ввиду, что им не следует писать о разработке. Хотя, конечно, к автору статьи это не относится

… а почему им не следует писать о разработке?

Простите, а что конкретно гуманитарного вы видите в том, что пишут Мартин и Фаулер?

Давай от противного. Что научного в том, что пишут Мартин и Фаулер? Понятие ООП — не определено формально. Свои утверждения они нигде и никогда никак не доказывают — ни методами естественных наук (статистические исследования), ни формально-математически.

Т.е. я открываю Фаулера, читаю что Rich лучше Anemic, но не вижу нигде даже попытки доказать почему. Есть график — типа Anemic на сложности загибается. Но откуда он его нарисовал, а? Да он его придумал из головы, когда писал книжку.

В этой статье — вообще софистика: автор переопределяет определения ООП и ФП как ему удобно, и начинает сравнивать только что выдуманные концепции.

Но там видно, что это он не со зла — он просто вообще не понимает чего несет, вот и всё.
У него консалтинговая компания. Есть клиенты, вероятно собирают статистику. Если бы совсем не работало, наверное со временем его услугами перестали бы пользоваться. С моим опытом большинство утверждений Фаулера согласуются. Конкретные цифры конечно подтвердить не могу.
Давай от противного. Что научного в том, что пишут Мартин и Фаулер?

Подождите, а я где-то утверждал, что работы Мартина и Фаулера научны? Я всего лишь спросил, почему вы считаете их гуманитарными.

Самое лучшее из всех доказательств есть опыт.
Бэкон Ф

ни методами естественных наук (статистические исследования), ни формально-математически.

Проблема в том, что проводить статистические исследования в software engineering очень дорого, поэтому их особо никто не делает.
Я с вами полностью согласен, такой мути как эти ребята мало кто пишет. Но у Боба есть несколько хороших идей которые кочуют из статьи в статью, но не имея опыта читателю легко принять за чистую монету всякую кашу типа солида. Фаулер же рассуждает как новичок, прочитавший кучу книг по паттернам и судя по всему он вообще мало кодит, занимаясь консалтингом и преподаванием (развешиванием лапши).

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

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

… тот факт, что он написал книгу по паттернам, которую читают новички, вас не смущает?

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

Вы, наверное, хотели сказать "при неправильном применении"? Потому что весь смысл паттерна в том, чтобы упростить код, решающий конкретную задачу.


(еще неплохо бы посмотреть на год написания PoEAA)


Современная разработка сфокусирована на дата классах, иммутабельности и переиспользовании кода в функциональном стиле.

Вот прямо вот вся? Откуда дровишки?


Фаулер со своими паттернами ооп и анемичными классами выглядит просто нелепо.

… или нет. Если понимать контекст утверждения.


Он к стати недавно написал про датаклассы, но статью про анемичные классы так и не удалил

А должен был? Анемичная доменная модель — это анемичная доменная модель, датаклассы — это датаклассы, зачем их путать?

Да почитайте вы Фаулера хоть прежде чем бросаться его защищать. martinfowler.com/bliki/CodeSmell.html

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

Поработайте в командах от 30-и программистов с агайлом и скрамами, чтобы прочувствовать всю глубину говнокода который можно намаслать со всякими умными паттернами. Такой опыт немного отрезвляет и спускает с облаков с радугами, пони, Фаулером и Бобом, солидом и оопаттернами.

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

Не мутабельность, а неидемпотентность.

Для каких паттернов мутабельность является неотъемлимым свойством?
Как SOLID мешает вам писать нормальный код в средненькой по размеру команде?
Почему вы считаете, что только у вас есть опыт работы в такой ситуации — или что он у всех отрицательный?
Визитор, итератор, мвп итп.

Мне никак солид не мешает, я на него ложил. Или клал, я хз как сегодня правильно. Просто его определение слишком размыто для практического применения.

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

Здесь, наверное, стоит уточнить: "надежность в ООП вами достигается в результате сверхусилий, и такой код вам крайне трудно рефакторить", да?

Нет, не стоит. К таким выводам пришли большинство известных мне разработчиков, которые знают больше чем ооп.

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

Окей, заменяем "вами/вам" на "большинством/большинству известных вам разработчиков". Так правильно?


А вы знаете хоть один фп язык?

Да.


И чем фп хуже исходя из вашего богатейшего опыта?

А я где-то говорил, что ФП чем-то хуже?

Visitor — описывает процесс, который не подразумевает мутабельного состояния. Если оно вам необходимо, вы его инкапсулируете, и отдаёте только по результатам работы. Можете его сделать даже иммутабельным, никто не мешает.
Iterator — какую его часть вы называете мутабельным состоянием? А, главное, как вы к нему хотите получить доступ?
MVP — как вы пишете иммутабельный UI, расскажите пожалуйста.

Ну и размытое определение SOLID это пять.
UFO just landed and posted this here
Да почитайте вы Фаулера хоть прежде чем бросаться его защищать

Вообще-то, я достаточно много его читал. И что?


Да-да конечно, только при неправильном использовании паттерны приводят к проблемам.

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


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

Давайте откажемся от ООП, для которого мутабельность и связывание кода с данными — основополагающие свойства (окей, не неотъемлимые, но существенные)?


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

Поработайте в той же команде, чтобы понять всю глубину говнокода, который можно намаслать со всякими умными компьютерами. Компьютеры на выброс, да?


У меня начинает создаваться ощущение, что вы не вполне понимаете, что такое, собственно, паттерн в программировании (те, которые Design Pattern). Как вы это определяете?

>Давайте откажемся от ООП
Если что, все давно уже отказались от ООП в том виде, в котором он изначально продавался — где белочки от зайчиков наследуются, а счета Алисы и Боба — отдельные объекты.

Сейчас ходу подход на смеси ФП и процедурного программирования — stateless-сервисы колбасят DTO-шки. Да, формально это ООП — т.к. под определение «все есть объект» подходит вообще всё. Но индустрия давно переболела идеями типа Rich Data Model. По факту ООП там-сям имеется, но концептуально идея ООП — давно провалилась с треском.

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

Посмотри тот же SICP — там про ООП только одна глава из пары десятков. Вот эти 20 раз — это как раз тот порядок, на который ООП-шники ограничивают свой кругозор.
Если что, все давно уже отказались от ООП в том виде, в котором он изначально продавался — где белочки от зайчиков наследуются, а счета Алисы и Боба — отдельные объекты.

… а где вы взяли такое ООП? Я его никогда не видел.


Но индустрия давно переболела идеями типа Rich Data Model. По факту ООП там-сям имеется, но концептуально идея ООП — давно провалилась с треском.

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


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

А кто-то где-то говорил, что надо читать только Фаулера?

Из моей практики то, о чём вы говорите — было верно на 2010 год. Тогда в ходу действительно была в основном анемичная модель Кстати, по моим воспоминаниям Фаулер в своём PoEA вполне себе описывал целиком ту модель, которую вы сейчас с восторгом описываете. Это 2002 год, если что.
Я бы сказал, что именно в последние пару-тройку лет Rich Data Model снова начала набираться популярность, на фоне всяких Domain Driven Design и прочих радостей. Просто то же DDD советуют применять только если у вас высоко профессиональная команда, иначе придётся собирать грабли.
Хотя у того же Фаулера подходы без использования RICH
Хотя всем уже давно пора убрать этих посредников, и выйти в мир, где есть масса крутых концепций
20 раз — это как раз тот порядок, на который ООП-шники ограничивают свой кругозор.

Вот есть игра в дурака, написана в ООП стиле. Сможете переписать ее с использованием крутых концепций ФП и 20 глав расширенного кругозора? Я серьезно, просто интересно сравнить результат и оценить сложность кода и дальнейшей поддержки.

Приведите мне пример правильного использования паттерна, при котором возникает проблема.
Singleton это паттерн или анти-паттерн?

Синглтон — это антипаттерн, а что?

Зависит от использования, конечно же. С тех пор, как управление зависимостями стало принято переносить наружу, реализация синглтона изменилась с той, которая описана в GoF, на "делегируйте ответственность в DI".

Приведите мне пример правильного использования паттерна, при котором возникает проблема.
Т.е. DI делает Singleton анти-паттерном?

Т.е. нет гарантии что завтра будет новый паттерн который сделает анти-паттернами сегодняшние паттерны?
Т.е. DI делает Singleton анти-паттерном?

Нет, неуместное использование делает синглтон антипаттерном.


Т.е. нет гарантии что завтра будет новый паттерн который сделает анти-паттернами сегодняшние паттерны?

Конечно, нет. Индустрия развивается.

Это инструмент.
И паттерн — поскольку это повторяющийся элемент проектирования.
Но из-за узких границ применимости, и нежелания людей думать, его долго пихали в те места, где он плохо работает.
А поскольку думать большинству по-прежнему лень, его «признали плохим».
Микроскоп, кстати, тоже негодная вещь — ей гвозди неудобно заколачивать.

Кстати, да, соглашусь. Синглтон — паттерн, вне зависимости от использования (вопреки тому, что я выше написал), просто зона его корректной применимости меньше, чем многие думают.

просто зона его корректной применимости
И какие применимости у Синглтона?

Проекты, не имеющие системы управления зависимостями, или ситуации, когда на конкретный объект не распространяются существующие правила управления зависимостями. Приведенный ниже пример с EqualityComparer<T>.Default — очень хорош.


Более того, если рассматривать синглтон как поведение, а не как реализацию, то все реализации через произвольный внешний менеджер (в том числе — DI-контейнер) тоже становятся валидными.

Та же, что и раньше.
В ситуации, когда изначально предложенная имплементация начинает вам мешать, его стоит заменить на что-то другое.
Например, в небольших домашних проектах использовать синглтон гораздо разумнее, чем пихать туда DI в каком-либо виде.

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


При неумеренном использовании легко превращается в анти-паттерн.


Пример нормального синглтона в стандартной библиотеке C# — EqualityComparer<T>.Default. Реализация интерфейса IEqualityComparer<T> по умолчанию, использующая метод Equals, по возможности без боксинга. При этом у того же самого интерфейса возможны и иные реализации, не являющиеся синглтонами.

Жалко на хабре правдорубов жестко минусят

Ой, да. "Минусят" не "правдорубов", а тех, кто никак не аргументирует свою точку зрения.

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

Как следствие применимость идей дяди Боба и Фаулера к конкретной системе оценить не получится. Результаты будут любыми, иногда хорошими и тогда авторов будут хвалить, иногда плохими и тогда будут ругать себя.
Так никто не пытается сделать его научным. Бродят всякие авторитеты и надувают щеки, книги пишут. Я всего пару статей видел как кто-то пытался осмыслить такие концепты как состояние и процедура. Народ заносит в какую-то дикую математику или гуманитарщину. Им сказали тридцать лет назад что серебряной пули нет, так они и не стараются ее найти. Как Кант сказал что ничего понять невозможно, так философы и перестали думать, у нас то же самое.

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

… а вы что под "гуманитарщиной" понимаете?


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

А те, кто эти "эффективные конь-цепты" принес — они сформулировали закон или теорему? Подвели научное обоснование?

Мы уже увидели в соседнем обсуждении, что вы не читаете источники и ходите критикуете тех кто читал. Поучитесь уж чему-то чтобы не задавать вопросы ответы на которые все знают.

(Казалось бы, какое отношение это имеет к вопросу "что вы понимаете под "гуманитарщиной""...)


Мы уже увидели в соседнем обсуждении, что вы не читаете источники и ходите критикуете тех кто читал.

Когда критикуют высказывание, не важно, что читал человек, важно, что он сказал.


Поучитесь уж чему-то чтобы не задавать вопросы ответы на которые все знают.

"Все знают" ответ на вопрос "что вы понимаете под гуманитарщиной"? Или "все знают" ответ на вопрос "подвели ли научное обоснование те, кто принес в программирование новые эффективные концепты на смену старому барахлу"? Если второе, то может быть вы мне приведете хотя бы пяток примеров? Мне всегда было интересно, что такое "научное обоснование в software design".

Стоит отметить, что thread local storage и type attributes (shared) позволяют точно так же отделить многопоточный доступ в "отдельные секции", не теряя возможностей ООП. И наоборот function attributes (pure) позволяют получить гарантии чистых функций, реализуя их совсем не ФП способом с присваиваниями и прочим.

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

ООП удобен для описания сущностей прикладной задачи и сущностей «вычислителя», на котором задача будет моделироваться, для декомпозиции прикладной задачи и вычислителя на максимально независимые модели состояния (чем ближе объект к «голой» структуре, чем меньше у него сложных методов трансформации — тем лучше, декларативнее). ФП же удобен для декомпозиции решения этой задачи в максимально независимые функции. Грубо говоря, в ООП-стиле удобно описывать «Дано» и «Надо», а в ФП-стиле — «Решение». Обе парадигмы полезны и в абсолюте неразделимы, потому в той или иной степени поддерживаются любым практическим языком программирования, но с «перекосом» в ту или иную сторону. И выбор языка, как мне кажется, зависит от выбранной методологии разработки и ценности полученного решения. Если хочется идти сверху вниз, от абстрактного решения к низкоуровневым аспектам реализации, и именно «решение» является максимально сложным и ценным аспектом в разрабатываемой инфосистеме, то выбирают что-то из «ФП-сильных» языков. Если же хочется идти снизу вверх, если «решение» как таковое тривиально и заранее известно, если инфосистема несёт ценность в большей степени как проецирование бизнеса («дано и надо») на «кремний», то выбирают «ООП-сильный» язык.
Прочитал ObjectOriented VisualStudio FunctionalProgramming. ASP.NET головного мозга, блин)
Мне больше нравится точка зрения на FP vs OOP описанная в SICP, где OOP рассматривается как способ достичь модульности путем сокрытия состояния. Того же можно добиться и в FP, например, в Haskell можно сделать что-то вроде
class MyClass state where 
	myMethod :: (MyClass state) => state -> state

В этом случае разница между OOP и FP заключается только в неизменяемых данных. А если вспомнить OCaml, который функциональный, но данные в нем менять можно, то вопрос о OOP vs FP как-то вообще теряет смысл.
Использование объектов в качестве структур данных – признак плохого проектирования.

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


Инструменты, вроде Hibernate называют себя ORM. Это некорректно. ORM не отображают реляционные данные на объекты. Они отображают реляционные данные на структуры данных. Эти структуры – не объекты. Объекты группируют поведение, а не данные.

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


Первые слайды намекают на то что все принципы и паттерны, разработанные нами за десятилетия работы применимы только для ООП. А в ФП все решается просто функциями.

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

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

Не смотря на свойственную Мартину сварливость в статье есть коротко-сформулированный и важный тезис: ФП и ООП — вещи не взаимоисключающие, а наоборот — дополняющие.
«Объект без поведения» это структура данных, потому что единственный его смысл это хранить данные.
ООП выросло из структурного программирования, и задачей появления объектов было получить управляющую структуру. Т.е. объект нужен, чтобы поддерживать нечто (например, структуру данных) в непротиворечивом состоянии.
Исходя из этого структура данных может являться объектом физически (в терминах C# или Java), но логически это структура данных. Т.е. нормально сконструированный объект должен быть консистентным, а структура данных такого ограничения не имеет.
Мне кажется, что одна из причин популярности ООП — удобство работы с IDE. Набрал название переменной, ставишь точку и нажимаешь ctrl+space — он показывает, что с этим можно сделать.
Речь не о том, что в ФП это сделать нельзя, а о том, что в прежних не-ОО языках так просто нельзя было сделать, а с ООП стало можно, и потому все начали массово переходить на ОО-языки.

… а вы уверены, что когда люди начали массово переходить на ОО-языки, IDE уже поддерживали эту замечательную функциональность?

Может быть именно такой функциональности не было, но были же различные браузеры классов, в том же Smalltalk еще в конце 70-х?
UFO just landed and posted this here
UFO just landed and posted this here
«Функциональные программы, как и объектно-ориентированные являются композицией функций преобразования данных. В ООП принято объединять данные и поведение. И что? Это действительно так важно?» — за этим вопросом следует параграф про иммутабельность, где разясняется, почему это действительно выжно. Пока состояние инкапсулировано в поведении об иммутабельности речи идти не может.
Sign up to leave a comment.

Articles