ООП сложно, потому что это не естественно?

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

Обратите внимание, что в повседневной жизни отношения и действия существуют главным образом между объектами, которые были бы экземплярами не связанных классов в ООП. Примеры таких отношений: «мой экран находится на вершине таблицы»; «Я (человек) сижу на стуле»; "машина на дороге"; «Я печатаю на клавиатуре»; «кофемашина кипит вода», «текст отображается в окне терминала».

Мы думаем в терминах двухвалентных (иногда трехвалентных, как, например, в «Я подарил вам цветы») глаголов, где глагол - это действие (отношение), которое воздействует на два объекта для получения некоторого результата / действия. Основное внимание уделяется действию, и два (или три) [грамматических] объекта имеют одинаковое значение.

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

Мало того, что акцент смещен на существительные, но одному из существительных (назовем это грамматическим предметом) дается более высокая «важность», чем другому (грамматическому объекту). Таким образом, нужно решить, скажете ли вы терминалWindow.show (someText) или someText.show (терминалWindow). Но зачем обременять людей такими тривиальными решениями без каких-либо эксплуатационных последствий, когда действительно нужно показать (TerminalWindow, someText)? [Последствия являются незначительными с точки зрения эксплуатации - в обоих случаях текст отображается в окне терминала - но могут быть очень серьезными при проектировании иерархий классов, а «неправильный» выбор может привести к запутанному и трудному в обслуживании коду.]

Поэтому я бы сказал, что основной способ выполнения ООП (на основе классов, одна отправка) сложен, потому что он НАТУРАЛЬНЫЙ и не соответствует тому, как люди думают о мире. Общие методы из CLOS ближе к моему мышлению, но, увы, это не распространенный подход.

Учитывая эти проблемы, как / почему случилось так, что в настоящее время основной способ сделать ООП стал настолько популярным? И что, если что, можно сделать, чтобы свергнуть это?

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

1. Некоторые люди ведут себя так, как будто это единственно верный способ программирования, а все остальные парадигмы ошибочны. ИМХО, каждый должен использовать многопарадигмальный язык и выбрать лучшую парадигму для подзадачи, над которой он сейчас работает. Некоторые части вашего кода будут иметь стиль OO. Некоторые будут функциональными. У некоторых будет прямой процедурный стиль. С опытом становится очевидным, какая парадигма лучше для чего:

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

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

   с. Функциональность лучше всего подходит, когда у вас есть что-то, что довольно легко написать декларативно, так что существование любого состояния вообще является деталью реализации, которую можно легко абстрагировать. Пример: Карта / Уменьшить параллелизм.

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

ИМХО это вопрос личного вкуса и способов мышления. У меня нет особых проблем с ОО.

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

ИМХО это не совсем так, хотя это может быть общим восприятием. Алан Кей, изобретатель термина ОО, всегда подчеркивал сообщения, передаваемые между объектами, а не самими объектами. И сообщения, по крайней мере для меня, обозначают отношения.

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

Если между объектами есть отношения, то они связаны по определению. В ОО вы можете выразить это с помощью зависимости ассоциации / агрегации / использования между двумя классами.

Мы думаем в терминах двухвалентных (иногда трехвалентных, как, например, в «Я подарил вам цветы») глаголов, где глагол - это действие (отношение), которое воздействует на два объекта для получения некоторого результата / действия. Основное внимание уделяется действию, и два (или три) [грамматических] объекта имеют одинаковое значение.

Но у них все еще есть свои четко определенные роли в контексте: субъект, объект, действие и т. Д. «Я подарил тебе цветы» или «Ты подарил мне цветы» - это не одно и то же (не говоря уже о том, «Цветок дал мне тебя»): -)

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

Я не согласен с этим. ИМХО английское предложение «Билл, иди к черту» читается более естественно в программном коде, bill.moveTo(hell)а не move(bill, hell). И первый фактически более похож на оригинальный активный голос.

Таким образом, нужно решить, скажете ли вы терминалWindow.show (someText) или someText.show (терминалWindow)

Опять же, это не то же самое, что попросить терминал показать некоторый текст или попросить текст показать терминал. ИМХО, вполне очевидно, какой из них более естественный.

Учитывая эти проблемы, как / почему случилось так, что в настоящее время основной способ сделать ООП стал настолько популярным?

Может быть, потому что большинство разработчиков OO видят OO иначе, чем вы?

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

... но в центре внимания ООП находится разработка отдельных классов и их иерархий.

ООД НЕ об этом. OOD - это выяснение того, как вещи ведут себя и взаимодействуют.

Мы думаем в терминах двухвалентных (иногда трехвалентных, как, например, в «Я подарил вам цветы») глаголов, где глагол - это действие (отношение), которое воздействует на два объекта для получения некоторого результата / действия. Основное внимание уделяется действию, и два (или три) [грамматических] объекта имеют одинаковое значение.

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

