Комментарии 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) фильтровать по отдельным компонентам, что в теории важно для задачи фильтрации из статьи по ссылке.

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

Информация

Дата основания
Местоположение
Россия
Сайт
piter.com
Численность
201–500 человек
Дата регистрации

Блог на Хабре