ООП - в топку!

Эм... Чего-то я теперь не догоняю. Где я выше писал про код? Вроде бы речь шла о дизайне. Поэтому ответ на твой вопрос: ХЗ. Если это фрагмент метода Serialize какого-нибудь класса - то, скорее всего, ОО. Если фрагмент функции main на 100500 строк, которая сначала что-то прочитала, потом что-то записала - то процедурный.

Цитата D_KEY @ 20.05.19, 14:24

Это ОО код или процедурный?

int fd = /* socket, open, etc. */
...
rc = write(fd, ...);
...

Ну, для начала - это код А код, в основном, он не ОО или какой-то еще, а говнокод или не говнокод

Цитата Flex Ferrum @ 20.05.19, 14:27

Вроде бы речь шла о дизайне.

Ну так у нас вот такая простенькая система. Мы в зависимости от некоторых настроек создаем разные объекты, в которые можно "писать" и пишем в них определенные данные (например, получаемые от клиента из консоли).
Что нужно для того, чтоб наш дизайн был ОО?

Цитата D_KEY @ 20.05.19, 14:36

Что нужно для того, чтоб наш дизайн был ОО?

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

Цитата Flex Ferrum @ 20.05.19, 14:41

Абстракция для "настроек", абстракция для "клиентского ввода", абстракция для "хранилищ данных", абстракция для "персистентное хранилище". В процедурной декомпозиции будет иначе: "Прочитали файл с настройками, получили клиентский ввод, проанализировали, определили тип создаваемой структуры, записали туда данные и выгрузили на диск".

Мне кажется, что код при этом будет практически одинаковый.

Цитата D_KEY @ 20.05.19, 14:44

Мне кажется, что код при этом будет практически одинаковый.

Возможно. А возможно и нет.

Цитата Flex Ferrum @ 20.05.19, 13:46

На практике, скажем, какая-нибудь система управления гидронасосом не будет ОО ни разу

А что скажешь по поводу ядра Люникса?

Цитата Flex Ferrum @ 20.05.19, 14:45

Цитата D_KEY @ 20.05.19, 14:44

Мне кажется, что код при этом будет практически одинаковый.

Возможно. А возможно и нет.

А в ОО-системе не нужно будет делать это: "Прочитали файл с настройками, получили клиентский ввод, проанализировали, определили тип создаваемой структуры, записали туда данные и выгрузили на диск"?
С другой стороны, в процедурных сиситемах точно так же широко применялись(применяются) и абстрактные данные(через теги и касты или через таблицы с указателями на функции, например) и полиморфизм(хотя бы через указатели на функции). И это так же закладывается на уровне дизайна.

Цитата D_KEY @ 20.05.19, 14:51

А в ОО-системе не нужно будет делать это: "Прочитали файл с настройками, получили клиентский ввод, проанализировали, определили тип создаваемой структуры, записали туда данные и выгрузили на диск"?

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

Добавлено 20.05.19, 14:55

Цитата JoeUser @ 20.05.19, 14:49

А что скажешь по поводу ядра Люникса?

Ничего. Я его не изучал.

Цитата Flex Ferrum @ 20.05.19, 14:53

Всё зависит от того, от чего ты пляшешь при дизайне системы.

Да от всего ты пляшешь на практике. Даже те абстракции, что ты выделил для примера, шли в том числе от того, что твоя система будет делать.

Цитата D_KEY @ 20.05.19, 14:57

Да от всего ты пляшешь на практике. Даже те абстракции, что ты выделил для примера, шли в том числе от того, что твоя система будет делать.

На практике для разных аспектов системы я применяю разные подходы в плане дизайна. Как-то так.

Добавлено 20.05.19, 15:04
Вот ближе к практике. По ссылке из моей подписи можно попасть на проект Jinja2Cpp. В этом проекте есть интересная задачка - прозрачная работа (на уровне реализации) с std::string/std::wstring. Весьма нетривиальная, как оказалось, задачка.

Добавлено 20.05.19, 15:08

Цитата Flex Ferrum @ 20.05.19, 14:59

На практике для разных аспектов системы я применяю разные подходы в плане дизайна. Как-то так.

Поэтому меня веселят статьи типа тех, что по ссылке топикстартера. Создаётся впечатление, что автор много лет мучился, раз за разом натягивая сов на глобус, просто потому, что его так научили и сказали: "Чуваг, только так правильно!", а потом он вдруг осознал! Бггг...

Цитата Flex Ferrum @ 20.05.19, 14:59

Цитата D_KEY @ 20.05.19, 14:57

Да от всего ты пляшешь на практике. Даже те абстракции, что ты выделил для примера, шли в том числе от того, что твоя система будет делать.

На практике для разных аспектов системы я применяю разные подходы в плане дизайна. Как-то так.

Это понятно. Ты когда абстракции придумываешь, об операциях, которые они будут осуществлять(или над ними будут), обдумываешь?

Цитата D_KEY @ 20.05.19, 15:18

Ты когда абстракции придумываешь, об операциях, которые они будут осуществлять(или над ними будут), обдумываешь?

Да. Но я размышляю над этим в терминах контрактов, активно применяя SOLID.

Цитата Flex Ferrum @ 20.05.19, 15:20

Да.

Тогда в чем разница?

Цитата

Но я размышляю над этим в терминах контрактов, активно применяя SOLID.

И что это меняет?

Цитата D_KEY @ 20.05.19, 15:23

И что это меняет?

Точку и угол зрения. При таком взгляде на дизайн возникают интересные констрейнты типа "принцип минимальных привилегий", "один класс - одна задача", "ответственность класса" и т. п.