Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Не совсем так. Проверенные времени практики (я понимаю, что ты имеешь в виду — разбиение на модули, выделение абстракций и т.п.) часто изначально подразумевают возможность расширения получающегося кода. Иными словами — изначально-таки расширение предусматривалось как явное требование, просто со временем это требование перестали явно озвучивать. Собственно, структурное программирование — это как раз и есть такая правильная практика, созданная отчасти ради поддержки дальнейшего расширения и сопровождения текста программы.
Да, ты меня правильно понял. Я это и имел в виду. Мой поинт в ответе на первое сообщение был в том, что хорошая программа это не есть минимальная программа (если это не есть отдельное требование, например, при разработке под какой-нибудь микроконтроллер).
ГВ>Скорость разработки и лёгкость освоения, ИМХО, относятся к стилю программирования (а всё, что ты назвал — это именно стили) как... Короче, слабовато относятся. Ну а структурную сложность программ нужно измерять на эквивалентных программах, иначе это чистые домыслы.
Что же тогда делать? Я подхожу с практической точки зрения — сложности/дороговизны создания/поддержки программы. Может я не прав... В соседней подветке предложили использовать цикломатическую сложность для оценки, пока не вчитывался. Если есть существующие тулзы для вычисления, я мог бы погонять ее на кусках проекта написанных в разных стилях.
ГВ>Хотя тот же самый Буч утверждал, что хороший структурный проект (т.е. — оформленный в стиле структурного программирования) ничуть не хуже объектно-ориентированного, тем более — плохого объектно-ориентированного проекта. Проблема, собственно, сводилась к тому, что среди структурных программ чаще встречались ходячие ужасы, чем среди ОО-программ. Во всяком случае, так было во времена расцвета ОО-апологии. Ну, сейчас, как видим, положение выправляется.
Да я, в общем-то, не фанат ООП, если подкинут денег, то готов писать на чем угодно вплоть до ассмеблера VAX Так же готов согласиться, что хороший структурный проект лучше плохого ОО. Но скорее всего, я бы предполчел работать с хорошим ОО, чем с хорошим структурным. Ничего кроме субъективного мнения предложить по этому поводу не могу. Мне всегда казалось, что класс проще в понимании чем разрозненные функции и данные, но что это, и правда, проще я доказать не возьмусь.
У меня есть друг — энтузиаст низкоуровнего программирования, работает сейчас в одном небезизвестном производителе антивирусов. Ну так вот, он умудряется писать на ассемблере программы в несколько десятков тысяч строк, и они нормально стабильно работают (в основном это, правда, всякие конверторы, распаковщики и т.д..) Просто аккурантно работает с памятью, выделяет процедуры, где нужно, соблюдает конвенции на передачи параметров. Тот же стркуктурный подход, но я бы не стал всем советовать так делать.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Son of Northern Darkness, Вы писали:
SON>>Интуиция подсказывает, что искать надо в сторону построения графа объектов программы (функции, переменные, классы...) и пытаться считать метрики на нем.
FR>Цикломатическая сложность
Здравствуйте, samius, Вы писали:
S>А, тогда более-менее понятно. Т.е. выводы основаны на сравнении кода 15-20 летней давности (на чем, если не секрет?) и относительно свежего. ИМХО, в таком случае мог повлиять не только парадигм-шифт, сколько само по себе развитие библиотек/фреймворка. Уже одна только библиотека хороших контейнеров может значительно упростить код, написанный без нее. В дотнете библиотека контейнеров скорее объектно ориентирована, но не без признаков функциональого подхода. А могла бы иметь более функциональный уклон. Так вот, мысль в том, что само использование библиотеки не означает изменение парадигмы, и можно продолжать писать в процедурном подходе используя ОО или ФП библиотеки. Уже только от этого код может оказаться проще, чем оригинальный 20-летний. S>Это не говоря уже о том, что даже в рамках одной парадигмы и одного набора библиотек код одного человека может существенно отличаться от кода другого (или того же, но спустя несколько лет) в аспекте сложности.
Часть кода на C, часть C++, часть C# и C++/CLI. По поводу использования ОО контейнеров в процедурном коде... Да, ты прав. Но еще больший выигрышь будет от использования ОО контейнеров в ОО коде Голословное заявление, конечно, но ничего кроме личного опыта предлодить не могу. Кстати, доводилось видеть и обратные примеры, то есть когда человек с помощью ООП простреливал себе ногу (голову?). Это когда 700 кб кода запихано в 10 классов, половина из которых просто интерфейсы для callback-ов, то есть по сути в 5 классов. Дежурная шутка была: "ну по крайней мере его уволят последним"
S>В свете этого даже мой пример с F# не показателен, т.к. F# несколько более высокоуровневый, чем C#. В идеале было бы взять некоторое множество задач и сравнить решения выполненные на одном языке (допустим C#) в разных подходах (ОО, ПП, ФП)... Это было бы интересно. Только боюсь, что код пера одного автора не будет отличаться разительным образом.
Да, было бы интересно. Но дело даже не в этом, это довольно серьезная инвестиция по времени.
SON>>>>Тоже самое. Предложи объективный критерий оценки, буду очень рад. S>>>Объективный — нет, воздержусь. Косвенные — могу предложить. Например, объем исходников или LOC. Если сравнивать F# и C#, то на F# объем в среднем меньше.
SON>>Ну тут есть два соображения. 1) смотря как ты его используешь, можно писать в ОО стиле используя элементы ФП, как большинство, и делает, скорее всего. 2) критерий не очень хороший. Если я обфусцирую существующую программу на Си, уберу проблемы, идентификаторы заменю на двухбуквенные, программа станет короче, но не проще. S>Согласен SON>>Интуиция подсказывает, что искать надо в сторону построения графа объектов программы (функции, переменные, классы...) и пытаться считать метрики на нем. S>Нужно выбрать метрики, которые имеют смысл для разных подходов. Так, если мы возьмем метрику, учитывающую взаимосвязь классов, то куда ее прикладывать в ПП? А если будем учитывать лишь связи функций и структур данных, то может оказаться что ОО не дает существенного упрощения согласно таким метрикам.
Тут предложили цикломатическую сложность. Будет время, посмотрю, есть ли что-то бесплатное, что умеет считать метрики на основе нее. Правда, обещать не могу, есть чем заняться на работе.
S>Глобальная переменная — отличный пример сложности. Только сложно сказать, для какого из подходов она более характерна? Во времена ПП их не боялись и использовали достаточно широко. И только. Т.е. если в ПП не будем использовать глобальные переменные слишком широко, то все еще останемся в рамках ПП. S>(я работал в институте, где 64-килобайтный файл объявлений глобальных переменных был вариантом нормы, т.е. никого особо не удивлял. Но это не проблема ПП вцелом, это проблема конкретных разработчиков)
S>Что нам предлагает ОО в отношении глобальных переменных? Положить ее в класс? Вобщем-то ничего особенно и не изменилось по сравнению с ПП. Скрыть доступ к глобальной переменной и инкапсулировать работу с ней? Мы могли это сделать и в ПП тоже. S>Самое мудрое решение в отношении глобальной переменной предлагает ФП — избавиться от нее. Точно так же мы можем не использовать ее в ОО/ПП.
Ну ООП предлагает синглтон как стандартный паттерн для реализации глобальной переменной. С моей точки зрения, переменная обернутая в синглтон — это уже неплохо. Мы можем поставить брейкпоинт в геттер/сеттер, логировать изменения, можем управлять временем жизни. Вообще ты прав, конечно. Есть хорошие практики и плохие. Делай правильно, не делай неправильно и выбор инструмента отходит на второй план.
S>В конце концов, после того как мы примем несколько правильных решений, может оказаться что разница в подходах сведется к синтаксической. Вопрос лишь в том, на сколько далеко мы пойдем. Наверняка ведь захочется остаться в рамках теплого и привычного подхода.
Уровень синтаксиса, это как раз еще один уровень сложности. Чем более он прозрачен, тем проще реализовать нужный функционал определенным образом. Я имею в виду, если, например, C++ 11 явным образом поддерживает лямбда выражения, отпадает необходимость городить кошмарные шаблоны, подключать сторонню библиотеку... Если язык поддерживает инкапсуляцию на уровне синтаксиса, на уровне описания интерфейса, то не надо городить огород со статическими глобальными переменными и разбиением на единицы компиляции. Можно много чего еще придумать, но, надеюсь, мысль понятна.
ООП сделано с учетом опыта ПП и при разрабке концепции применение "хороших" практик старались упростить, так чтобы разработчик, идя по пути наименьшего сопротивления, создавал простой и надежный код.
Здравствуйте, Son of Northern Darkness, Вы писали:
SON>Здравствуйте, samius, Вы писали:
SON>Часть кода на C, часть C++, часть C# и C++/CLI.
Да, злая солянка.
SON>По поводу использования ОО контейнеров в процедурном коде... Да, ты прав. Но еще больший выигрышь будет от использования ОО контейнеров в ОО коде Голословное заявление, конечно, но ничего кроме личного опыта предлодить не могу.
Голословно соглашусь.
SON>Кстати, доводилось видеть и обратные примеры, то есть когда человек с помощью ООП простреливал себе ногу (голову?). Это когда 700 кб кода запихано в 10 классов, половина из которых просто интерфейсы для callback-ов, то есть по сути в 5 классов. Дежурная шутка была: "ну по крайней мере его уволят последним"
Прострелить себе что-нибудь можно чем угодно
S>>В свете этого даже мой пример с F# не показателен, т.к. F# несколько более высокоуровневый, чем C#. В идеале было бы взять некоторое множество задач и сравнить решения выполненные на одном языке (допустим C#) в разных подходах (ОО, ПП, ФП)... Это было бы интересно. Только боюсь, что код пера одного автора не будет отличаться разительным образом.
SON>Да, было бы интересно. Но дело даже не в этом, это довольно серьезная инвестиция по времени.
Конечно, не на столько интересно что бы делать один проект 3 раза, даже очень маленький.
S>>Нужно выбрать метрики, которые имеют смысл для разных подходов. Так, если мы возьмем метрику, учитывающую взаимосвязь классов, то куда ее прикладывать в ПП? А если будем учитывать лишь связи функций и структур данных, то может оказаться что ОО не дает существенного упрощения согласно таким метрикам.
SON>Тут предложили цикломатическую сложность. Будет время, посмотрю, есть ли что-то бесплатное, что умеет считать метрики на основе нее. Правда, обещать не могу, есть чем заняться на работе. http://www.campwoodsw.com/sourcemonitor.html
Вроде бы считает на основе цикломатической сложности, возможно с модификациями. Как-то сразу не подумал, что цикломатическую сложность называют и структурной тоже.
SON>Ну ООП предлагает синглтон как стандартный паттерн для реализации глобальной переменной. С моей точки зрения, переменная обернутая в синглтон — это уже неплохо. Мы можем поставить брейкпоинт в геттер/сеттер, логировать изменения, можем управлять временем жизни.
Не согласен. Синглтон для переменной в плане удобства вряд ли лучше геттера. А сеттер синглтону вообще противопоказан, во всяком случае видимый извне. Как и глобальная переменная, синглтон так же создает неявные зависимости, которые выстреливают в ногу в неожиданный момент. SON>Вообще ты прав, конечно. Есть хорошие практики и плохие. Делай правильно, не делай неправильно и выбор инструмента отходит на второй план.
Конечно, правило универсальное. Жаль, что узнаешь о том, как неправильно, когда нога отстрелена
SON>Уровень синтаксиса, это как раз еще один уровень сложности. Чем более он прозрачен, тем проще реализовать нужный функционал определенным образом. Я имею в виду, если, например, C++ 11 явным образом поддерживает лямбда выражения, отпадает необходимость городить кошмарные шаблоны, подключать сторонню библиотеку... Если язык поддерживает инкапсуляцию на уровне синтаксиса, на уровне описания интерфейса, то не надо городить огород со статическими глобальными переменными и разбиением на единицы компиляции. Можно много чего еще придумать, но, надеюсь, мысль понятна.
Да, понятна. Но есть обратная сторона. Пока посторонний человек не разберется с синтаксисом того, что позволяет язык, вряд ли он сможет понять, что именно написано и как это поддерживать.
Т.е. как только мы воспользовались синтаксической возможностью и сделали код прозрачнее, сложность понимания кода не исчезла, просто она ушла в документацию этой синтаксической возможности. Хотя, цикломатическая сложность уменьшится. Т.е. код стал проще, а что бы его прочитать стало нужно знать больше. И часто непропорционально больше, несоразмерно. Но на больших количествах употреблений можно и сэкономить.
SON>ООП сделано с учетом опыта ПП и при разрабке концепции применение "хороших" практик старались упростить, так чтобы разработчик, идя по пути наименьшего сопротивления, создавал простой и надежный код.
Наверное так и было. Только, имхо, сложность программ растет быстрее, чем обилие хороших пратктик позволяет контроллировать сложность. Я не про конкретную программу или проект, вообще в целом.
Практически сложно представить код (например совеременного браузера) в ПП виде. Благодаря ООП, код современного браузера будет значительно проще, чем он мог бы быть в ПП, но сказать что ООП код браузера прост и надежен безотносительно сравнения с ПП — Соответственно, упрощать его далее средствами ООП если и возможно, то вряд ли существенно. А вот ФП (с метапрограммированием), а то и DSL, могут и потягаться с задачей.
Здравствуйте, Константин Б., Вы писали:
U>>Членами каких классов перечисленная функциональность является в Qt? КБ>QStyle, QTextLayout
Насколько я понял, QStyle это базовый класс имеющий специфического наследника для textBox. При этом QStyle отвечает не только за вывод рамочки, а вообще за всю отрисовку контрола. Соответственно состояние QStyleTextBox будет намного более жирным, нежели требуется для отрисовки одной только рамочки. Из-за этого при решение своей задачи я точно также могу столкнуться с ситуацией, когда состояние необходимое для отрисовки рамочки у меня есть, а состояния необходимого для создания QStyleTextBox — нет. Т.е. за счет лишнего абстрактного слоя ситуация в Qt несколько лучше, чем в Winforms, но принципиально проблемы те же самые. Если же подобную функциональность вынести в чистые функции, то такой проблемы не будет в принципе.
В последнее время замечаю что, чем на большее число элементов(функций, интерфейсов) разбита логика, тем легче писать юнит тесты. То есть разбивать (если есть время и желание) нужно хотя бы для целей тестирования.
Здравствуйте, gandjustas, Вы писали:
G>Рациональное зерно в SOLID есть, но очень глубоко зарыто. Проблема в том что Мартин пытался популяризировать принципы, которые сам довольно плохо понимал. У фаулера вышло лучше, так как он больше аппелирует к объектности, моделям итп. Хотя в его книге много явных передергиваний и книга уже давно устарела.
Здравствуйте, AndreyM16, Вы писали:
AM>Здравствуйте, gandjustas, Вы писали:
G>>Рациональное зерно в SOLID есть, но очень глубоко зарыто. Проблема в том что Мартин пытался популяризировать принципы, которые сам довольно плохо понимал. У фаулера вышло лучше, так как он больше аппелирует к объектности, моделям итп. Хотя в его книге много явных передергиваний и книга уже давно устарела.
AM>А что не устарело, если не секрет?
Сложно сказать. Все новое хорошо забытое старое. Если не верить всему что читаешь, а пытаться сопоставить с современными реалиями. Полезное можно найти и у фаулера, и у мартина, и у банды четрырех. Но надо думать головой.
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, Константин Б., Вы писали:
U>>>Членами каких классов перечисленная функциональность является в Qt? КБ>>QStyle, QTextLayout
U>Насколько я понял, QStyle это базовый класс имеющий специфического наследника для textBox.
Неправильно понял. Специфическим наследником будет например QWindowsVistaStyle чтобы рисовать контролы как в Висте.
U>При этом QStyle отвечает не только за вывод рамочки, а вообще за всю отрисовку контрола. Соответственно состояние QStyleTextBox будет намного более жирным, нежели требуется для отрисовки одной только рамочки. Из-за этого при решение своей задачи я точно также могу столкнуться с ситуацией, когда состояние необходимое для отрисовки рамочки у меня есть, а состояния необходимого для создания QStyleTextBox — нет.
Нету в QStyle никакого состояния. Вообще.
U>Т.е. за счет лишнего абстрактного слоя ситуация в Qt несколько лучше, чем в Winforms, но принципиально проблемы те же самые. Если же подобную функциональность вынести в чистые функции, то такой проблемы не будет в принципе.
Тут и так вполне чистые функции. И ООП при этом. Здорово правда?
Здравствуйте, Константин Б., Вы писали:
КБ>Здравствуйте, Undying, Вы писали:
U>>Т.е. за счет лишнего абстрактного слоя ситуация в Qt несколько лучше, чем в Winforms, но принципиально проблемы те же самые. Если же подобную функциональность вынести в чистые функции, то такой проблемы не будет в принципе.
КБ>Тут и так вполне чистые функции. И ООП при этом. Здорово правда?
Не помню уже, что именно Undying подразумевает под чистыми функциями, но в QStyle функции не чистые. По крайней мере те, что пачкают QPainter.
Здравствуйте, Константин Б., Вы писали:
КБ>Нету в QStyle никакого состояния. Вообще.
Если QStyle не имеет состояния, то все функции экземпляра QStyle являются чистыми функциями. Соответственно благодаря широкому использованию чистых функций возможности QStyle по повторному использованию коду много богаче чем в Winforms.
КБ>Тут и так вполне чистые функции. И ООП при этом. Здорово правда?
Так с чем ты тогда спорил? Речь шла о том, что совмещение ООП и чистых функций дает много лучший код, нежели жесткое привязывание функциональности к состоянию. Qt оказалась примером этого.
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, Константин Б., Вы писали:
КБ>>Нету в QStyle никакого состояния. Вообще.
U>Если QStyle не имеет состояния, то все функции экземпляра QStyle являются чистыми функциями. Соответственно благодаря широкому использованию чистых функций возможности QStyle по повторному использованию коду много богаче чем в Winforms.
Тут дело не в чистых функциях, а в том что в Qt вынесли наружу функцию рисования рамки, а в винде — не вынесли.
Очевидно что в недрах USER32 такая функция есть, вся из себя чистая и не-ООПная, а повторно использовать ее — не получится.
КБ>>Тут и так вполне чистые функции. И ООП при этом. Здорово правда? U>Так с чем ты тогда спорил? Речь шла о том, что совмещение ООП и чистых функций дает много лучший код, нежели жесткое привязывание функциональности к состоянию. Qt оказалась примером этого.
Речь шла о том что якобы только ООП-код может не реюзабельным, а не-ООП код реюзабельным получается автоматически.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, Константин Б., Вы писали:
КБ>>Здравствуйте, Undying, Вы писали:
U>>>Т.е. за счет лишнего абстрактного слоя ситуация в Qt несколько лучше, чем в Winforms, но принципиально проблемы те же самые. Если же подобную функциональность вынести в чистые функции, то такой проблемы не будет в принципе.
КБ>>Тут и так вполне чистые функции. И ООП при этом. Здорово правда? S>Не помню уже, что именно Undying подразумевает под чистыми функциями, но в QStyle функции не чистые. По крайней мере те, что пачкают QPainter.
Думаю мы подразумеваем функции результат/действие которых зависит только от переданных параметров. Или что-то вроде того.
Здравствуйте, Константин Б., Вы писали:
КБ>Здравствуйте, samius, Вы писали:
КБ>>>Тут и так вполне чистые функции. И ООП при этом. Здорово правда? S>>Не помню уже, что именно Undying подразумевает под чистыми функциями, но в QStyle функции не чистые. По крайней мере те, что пачкают QPainter.
КБ>Думаю мы подразумеваем функции результат/действие которых зависит только от переданных параметров. Или что-то вроде того.
То есть что-то свое, отличное от http://en.wikipedia.org/wiki/Pure_function. Ок, не буду вмешиваться.
Здравствуйте, Константин Б., Вы писали:
КБ>Тут дело не в чистых функциях, а в том что в Qt вынесли наружу функцию рисования рамки, а в винде — не вынесли. КБ>Очевидно что в недрах USER32 такая функция есть, вся из себя чистая и не-ООПная, а повторно использовать ее — не получится.
Если и не получится использовать, то исключительно из-за того, что эту функцию не сделали публичной. А так вполне можно. Другое дело, что из шарпа напрямую работать с WinApi не удобно, но это уже совершенно другой вопрос.
Собственно из-за того, что код WinApi это в основном чистые функции, он и через двадцать лет живей всех живых (хоть и нынче используется в основном через обертки). Фрамеворкам, в которых функциональность прибита к состоянию объектов, такая продолжительность жизни и не снилась.
КБ>Речь шла о том что якобы только ООП-код может не реюзабельным, а не-ООП код реюзабельным получается автоматически.
Об автоматичности речи точно не было. Чистые функции это необходимое, но недостаточное условие реюзабельного кода.
КБ>Тут дело не в чистых функциях, а в том что в Qt вынесли наружу функцию рисования рамки, а в винде — не вынесли. КБ>Очевидно что в недрах USER32 такая функция есть, вся из себя чистая и не-ООПная, а повторно использовать ее — не получится.
Здравствуйте, Undying, Вы писали:
U>Собственно из-за того, что код WinApi это в основном чистые функции, он и через двадцать лет живей всех живых (хоть и нынче используется в основном через обертки). Фрамеворкам, в которых функциональность прибита к состоянию объектов, такая продолжительность жизни и не снилась.
"Ох уж эти мне сказки, ох уж эти мне сказочники..."
Ты ничего не нарисуешь в окне или на экране, не создав draw context и не передавая его хэндл в каждую функцию для рисования.
Ты ничего не сделаешь с существующим окном, не указав его хэндл.
Ты ничего не прочитаешь из файла, не запишешь, предварительно его не открыв.
Всё это — работа с объектами.
И WinAPI живо не от того, что там якобы нет объектов, а в том, что тебе дали возможность расширять функциональность во всех ключевых объектах. Хочешь нарисовать по-своему? Хочешь переопределить часть реакций? Пожалуйста, всё к твоим услугам (по крайней мере пока речь идёт про окна и тому подобное). Ну ладно, почти всё. Некоторые вещи менять таки не можешь.
Ну да, в WinAPI есть некоторые функции, которые по крайней мере внешне не связаны с объектами. GlobalAlloc, например (хотя там объектом является процесс), или там EnumCodePages. И как ты думаешь, если ты будешь использовать только их, далеко ли уйдёшь?
КБ>>Речь шла о том что якобы только ООП-код может не реюзабельным, а не-ООП код реюзабельным получается автоматически.
U>Об автоматичности речи точно не было. Чистые функции это необходимое, но недостаточное условие реюзабельного кода.
Здравствуйте, netch80, Вы писали:
U>>Собственно из-за того, что код WinApi это в основном чистые функции, он и через двадцать лет живей всех живых (хоть и нынче используется в основном через обертки). Фрамеворкам, в которых функциональность прибита к состоянию объектов, такая продолжительность жизни и не снилась.
N>Ты ничего не нарисуешь в окне или на экране, не создав draw context и не передавая его хэндл в каждую функцию для рисования. N>Ты ничего не сделаешь с существующим окном, не указав его хэндл. N>Ты ничего не прочитаешь из файла, не запишешь, предварительно его не открыв. N>Всё это — работа с объектами.
Ты это к чему все? Где в перечисленном ты увидел выделенное?
N>И WinAPI живо не от того, что там якобы нет объектов, а в том, что тебе дали возможность расширять функциональность во всех ключевых объектах. Хочешь нарисовать по-своему? Хочешь переопределить часть реакций? Пожалуйста, всё к твоим услугам (по крайней мере пока речь идёт про окна и тому подобное). Ну ладно, почти всё. Некоторые вещи менять таки не можешь.
И получилось это благодаря тому что функциональность представлена в виде чистых функций, а не в виде методов жирных классов.
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, netch80, Вы писали:
U>>>Собственно из-за того, что код WinApi это в основном чистые функции, он и через двадцать лет живей всех живых (хоть и нынче используется в основном через обертки). Фрамеворкам, в которых функциональность прибита к состоянию объектов, такая продолжительность жизни и не снилась.
N>>Ты ничего не нарисуешь в окне или на экране, не создав draw context и не передавая его хэндл в каждую функцию для рисования. N>>Ты ничего не сделаешь с существующим окном, не указав его хэндл. N>>Ты ничего не прочитаешь из файла, не запишешь, предварительно его не открыв. N>>Всё это — работа с объектами.
U>Ты это к чему все? Где в перечисленном ты увидел выделенное?
И что не соответствует выделенному? Если нет объекта или объект не в том состоянии, у тебя не получится нормальной работы с ним.
N>>И WinAPI живо не от того, что там якобы нет объектов, а в том, что тебе дали возможность расширять функциональность во всех ключевых объектах. Хочешь нарисовать по-своему? Хочешь переопределить часть реакций? Пожалуйста, всё к твоим услугам (по крайней мере пока речь идёт про окна и тому подобное). Ну ладно, почти всё. Некоторые вещи менять таки не можешь.
U>И получилось это благодаря тому что функциональность представлена в виде чистых функций, а не в виде методов жирных классов.
Нет в описанном "чистых функций", не обманывай себя.
Я подхожу с практической точки зрения — сложности/дороговизны создания/поддержки программы. Может я не прав... В соседней подветке предложили использовать цикломатическую сложность для оценки, пока не вчитывался. Если есть существующие тулзы для вычисления, я мог бы погонять ее на кусках проекта написанных в разных стилях.
Так же готов согласиться, что хороший структурный проект лучше плохого ОО. Но скорее всего, я бы предполчел работать с хорошим ОО, чем с хорошим структурным. Ничего кроме субъективного мнения предложить по этому поводу не могу. Мне всегда казалось, что класс проще в понимании чем разрозненные функции и данные, но что это, и правда, проще я доказать не возьмусь.