Я не вижу делателя более важным, чем то, что с ним что-то делает.

Но зачем обременять людей такими тривиальными решениями без каких-либо эксплуатационных последствий, когда действительно нужно показать (TerminalWindow, someText)?

Для меня это то же самое с другой нотацией. Вы все еще должны решить, кто шоу-шоу, а кто шоу-е. Как только вы это знаете, в ООД решения не принимается. Windows показать текст -> Window.Show (текст).

Многие вещи там (особенно в унаследованной области) говорят, что это ОО, когда это не так. Например, существует огромное количество кода на C ++, который не реализует ни черта OOD.

OOD легко, когда вы выходите из себя, решая проблему для компьютеров. Вы решаете проблемы для вещей, которые делают вещи.

Может быть, я не могу понять, но:

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

Для меня это довольно ясно: собака - это животное, животное должно есть, моя собака - это собака, поэтому она должна есть ...

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

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

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

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

Я до сих пор поражаюсь огромным трудностям, которые мне дала эта ложная предпосылка (и тому, как я позволил себе быть признанным этим).

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

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

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

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

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

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

Это только часть того, что не так с ООП.

По сути, функции становятся гражданами второго сорта, и это плохо.

Современные языки (ruby / python) не страдают от этой проблемы и предоставляют функции в качестве объектов первого класса, а также позволяют создавать программы без построения какой-либо иерархии классов.

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

РЕДАКТИРОВАНИЕ

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

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

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

Я работал в основном с языками ООП (C ++, Java), но у меня часто возникает ощущение, что я могу быть столь же продуктивным, используя Pascal или Ada, хотя я никогда не пробовал их в больших проектах.

Сравните это с ООП, где вы сначала должны найти один объект (существительное) и сказать ему выполнить какое-то действие с другим объектом.

[порез]

Поэтому я бы сказал, что основной способ выполнения ООП (на основе классов, одна отправка) сложен, потому что он НАТУРАЛЬНЫЙ и не соответствует тому, как люди думают о мире. Общие методы из CLOS ближе к моему мышлению, но, увы, это не распространенный подход.

Когда я прочитал этот последний абзац более внимательно, я наконец понял суть вашего вопроса, и мне пришлось переписать свой ответ с нуля. :-)

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

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

Прекратите искать исключительно парадигму ООП и попробуйте немного JavaScript.

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

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

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

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

Итак, я думаю, что я говорю, это: это не проблема переключения типа заявления. Это смешивать и сочетать. Проблема в языках и причудах, которые хотят, чтобы вы поверили, что это одна вещь. Как может, например, младший Java-разработчик по-настоящему ценить ООП, если он думает, что он всегда делает это правильно по умолчанию?

Мне это объяснили с помощью тостера и машины. У обоих есть пружины, так что у вас был бы «пружинный» объект, и они были бы разных размеров, сил и тому подобное, но они оба были бы «пружинами», а затем распространяли эту метафору на автомобиль, если бы у вас было много колес (Колеса, очевидно, плюс руль, и т. Д.), И это имело большой смысл.

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

Я думаю, что настоящая проблема с ООП состоит в том, как это объясняется людям. Часто (в моих университетских классах) я вижу, что это объясняется тем, что «речь идет о множестве классов, которые делают мелочи, и вы можете создавать объекты из этого», и все это сбивает с толку многих людей, потому что они используют то, что по сути абстрактно термины, объясняющие эти понятия, а не конкретные идеи, которые люди поняли, когда им было 5 лет, играя с лего.

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

Я думаю, что некоторые трудности возникают, когда люди пытаются использовать ООП для представления реальности. Всем известно, что у машины четыре колеса и двигатель. Все знают, что автомобили могут Start(), Move()и SoundHorn().

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

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

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

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

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

В реальном мире иногда люди используют функциональную парадигму, а иногда мы используем процедурную парадигму и так далее. И иногда мы перепутали. И в конце концов мы представляем их как особый стиль или парадигму программирования.

Существует также парадигма «все - список или элемент», используемая в LISP. Мне нравится упоминать как отличную вещь от функционального программирования . PHP использует это в ассоциативных массивах.

Парадигмы ООП и «Все является списком или элементом» рассматриваются как два из БОЛЕЕ ЕСТЕСТВЕННЫХ стилей программирования, как я помню в некоторых классах искусственного интеллекта.

Звучит для меня странно: «ООП не является естественным», возможно, то, как вы учитесь, или то, как вас учили об ООП, неверно, но не само ООП.

Учитывая эти проблемы, как / почему случилось так, что в настоящее время основной способ сделать ООП стал настолько популярным? И что, если что, можно сделать, чтобы свергнуть это?

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

