Как стать автором
Обновить

Комментарии 10

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


Ну а разве ООП не про то же самое? Я имею ввиду принципы из GRASP про взаимосвязи: Low Coupling и High Cohesion.

Сию статью можно было бы чуть менее чем полностью заменить на известное высказывание Винни-Пуха "нужно делать так, как нужно, а как не нужно — делать не нужно!"

Но как нужно — не скажем (ибо не знаем)
Решил переписать сортировку пузырьком на ООП. Выделил объект пузырек. обернул в объект сортировка. Дальше запутался, помогите!
Словоблудие ни о чем. Ни примеров, ни сравнений, ни альтернатив.

ООП — что имеется в виду — инкапсуляция, полиморфизм или все сразу? Если в Java практически невозможно использовать одно без другого, то в с++ можно написать несколько мегабайт хорошего кода без следов полиморфизма, на одной инкапсуляции. Это ООП или нет? Это плохо или хорошо?

С++ — это мультипарадигмальный язык — прекрасно, пару примеров разных парадигм в студию.

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

Да, но зачем? Поспорить сам с собой? Почему в коде небезопасное легаси из другого языка (stdio.h, printf)?
Где реализация (для сравнения) в рамках идеально вылизанной, всеобъемлющей и оптимальной архитектуры без ООП? Дайте угадаю, там внутри будет тот же printf. Заходим в реализацию printf и что видим? Видим там парсер текста, копирование символов с места на место, кучу malloc и free, псевдо-ООП код, код преобразования int, long, double и других типов данных в текст. И это все загрузится в память, да. Для приведенного примера оно не нужно, нет.

Также невозможно не отметить, что ООП-фичи по определению не блещут производительностью.

Тезис требует подтверждения. Методика исследования и результаты в студию. Примеры брать не из головы автора, а из реальных проектов. В приведенном куске кода автор уже продемонстрировал, что ни C++, ни анализ производительности не являются его коньком.

Следующий тезис — ООП помогает от энтропии только на время. Согласен, но что помогает от энтропии навсегда? По-моему — только rm -rf /.

В моем понимании, каждое такое созвездие[объектов] – не более чем мгновенный снимок образа, сложившегося в голове у программиста

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

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

А что выдается за альтернативу автор поясняет?
Структурное программирование?
Функциональное?
Загляните по ссылке в заголовке поста. Блог автора (4 записи) плюс краткая информация о нём (включая фотографию) рисуют мне следующий образ. Молодой человек работает в геймдеве над игровым движком, его интересы сосредоточены вокруг перформанса. В примерах кода он использует стиль чистого C. Аргументирует в эту сторону (например, цикл по C-массиву, представленному указателем, ему милей, чем использование стандартной библиотеки C++), вплоть до отказа использования не только стандартной библиотеки, но и общепринятых C++ парадигм, например RAII. Ссылается на видео с CppCon 2014, посвящённого Data Oriented Design и чужие блоги (я планирую посмотреть и то и другое). Возможно, он предполагает, что его читатели, также как он, работают над приложениями, в которых перформанс — критичен, а безопасность получающегося кода и скорость разработки — нет. Мне его рассуждения не показались убедительными. Если кому-любо интересно, я бы продолжил после ознакомления с материалами по ссылкам из записей этого блога.

Поверхностно ответ на «Структурное программирование? Функциональное?» — скорее ближе к структурному.

Напомнило про недавнее обсуждение ООП virtual inheritance vs DOD (ECS) из другого поста, может кому—то будет интересно взглянуть https://m.habr.com/en/company/piter/blog/524882/comments/#comment_22270190


Заметьте, что ECS решение позволяет оптимально (не смотря в цикле все объекты типа ITransaction) фильтровать по отдельным компонентам, что в теории важно для задачи фильтрации из статьи по ссылке.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.