Ну так не пейте токсические спирты включая этанол.

||зачем ||ты ||это ||делаешь?

я просто не знаю как здесь вставить цитату…

Поставь лазарус, нарисуй формочку и подумай, какой ад был бы без ООП. Хотя, что думать - как в жс 10 лет назад.

Посмотри на сишные GTK приложения. Нет классического ООП. Код читается и пишется проще. Тех же Qt с из крестами намного мудренее, код читается хуже.

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

IMHO на самом деле тесты заставляют в неявном виде продумывать архитектуру. Но т.к. в неявном - далеко не всех. Половина все равно фигню напишет. А кто не напишет - может и без тестов код клепать, если держит в голове «как бы я для этого писал тест».

А про ООП - аффтор[ка] похоже не в курсе, что никто не запрещает рисовать data flow для классов. И предлагает делать его ВМЕСТО классов. Вангую ограничения самообразования.

Ну есть, к примеру, рвотное. Оно не полезно и его дают именно чтобы вызвать реакцию. А в китайской или ещё какой-то там восточной медицине есть идея «излечения через обострение». Или ещё есть гомеопатия.

Читай

А что не так?

То, что ООП там тоже есть. С дескрипторами и коллбеками.

три разных сервиса (ALSA, JACK, PulseAudio) запущенные параллельно

И совсем непонятно, какое это отношение имеет к объектной архитектуре той же VFS в ядре.

я просто не знаю как здесь вставить цитату…

Рукалицо. Ты когда сообщение пишешь у тебя под полем ввода написано:

Пустая строка (два раза Enter) начинает новый абзац. Знак '>' в начале абзаца выделяет абзац курсивом цитирования.
Внимание: прочитайте описание разметки Markdown или LORCODE.

Слушай, ну вообще когда какой-то очень авторитетный программист начинает говорить, что есть хорошие и плохие программисты, притом его высказывание короткое и похоже на лозунг - то это секта 100%.

Забавно ты сам себя описал, кстати.

Кстати, о каком ООП речь? Наследственность, изменчивость, естественный отбор или обмен сообщениями, позднее связывание и что там ещё было третье? Или не было?

Это ты его ловко подловил.

Мой ответ по теме: Data Oriented Design.

Это все оставьте для детских утренников. Просто покажите код.

Я у него в игноре, он эпично сделает вид, что ничего не увидел :)

Вот, кстате, GTK ООП пронизан. Он же основан на GObject, который в Сишечку ооп просто пропихивает. Единственно, что там не так это С++ и то для этого Vala был придуман. ну и биндинги для С++

Я много лет жизни потерял пытаясь понять что это за зверь

Но, видимо, так ничего и не понял. По крайней мере ничего осмысленного в теме не изложил.

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

Ты, как мой батя: «цель жизни политиков — сделать нам на зло, чтобы нам хуже жить было».

Вот батя в детстве меня дрючил, чтобы я писал красиво — прошло эн лет, а я уже года два кроме подписи ничего не писал от руки. И какой был смысл?

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

Блин, ну я тогда не буду вываливать свои соображения ... мое мнение на форуме уже все примерно знают.

Мания величия вдобавок? Любопытный случай

10000 классов по 1000 строк - 10 миллионов строк кода? Ядро Линукс нервно курит в сторонке…

Посмотри на сишные GTK приложения. Нет классического ООП.

Я не знаю, насколько оно там классическое, но оно однозначно есть. Кстати, ТС мой коварный вопрос, относится ли GTK к раздутым из-за ООП проектам, благоразумно не заметил, видимо, начал о чём-то догадываться. :)

Тех же Qt с из крестами намного мудренее, код читается хуже.

Субъективное.

А это еще не кровавый ынтырпрайз, чувак, ты походу жизни не видел

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

Пожалуй, самый взвешенный тезис в теме.

Так вот, TDD вполне конкретно, а не абстрактно, препятствует здоровому рефакторингу.

это как заявлять, что строителям леса вокруг здания мешают

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

Один говори - «Говно!», остальные доказывают, что всё норм. В процессе иногда всплывает что-нибудь интересное

Всплывает говно!

В квотезы!

Процедурщина с элементами ООП чем тебя не устраивает? Где набор логики связан с конкретной сущностью, там появляется класс, в обратном случае он не появляется. Просто же всё.

Да за державу обидно, я подобных чудиков постоянно вижу, на собеседования приходят постоянно, минимум 5 лет стажа, а думают, что знают все.

Да на эту тему много есть примеров. Об этом говорилось вот в этом видео, например: https://www.youtube.com/watch?v=V6VP-2aIcSc

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

Да, но без ООП никакой большой системы не будет вообще.

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

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

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

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

