[IT-стандарты, ООП, Функциональное программирование] Объектно-ориентированное программирование – катастрофа за триллион долларов. Часть 1 (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Пришло время уйти от OOP
OOP считается самым большим бриллиантом в короне компьютерной науки. Лучшим способом организации кода. Решением всех проблем. Единственно верным способом писать наши программы. Ниспосланным нам свыше самим богом программирования… Только вот OOP программист вынужден разгребать кучу всяких абстракций, следить за всеми совместно используемыми объектами, помнить тонны «паттернов программирования» — и на все это тратить свои время и силы вместо того, чтобы решать саму поставленную задачу.
Многие уже давно критикуют OOP, и среди этих критиков не мало очень уважаемых программистов. И даже Alan Kay – изобретатель OOP находится в их рядах!
Главной целью любого разработчика является написания надежного кода. Если код глючный и не работает, как задумано, то всё остальное не имеет никакого значения. А какой самый лучший способ написать надежный код? Сделать код простым. Простота – это противоположность сложности. Отсюда следует, что первоочередная цель разработчика – уменьшить сложность кода.
Disclaimer:
Я не фанат OOP, так что нет ничего удивительного, что эта статья покажется многим предвзятой. Однако, я приведу аргументы в защиту своей позиции.
Я также прекрасно понимаю, что критика OOP воспринимается многими очень болезненно. Так что многие читатели почувствуют себя оскорбленными лично. Тем не менее, я намерен высказать то, что я считаю правильным. Ибо моя цель не оскорбить, а указать на проблемы, которые есть в OOP.
Вот OOP от Alan Kay я не критикую. Он вообще гений. Лично я бы хотел, чтобы OOP был именно таким, какие его задумал Alan Kay. Что я критикую, так это OOP в реализации C# или Java.
Проблема в том, что OOP давно считается стандартом организации программного кода. И так считают очень многие, включая тех, кто занимает серьезные должности в софтверной индустрии, отчего другие подходы к программированию даже не рассматриваются в большинстве компаний.
Мне приходилось преодолевать множество сложностей, когда я писал на OOP языках. И мне всегда было интересно, почему возникали эти сложности. Может, это я был не слишком хорош? Может, мне надо было научиться еще паре десятков «паттернов программирования»? В конце концов, у меня на всё это просто не осталось сил.
Эта статья расскажет вам, какой путь длинной в десятилетие я прошел от OOP к функциональному программированию. С тех пор я не припомню случая, чтобы мне попался проект, для которого бы именно OOP подходил лучше всего. Более того, проекты, где использовался OOP, проваливались под тяжестью сложности кода – с какого-то момента их было невозможно дальше поддерживать и развивать.
TLDR
«Объектно-ориентированные программы – это альтернатива правильным программам.»
Edsger W. Dijkstra, пионер компьютерной науки
Цель создания OOP была одна – справиться со сложностью процедурного кода. Другими словами, OOP был призван улучшить организацию кода. Но с тех пор не было приведено ни одного свидетельства в пользу того, что OOP лучше старого процедурного программирования.
Горькая правда состоит в том, что OOP не справился с той единственной задачей, для которой он был создан. На бумаге всё выглядело прекрасно – у нас были строгие иерархии животных, собак, людей… (И, конечно же, фигур: прямоугольников, квадратов и кругов – куда ж без них!) Но по мере возрастания сложности кода приложения, OOP не помогал ее уменьшить, а наоборот увеличивал – тоннами необходимых «паттернов программирования» и создавая сложности для программиста уследить за тем, где и как меняются значения переменных. OOP сделал многие часто используемые процедуры, такие как рефакторинг и тестирование, неоправданно сложными.
Многие не согласиться со мной, но факт в том, что дизайн OOP в C# или Java не был продуман с научной точки зрения, он не явился результатом серьезного научного исследования. В отличие от функционального программирования, например, в Haskell, где прочной теоретической основой является лямбда-исчисление. В основе OOP не лежит ничего подобного.
В маленьких проектах OOP показывает себя вполне неплохо. Но что будет, когда проект разрастется? OOP – это мина замедленного действия, которая неизбежно рванет, когда код проекта достигнет определенных размеров. Проекты начинают задерживаться, дедлайны срываться, разработчики падают без сил, а добавление новых фич становится практически невозможным. В конце концов, компании вынуждены помечать такой код как «устаревший», а разработчиков засадить за рерайт.
OOP не слишком хорошо согласуется с тем, как думает наш мозг. Мы привыкли сосредотачиваться на действиях: пойти на прогулку, поговорить с другом, съесть пиццу. Наш мозг развивался в сторону «делания чего-то», а не в сторону выстраивания сложной иерархии из абстрактных объектов.
Код OOP недетерминированный (в отличие от функционального программирования): мы не можем быть уверены, что при одних и тех же входных данных мы каждый раз будем получать один и тот же результат. А это очень затрудняет понимание того, как программа работает. Приведу простой пример: сравните 2+2 и calculator.Add(2, 2). Последнее выражение, по идее, должно всегда выдавать 4, но оно может выдать и 5, и 3, а то и 1004, ибо зависимости объекта Calculator могут изменить его поведение самым непредсказуемым образом.
===========
Источник:
habr.com
===========
===========
Автор оригинала: Ilya Suzdalnitski
===========Похожие новости:
- [IT-стандарты] GDRP: Что считать персональными данными граждан ЕС и можно ли с ними работать в РФ
- [IT-стандарты, Бизнес-модели, Искусственный интеллект, IT-компании] Astra Linux — на хромой лошади экономику не объедешь
- [IT-инфраструктура, IT-стандарты, Инженерные системы] Дата-центры высшего уровня: отвечаем на часто задаваемые вопросы про Tier IV
- [Алгоритмы, Функциональное программирование, Elixir/Phoenix] Перевозим волка, козу и капусту через реку с эффектами на Elixir
- [IT-инфраструктура, IT-стандарты, Управление сообществом] Где купить паспорт с дисконтом до 50%? Сравнение коронаскидок
- [Python, Будущее здесь, ООП, Параллельное программирование] Мир без корутин. Костыли для программиста — asyncio
- [Haskell, Алгоритмы, Функциональное программирование] Перевозим волка, козу и капусту через реку с эффектами на Haskell
- [IT-инфраструктура, IT-стандарты, Администрирование баз данных, Резервное копирование, Хранение данных] Судьба EU-U.S. Privacy Shield и что нужно предпринять компаниями, которые осуществляют трансграничную передачу данных?
- [Программирование, Сетевые технологии, IT-стандарты] Закон дырявых абстракций (перевод)
- [Разработка веб-сайтов, Python, Программирование, Функциональное программирование] Какая асинхронность должна была бы быть в Python
Теги для поиска: #_itstandarty (IT-стандарты), #_oop (ООП), #_funktsionalnoe_programmirovanie (Функциональное программирование), #_oop (ООП), #_funktsionalnoe_programmirovanie (функциональное программирование), #_itstandarty (
IT-стандарты
), #_oop (
ООП
), #_funktsionalnoe_programmirovanie (
Функциональное программирование
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 20:32
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Пришло время уйти от OOP OOP считается самым большим бриллиантом в короне компьютерной науки. Лучшим способом организации кода. Решением всех проблем. Единственно верным способом писать наши программы. Ниспосланным нам свыше самим богом программирования… Только вот OOP программист вынужден разгребать кучу всяких абстракций, следить за всеми совместно используемыми объектами, помнить тонны «паттернов программирования» — и на все это тратить свои время и силы вместо того, чтобы решать саму поставленную задачу. Многие уже давно критикуют OOP, и среди этих критиков не мало очень уважаемых программистов. И даже Alan Kay – изобретатель OOP находится в их рядах! Главной целью любого разработчика является написания надежного кода. Если код глючный и не работает, как задумано, то всё остальное не имеет никакого значения. А какой самый лучший способ написать надежный код? Сделать код простым. Простота – это противоположность сложности. Отсюда следует, что первоочередная цель разработчика – уменьшить сложность кода. Disclaimer:
Я не фанат OOP, так что нет ничего удивительного, что эта статья покажется многим предвзятой. Однако, я приведу аргументы в защиту своей позиции. Я также прекрасно понимаю, что критика OOP воспринимается многими очень болезненно. Так что многие читатели почувствуют себя оскорбленными лично. Тем не менее, я намерен высказать то, что я считаю правильным. Ибо моя цель не оскорбить, а указать на проблемы, которые есть в OOP. Вот OOP от Alan Kay я не критикую. Он вообще гений. Лично я бы хотел, чтобы OOP был именно таким, какие его задумал Alan Kay. Что я критикую, так это OOP в реализации C# или Java. Проблема в том, что OOP давно считается стандартом организации программного кода. И так считают очень многие, включая тех, кто занимает серьезные должности в софтверной индустрии, отчего другие подходы к программированию даже не рассматриваются в большинстве компаний. Мне приходилось преодолевать множество сложностей, когда я писал на OOP языках. И мне всегда было интересно, почему возникали эти сложности. Может, это я был не слишком хорош? Может, мне надо было научиться еще паре десятков «паттернов программирования»? В конце концов, у меня на всё это просто не осталось сил. Эта статья расскажет вам, какой путь длинной в десятилетие я прошел от OOP к функциональному программированию. С тех пор я не припомню случая, чтобы мне попался проект, для которого бы именно OOP подходил лучше всего. Более того, проекты, где использовался OOP, проваливались под тяжестью сложности кода – с какого-то момента их было невозможно дальше поддерживать и развивать. TLDR «Объектно-ориентированные программы – это альтернатива правильным программам.» Edsger W. Dijkstra, пионер компьютерной науки Цель создания OOP была одна – справиться со сложностью процедурного кода. Другими словами, OOP был призван улучшить организацию кода. Но с тех пор не было приведено ни одного свидетельства в пользу того, что OOP лучше старого процедурного программирования. Горькая правда состоит в том, что OOP не справился с той единственной задачей, для которой он был создан. На бумаге всё выглядело прекрасно – у нас были строгие иерархии животных, собак, людей… (И, конечно же, фигур: прямоугольников, квадратов и кругов – куда ж без них!) Но по мере возрастания сложности кода приложения, OOP не помогал ее уменьшить, а наоборот увеличивал – тоннами необходимых «паттернов программирования» и создавая сложности для программиста уследить за тем, где и как меняются значения переменных. OOP сделал многие часто используемые процедуры, такие как рефакторинг и тестирование, неоправданно сложными. Многие не согласиться со мной, но факт в том, что дизайн OOP в C# или Java не был продуман с научной точки зрения, он не явился результатом серьезного научного исследования. В отличие от функционального программирования, например, в Haskell, где прочной теоретической основой является лямбда-исчисление. В основе OOP не лежит ничего подобного. В маленьких проектах OOP показывает себя вполне неплохо. Но что будет, когда проект разрастется? OOP – это мина замедленного действия, которая неизбежно рванет, когда код проекта достигнет определенных размеров. Проекты начинают задерживаться, дедлайны срываться, разработчики падают без сил, а добавление новых фич становится практически невозможным. В конце концов, компании вынуждены помечать такой код как «устаревший», а разработчиков засадить за рерайт. OOP не слишком хорошо согласуется с тем, как думает наш мозг. Мы привыкли сосредотачиваться на действиях: пойти на прогулку, поговорить с другом, съесть пиццу. Наш мозг развивался в сторону «делания чего-то», а не в сторону выстраивания сложной иерархии из абстрактных объектов. Код OOP недетерминированный (в отличие от функционального программирования): мы не можем быть уверены, что при одних и тех же входных данных мы каждый раз будем получать один и тот же результат. А это очень затрудняет понимание того, как программа работает. Приведу простой пример: сравните 2+2 и calculator.Add(2, 2). Последнее выражение, по идее, должно всегда выдавать 4, но оно может выдать и 5, и 3, а то и 1004, ибо зависимости объекта Calculator могут изменить его поведение самым непредсказуемым образом. =========== Источник: habr.com =========== =========== Автор оригинала: Ilya Suzdalnitski ===========Похожие новости:
IT-стандарты ), #_oop ( ООП ), #_funktsionalnoe_programmirovanie ( Функциональное программирование ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 20:32
Часовой пояс: UTC + 5