Чтобы свергнуть ОО, создайте язык, который позволяет постепенно переходить от того, что большинство программистов знают сегодня (в основном процедурное, с небольшим ОО), к предпочитаемой вами парадигме. Убедитесь, что он предоставляет удобные API для выполнения общих задач и хорошо его продвигает. Вскоре люди будут создавать программы для X-in-name-only на вашем языке. Тогда вы можете ожидать, что людям потребуются годы и годы, чтобы хорошо освоить X.

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

Если вы правильно понимаете, ООП - это черные ящики (объекты), на которых есть кнопки, которые можно нажимать (методы). Классы только для того, чтобы помочь организовать эти черные ящики.

Одна проблема заключается в том, что программист нажимает кнопки на неправильном объекте. Терминал не может показывать текст сам по себе, текст не может показывать себя на терминале. Компонент оконного менеджера операционной системы, который может это сделать. Окно терминала и текст - это просто пассивная сущность. Но если мы думаем таким образом, мы понимаем, что большинство сущностей являются пассивными вещами, и у нас будет только очень немного объектов, которые действительно что-то делают (или просто один: компьютер ). Действительно, когда вы используете C, вы организуете его в модули, эти модули представляют это несколько объектов.

Другое дело, что компьютер просто выполняет инструкции последовательно. Давайте предположим, что у вас есть объект VCRи Televisionобъект, как бы вы воспроизводили видео? Вы, вероятно, напишите что-то вроде этого:

connect(television, vcr);
vcr.turnOn();
television.turnOn();
insert(vcr, yourFavoriteCasette);
vcr.play();
while (vcr.isPlaying()) {} // Wait while the VCR is playing the casette.
vcr.eject();
vcr.turnOff();
television.turnOff();

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

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

Взгляните на DCI (данные, контекст и взаимодействие), изобретенные изобретателем шаблона MVC.

Цель DCI (цитируется из Википедии):

• Дайте поведению системы первоклассный статус над объектами (существительными).
• Чисто отделить код для быстро меняющегося поведения системы (что делает система) от кода для медленно меняющегося знания предметной области (что такое система) вместо того, чтобы объединять оба в одном интерфейсе класса.
• Поддерживать объектный стиль мышления, близкий к ментальным моделям людей, а не классовый стиль мышления.

Вот хорошая статья авторов и небольшой пример реализации (.NET), если вы хотите увидеть некоторый код. Это намного проще, чем может показаться, и кажется очень естественным.

Часто можно услышать, что ООП естественно соответствует тому, как люди думают о мире. Но я бы категорически не согласился с этим утверждением (...)

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

(...) но в центре внимания ООП находится разработка отдельных классов и их иерархий.

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

«Предложение по упрощенным, современным определениям« объект »и« объектно-ориентированный » http://wcook.blogspot.com.br/2012/07/proposal-for-simplified-modern.html

Учитывая эти проблемы, как / почему случилось так, что в настоящее время основной способ сделать ООП стал настолько популярным?

Возможно, по той же причине, по которой клавиатуры QWERTY стали популярными, или по той же причине, по которой операционная система DOS стала популярной. Вещи просто прокатятся на популярных автомобилях, несмотря на их свойства, и сами станут популярными. И иногда подобные, но худшие версии чего-либо считаются действительными.

И что, если что, можно сделать, чтобы свергнуть это?

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

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

Возьмем Java: объекты являются своего рода узким местом абстракции, большинство «вещей» являются либо строго подкомпонентами объектов, либо используют объекты в качестве своих подкомпонентов. Объекты должны быть достаточно многоцелевыми, чтобы весь слой абстракции между этими двумя типами вещей - многоцелевой означает, что нет единой метафоры, которую они воплощают. В частности, Java делает объекты (и классы) единственным слоем, через который вы вызываете / отправляете код. Честно говоря, такое количество вещей, которые воплощают объекты, делает их слишком сложными. Любое их полезное описание должно быть ограничено какой-либо специализированной или ограниченной формой.

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

Можно сказать, что «объекты» имеют или должны быть многими вещами, потому что они являются многоцелевой абстракцией, более или менее универсальной в «OO Langauge». Если они используются для хранения локального изменяемого состояния или для доступа к некоторому состоянию внешнего мира, то они очень похожи на «существительное».

Напротив, объект, который представляет процесс, например «шифровать» или «сжимать» или «сортировать», выглядит как «глагол».

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

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

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

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

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

Если вы сравните правильно написанный ОО-код с плохо написанным процедурным кодом, то вы всегда будете приходить к неправильному выводу. Очень немногие проекты требуют объектно-ориентированного дизайна. Если вы являетесь IBM и управляете огромным проектом, который многие годы должны поддерживать несколько разработчиков, выберите Object Oriented. Если вы пишете небольшой блог или торговый сайт для клиента, подумайте дважды.

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

Обязательным требованием для любого объектно-ориентированного программиста должно быть знание того, как написать шахматное приложение на ассемблере для максимально доступной памяти в 16 КБ. Затем они научились бы обрезать жир, избавляться от лени и находить гениальные решения.