Комментарии 10
В любой системе, построенной по принципу ООП, именно объектам в составе «созвездия» уделяется основное внимание. Но я считаю, что взаимосвязи между объектами важны не менее, если не более, чем сами объекты.
Я предпочитаю простые решения, при которых граф зависимостей кода состоит из минимального количества узлов и ребер
Ну а разве ООП не про то же самое? Я имею ввиду принципы из GRASP про взаимосвязи: Low Coupling и High Cohesion.
Сию статью можно было бы чуть менее чем полностью заменить на известное высказывание Винни-Пуха "нужно делать так, как нужно, а как не нужно — делать не нужно!"
Словоблудие ни о чем. Ни примеров, ни сравнений, ни альтернатив.
ООП — что имеется в виду — инкапсуляция, полиморфизм или все сразу? Если в Java практически невозможно использовать одно без другого, то в с++ можно написать несколько мегабайт хорошего кода без следов полиморфизма, на одной инкапсуляции. Это ООП или нет? Это плохо или хорошо?
С++ — это мультипарадигмальный язык — прекрасно, пару примеров разных парадигм в студию.
Да, но зачем? Поспорить сам с собой? Почему в коде небезопасное легаси из другого языка (stdio.h, printf)?
Где реализация (для сравнения) в рамках идеально вылизанной, всеобъемлющей и оптимальной архитектуры без ООП? Дайте угадаю, там внутри будет тот же printf. Заходим в реализацию printf и что видим? Видим там парсер текста, копирование символов с места на место, кучу malloc и free, псевдо-ООП код, код преобразования int, long, double и других типов данных в текст. И это все загрузится в память, да. Для приведенного примера оно не нужно, нет.
Тезис требует подтверждения. Методика исследования и результаты в студию. Примеры брать не из головы автора, а из реальных проектов. В приведенном куске кода автор уже продемонстрировал, что ни C++, ни анализ производительности не являются его коньком.
Следующий тезис — ООП помогает от энтропии только на время. Согласен, но что помогает от энтропии навсегда? По-моему — только rm -rf /.
Естественно. И это ужасно. Пожалуйста, представьте нам парадигму, в которой архитектура будет единственно верным, всеобъемлющем и неизменным воплощением реальной структуры мира с нулевой энтропией, я буду знать чем пользоваться отныне и навсегда.
ООП — что имеется в виду — инкапсуляция, полиморфизм или все сразу? Если в 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) фильтровать по отдельным компонентам, что в теории важно для задачи фильтрации из статьи по ссылке.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
О C++ и объектно-ориентированном программировании