Меня устраивает любой подход, если он применяется адекватно. Там где ООП ради ООП(серьезно, в одном проекте я видел промежуточный класс, у которого не было НИЧЕГО, кроме потомков, которые от него наследуются. И так было в коде лет 5, потому что «ну может когда-нибудь будем расширять эту абстракцию»), густо замешанное на глобальных переменных с лямбдами только что это круто и модно - вот от этого тянет блевать.

чтобы все по-быстрому и чтоб потом быстро

Это точно про язык программирования? ;)

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

Либо код работает, либо манагеры проекта не знают про правило трех

То, что ООП там тоже есть. С дескрипторами и коллбеками.

А где вообще нет декрипторов и коллбеков??

И совсем непонятно, какое это отношение имеет к объектной архитектуре той же VFS в ядре.

«One of the first virtual file system mechanisms on Unix-like systems was introduced by Sun Microsystems in SunOS 2.0 in 1985.» - ну тут как бы ясно откуда ноги растут…

Забей, это я спетросянил.

Знать и использовать разные вещи.

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

Что-то ты гонишь. Я до сих пор пишу процедурами, но для формы у меня объект, на который мапится структура данных.

Я посмотрел сейчас gtk hello world - да это хтонь какая-то. wxWidgets c++ hello world намного проще для чтения.

Половина все равно фигню напишет

Будто на фигню не пишут тесты.

серьезно, в одном проекте я видел промежуточный класс, у которого не было НИЧЕГО, кроме потомков, которые от него наследуются

У меня встречется такое:

template <typename T, unsigned N>
struct maker : maker<T, N - 1> {};
template <typename T>
struct maker<T, 0> {};

А где вообще нет декрипторов и коллбеков??

В нормальном, отрефакторином коде, а пока будет индусстриальное программирование, нам это не светит. Про коллбеки и замену его паттерном Observer не слышал ?

ты еще не видел, что с метаклассами в питоне вытворяют

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

Концепция мне знакома, но не суть, сейчас я без усиленного гуглежа всё равно не разберусь и в записи уравнения. Если отбросить абракадабру, то будто там что-то сложное есть.

никогда и нигде не использовала

И не сможешь использовать, ведь для этого тебе, Пиноккио, нужно сначала стать настоящим мальчиком девочкой.

Пока программы были небольшими и ограниченными

ядро создавалось именно тогда

Ты лет на 20 ошибся.

никакой разницы между функцией и объектом в определенном смысле нет.

Расскажи это фанатам функциональных языков программирования :-) Удалённо, конечно. Не в баре…

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

То что ты называешь контекст - это состояние машины. А то что я называю контекст - это состояние внешнего мира. Проблема объекта в том, что он «знает как себя отрисовать», но при этом ему надо передать информацию о внешнем мире. Что в принципе противоречие.

Я о том и говорю что чтобы знать как отрисовать кнопку надо знать разрешение экрана, надо знать всё о текущей теме рабочего стола и так далее. Это всё находится ВНЕ объекта, и поэтому сама мысль о том что объект чего-то там «знает» в корне неверна. Любые разработки на ООП приходят к этому противоречию, упираются в него и начинают искать пути обхода. Появляются паттерны, принципы и прочая фигня, которая по сути - костыли, необходимые из-за принятия изначально неверного тезиса.

Данные важнее, чем код

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

Почему в голове автора нельзя одновременно НЕ_игнорировать архитектуру модели данных и при этом хранить всё в объектах без потери производительности при кодировании и не создавая бестолковых вещей?

Мотивирование к сложности

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

Если мыслить в категориях абстрактных классов и объектов, то грандиозность и сложность абстракций сверху ничем не ограничивается

Головой она ограничивается, временем и ресурсами.

Это никак не мешает мне создать абстракцию для сущностей предметной области которые объединяют общие свойства. Например, у всех моих сущностей есть ID и UUID, почему я не могу сделать абстракцию и наследование? Это автоматом создаст FizzBuzz Enterprise Edition или чёрную дыру или вызовет сатану? Нет.

Повсюду графы

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

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

Задачи поперечных срезов

Вообще не понимаю о чём говорит автор, в моём манямирке class Monster вообще не знает никаких особых методов взаимодействия с другими классами. Для этого у меня есть сервисы.

Шизофреническая инкапсуляция объектов

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

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

На одинаковые данные можно смотреть по-разному

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

Создай ещё один сервис или метод в существующем сервисе с отличной обработкой тех же данных. В чём проблема?

Низкая производительность

Ой всё. Пока никто не подтвердил, что производительность твоего ПО низкая - её достаточно.

Пока Линус твердо стоит на ногах, он от сишечки не откажется(там можно свое ООП, низкоуровневое). Пюсы отсек, вот rust пытаются пропихнуть, пока сопротивляется

I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386(486) AT clones

Как раз таки не ошибся.

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