там где не нужно наследование можно вполне написать на процедурках и разложить по разным файлам, никто разницы не заметит

авторООП не используется при разработке операционных систем. Единственная (BeOS) умерла так и не пожив.
вот кстати, в nginx-ах всяких есть ООП, и много где ещё

авторООП в БДлол

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

Изопропилtip78кстати, есть другой важный вопрос - почему не напишут тулзу к тому же ПХП, которая компильнёт код в бинарник и его потом можно тупо отдавать веб-серверу?
так он это делает на каждом запросе, а так бы 1 раз и всё.
Давно написан - HHVM
хм
авторAs a process virtual machine that provides the execution environment, HHVM has the ability to use live type information to produce more efficient native code, leading to a higher web server throughput and lower latency. In Q4 2012, the execution of facebook.com's source code on HHVM achieved performance parity with HPHPc,[8] and in December 2013 HPHPc was even surpassed by around 15%.
это в 2013
а в PHP7 какие результаты, интересно. Он типа на 40% быстрее PHP5 получился

kolobok0- при использовании ОО один из профитов = СТАТИЧНОСТЬ кода. Т.е. меньше всего переделок. Если это не так - то разработчику надо читать теорию - т.е. указанную книгу.
дам ещё раз ссылку: https://habrahabr.ru/company/hexlet/blog/303160/]как сопровождать 10 миллионов строк кода и не сойти с ума - 10 правил от NASA
«The Power of 10: Rules for Developing Safety-Critical Code»В 2006 году Gerard Holzmann с коллективом сформулировал 10 основных правил для JPL в документе «The Power of 10: Rules for Developing Safety-Critical Code». Они вошли в основу нынешнего станда

Вот перевод этого списка.

1. Нужно сильно ограничивать ветвления и условия. Не использовать goto, setjmp или longjmp, не использовать прямую или косвенную рекурсию.
2. У всех циклов должен быть предел. Проверяющая программа должна иметь возможность легко доказать, что определенное количество итераций не может быть превышено.
Если предел невозможно доказать статически, то правило считается нарушенным.
3. Не использовать динамическое распределение памяти после инициализации.
4. Любая функция должна уместиться на одном стандартном листе бумаги, одно выражение на строку и одна строка на определение. Обычно это означает, что функция не должна быть длиннее 60 строк.
5. Плотность assert-ов в коде должна быть не менее двух assert-ов на каждую функцию (!!! ТУТ ОШИБКА ПЕРЕВОДА БЫЛА: не более 2х assert-ов).
Assert-ы используются для проверки аномальных условий, которые не могут произойти при реальном запуске.
Assert-ы не должны содержать сайд-эффектов, и по формату должны быть Boolean-тестами. Когда assert падает, должно запуститься специальное действие по восстановлению, например,
возврат условия падения обратно в вызывающую функцию. Если проверяющая программа доказывает, что assert никогда не фейлится или никогда не удовлетворяется, то правило считается нарушенным.
(Нельзя обойти это правило с помощью бессмысленных “assert(true)”).
6. Объекты с данными должны быть задекларированы на самом низком (из возможных) уровне области видимости.
7. Возвращаемое значение не-void функции должно проверяться вызывающей функцией. Валидность параметров должна проверяться внутри каждой функции.
8. Препроцессор можно использовать только для включения header-файлов и простых макро-определений. Token pasting, вариативные функции и рекурсивные макро вызовы запрещены.
Использование условных директив компиляции нежелательно, но иногда неизбежно. Это означает, что только в редких случаях уместно использовать больше чем одно или два условия в директивах
компиляции, даже в больших проектах.
9. Использование указателей должно быть ограничено. Допустимо не больше одного уровня разыменования. Операторы разыменования не должны быть скрыты в макро определениях или внутри typedef.
Указатели на функции запрещены.
10.Весь код должен компилироваться при всех включенных warning'ах, на самых дотошных настройках компилятора с самого первого дня разработки. Весь код должен компилироваться с такими
настройками без единого warning'а. Весь код должен проверяться каждый день (как минимум раз в день, но желательно чаще), с использованием лучшего из доступных на текущий день
статического анализатора кода, и должен проходить анализ без единого warning'а.