Является ли парадигма объектно-ориентированного программирования устаревшей, поскольку она антимодульная и антипараллельная? [закрыто]

Я прочитал противоречивую статью « Обучение ФП первокурсникам», которую написал Роберт Харпер, профессор КМУ. Он утверждал, что CMU больше не будет обучать объектно-ориентированному программированию во вводном курсе, поскольку он «не подходит для современной программы CS».

И он утверждал, что:

Объектно-ориентированное программирование полностью исключено из вводной учебной программы, потому что оно антимодульное и антипараллельное по самой своей природе.

Почему ООП считается антимодульным и антипараллельным?

Пожалуйста , обратите внимание, что потребности Харпера для обучения в вводном учебном плане CS класса сильно отличаются от потребностей реального проекта жизни . Его работа состоит в том, чтобы преподавать фундаментальные понятия (например, модульность, параллелизм, индукция) новичкам. Таким образом, очень важно, чтобы выбранный язык (и парадигма) мог выражать эти понятия с как можно меньшей церемонией (синтаксической и концептуальной), насколько это возможно. Знакомство, поддержка инструментов, доступные библиотеки, производительность выполнения и т. Д. Совершенно не имеют значения в этом контексте. Поэтому, пожалуйста, имейте это в виду, учитывая следующее ...

Мнение , что OO является анти-модульные результаты большого числа зависимостей с другими классами даже объекты хорошо разработанные классы , как правило, в конечном итоге. То, что это проблема - даже в глазах сторонников ОО - становится ясным, если взглянуть на распространение платформ Dependency Injection , статей, книг и постов в блогах за последние годы (также интересно появление насмешек и заглушек).

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

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

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

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

Вероятно, это смелое заявление, но я почему-то подозреваю, что этот Роберт Харпер никогда не писал реальное программное обеспечение в своей жизни. Все, что он, кажется, беспокоит - это ML и системы статических типов. Как бы большой вклад это ни было, я не понимаю, насколько его заявления об ООП имеют отношение к делу.

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

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

2. Утверждение, что ООП является антипараллельным, просто демонстрирует отсутствие понимания. ООП не фиксирует никаких решений относительно параллелизма. ООП диктует только их скрыть: при правильной сборке вы не можете сказать, является ли реализация объекта параллельной или нет.
   Таким образом, в конечном итоге ООП и параллельное программирование являются ортогональными. Модель актера - это элегантная модель параллелизма, которая может быть непосредственно отражена в объектной системе (но не обязательно), создавая потрясающую комбинацию обоих.

Проблема с ООП состоит в том, что мало кто на самом деле понимает это в том смысле, в каком его определил Алан Кей .

1. ООП это подход. В некоторых языках это реализовано с использованием шаблонов, в других вы можете напрямую использовать встроенные языковые идиомы (например, Ruby, Objective-C, Smalltalk, Io ).
2. Вопреки распространенному мнению, ООП не о классах. Речь идет об объектах, а объекты - о передаче сообщений или о одинаково неплотном способе инкапсуляции и абстракции.

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

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

Вы получаете фанатиков каждой полосы.

Объектно-ориентированное программирование не является серебряной пулей. Это никогда не было. Что это, является жертвой обмана. Неизбежно, люди заболели обманом, и обратная реакция начинает развиваться (независимо от фактической полезности парадигмы).

Без сомнения, через двадцать лет у нас будет еще одна отрицательная реакция на функциональное программирование.

Я не могу ответить на этот вопрос полностью, потому что можно только догадываться о смутных мыслях его автора. Я сильно подозреваю, что эта статья собирается вызвать некоторое замешательство у ее автора. В ООП нет ничего, что указывало бы на то, что оно не является ни модульным, ни параллельным:

Модульность . Основным аспектом ООП является то, что он действительно модульный (но модульность означает разные вещи в разных контекстах). Таким образом, независимо от того, говорит ли автор об обобщении или статическом программировании, он неверен.

Распараллеливание : Что касается параллельного программирования, большинство фреймворков поддерживают прерывания, затем многопоточность и теперь правильное распараллеливание, такое как то, что мы видим в .Net framework 4.0 и языки ООП, которые на него навязывают.

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

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

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

Лично я думаю, что это излишне, но ученые любят пробовать новые и экстремальные вещи. В качестве противовеса MIT использовал (и мог бы по-прежнему) преподавать все основные парадигмы программирования в одном классе новичка.

Как ни странно, обе школы подготовили несколько действительно хороших программистов. Пойди разберись.