Здравствуйте, IT, Вы писали:
VD>>Ну, так назови статью адекватным образом. Например, "Виды сложности и преобразования между ними", или "Видя сложности и как с ними бороться", или "Заметки о том как бороться со сложностью".
IT>Тогда пропадёт вся интрига.
Ничего никуда не пропадет. Да и интриги особой я тут не вижу. Что есть, то есть.
Закона сохранения сложности конечно не в природе. Есть возможность трансформировать сложность из одного вида в другой и возможность уменьшать сложность там где она банально избыточна. Кроме того, конечно же, есть возможность уменьшать сложность методом JPEG, т.е. с потерей качества.
Ты очень правильно затронул данную тему.
На мой взгляд если статью переименовать и несколько доработать, то она станет только лучше и интереснее. За одно отпадет большая часть нападок.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
VGn>>Аналогия суждения: "использование автомобиля всегда ведёт к дополнительным затратам, потому что в соседний ларёк ездить за пивом на авто не эффективно"
IT>Ты не согласен с такой своей аналогией?
Тебя развели, а ты купился.
Твое суждение было "любой (абсолютно) инструмент может быть использован как во благо, так и совсем наоборот...". Если уж строить аналогии, которые в прочем не уместны, то про автомобили нужно было писать "автомобиль может быть использован как по делу, так и не эффективно, например в соседний ларёк ездить за пивом на авто не эффективно".
В таком же, извращенном, виде — это высказывание принципиально ложно, так как нарушает базовые законы логики.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>>>Ну, так назови статью адекватным образом. Например, "Виды сложности и преобразования между ними", или "Видя сложности и как с ними бороться", или "Заметки о том как бороться со сложностью".
IT>>Тогда пропадёт вся интрига.
VD>На мой взгляд если статью переименовать и несколько доработать, то она станет только лучше и интереснее. За одно отпадет большая часть нападок.
Если отпадёт большая часть нападок, то будет не интересно.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, gandjustas, Вы писали:
IT>>Парсинг XML, алгоритм преобразования, генерация выходного потока. Тоже самое как и случае с компилятором: парсинг, преобразования, генерация. G>И так все разделено? Объекты xml и file отвечают за парсинг и генерацию соотвественно, а сам метод за проеобразования.
Так и в компиляторе у нас есть file и file, но почему-то народ над ними строит лексеры, парсеры, генераторы и пр. Не знаешь почему?
G>>>Применять здесь SRP абсолютно незачем. IT>>В данном примере это очевидно и мне и тебе, да и всем остальным. G>Тогда к чему пример был? G>Вроде как цель была показать пример где применение SRP увеличивает сложность.
А я и показал. Бестолковое применение SRP приводит к усложнению. Точнее любое применение SRP приводит к усложнению, а вот положительный эффект под вопросом.
IT>>Ну сам немного подумай. В приведённом примере нужно добавить только одну строчку, а после применения SRP много больше чем одну. G>Не нужно там применение SRP в принципе. В прмиере нету отвественностей которые надо разделять. G>Все рассуждения идут от неверной посылки, следовательно сами рассуждения вполне могут быть неверными.
Пока ты не дашь точный и однозначный критерий когда применять SRP надо, а когда не надо, все эти разговоры будут переливанием из пустого в порожднее. Я для наглядности дал два примера, в обоих из которых применить SRP можно. Но в одном случае это даёт эффект, а во втором бессмысленно. Для наглядности. Ты же утверждаешь, что я не прав, потому что в случае XML -> FILE применение SRP не нужно. Я с тобой соглашусь, что я не прав, если ты мне дашь точное правило для определения границы, где нужно применять SRP, а где не нужно, где у нас белое, а где чёрное.
G>>>Видиимо увеличивается только в случае неправильного применения SRP. IT>>Но ведь увеличивается? G>Любую программу можно написать плохо, давайте теперь дакажем что не стоит применять ни один паттерн, ООП и вообще писать надо только на ассемблере.
Любую программу не просто можно написать плохо, любая программа написана плохо. В том числе из-за того, что нет точного критерия когда и где нужно применять тот или иной паттерн.
IT>>В моём примере с XML -> TXT SRP можно применить во всей красе. В результате мы получим три компонента: парсер XML, модуль преобразования, генератор TXT. В результате твоя точная метрика даст усложнение кода в разы. G>Покажи в коде как это будет. G>Сейчас есть: G>
Здравствуйте, gandjustas, Вы писали:
IT>>Всё верно. Твой пример как раз хорошо показывает зависимость сложности кода от сложности используемых инструментов.
G>От этого сложность самой задачи не меняется.
Сложность задачи меня мало интересует, исключительно как изначальная сложность. С ней в общем-то всё понятно. Интересна как раз сложность получаемого решения.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
VD>Тебя развели, а ты купился.
Ну зачем сразу наговаривать на человека? У нас с ним просто своеобразный стиль общения — он мощно телепатирует, я пытаюсь принять его поток сознания. Пока у меня неважно получается, но прогресс имеется.
Если нам не помогут, то мы тоже никого не пощадим.
Перераспределение сложности означает одну простую вещь — устраняя сложность в одном месте мы всегда добавляем её где-то в другом. Если этого не происходит, то скорее всего мы просто чего-то не видим и не осознаём. Сложность никогда не уходит без следа, она трансформируется и сохраняется в виде других видов сложности. Давайте условно назовём это законом сохранения сложности.
Отсюда следует один очевидный вывод — не существует идеальных способов борьбы со сложностью.
Non sequitur.
Вывод-то не следует!
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>Отсюда следует один очевидный вывод — не существует идеальных способов борьбы со сложностью.[/q]
T>Non sequitur.
T>Вывод-то не следует!
Назови мне идеальный способ. Пожалуйста, я тебя очень прошу!
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, gandjustas, Вы писали:
IT>>>Парсинг XML, алгоритм преобразования, генерация выходного потока. Тоже самое как и случае с компилятором: парсинг, преобразования, генерация. G>>И так все разделено? Объекты xml и file отвечают за парсинг и генерацию соотвественно, а сам метод за проеобразования. IT>Так и в компиляторе у нас есть file и file, но почему-то народ над ними строит лексеры, парсеры, генераторы и пр. Не знаешь почему?
Не вдавайся в демагогию. Можешь в своем коде показать где есть различные отвественности, которые нужно разделять?
G>>>>Применять здесь SRP абсолютно незачем. IT>>>В данном примере это очевидно и мне и тебе, да и всем остальным. G>>Тогда к чему пример был? G>>Вроде как цель была показать пример где применение SRP увеличивает сложность.
IT>А я и показал. Бестолковое применение SRP приводит к усложнению. Точнее любое применение SRP приводит к усложнению, а вот положительный эффект под вопросом.
Не показал, потому что применение SRP там ненужно.
Покажи пример где нужно применение SRP и оно приведет к увеличению совокупной сложности.
IT>>>Ну сам немного подумай. В приведённом примере нужно добавить только одну строчку, а после применения SRP много больше чем одну. G>>Не нужно там применение SRP в принципе. В прмиере нету отвественностей которые надо разделять. G>>Все рассуждения идут от неверной посылки, следовательно сами рассуждения вполне могут быть неверными.
IT>Пока ты не дашь точный и однозначный критерий когда применять SRP надо, а когда не надо, все эти разговоры будут переливанием из пустого в порожднее.
Криетрий прямо из определения: есть отвественноти, которые надо разделить.
IT>Я для наглядности дал два примера, в обоих из которых применить SRP можно.
Покажи где есть отвественности которые надо разделить, а еще хорошо бы и код, который получится в результате.
IT>>>В моём примере с XML -> TXT SRP можно применить во всей красе. В результате мы получим три компонента: парсер XML, модуль преобразования, генератор TXT. В результате твоя точная метрика даст усложнение кода в разы. G>>Покажи в коде как это будет. G>>Сейчас есть: G>>
G>>объект xml — занимается парсингом, file — выводом, а сама функция — преобразование. G>>Что тут можно от чего отделить и какой код в результате будет?
IT>Ты статью читал?
Читал. Ответь на вопрос выше.
IT>>>Правильно. А где граница между ведёт к усложнению или получишь упрощение? G>>Граница в правильном применении. Определение выше.
IT>Ты про эту воду в ступе: IT>
IT>Правильность — соответсвие инструмента задаче.
IT>А как определеить соответствие? У тебя есть универсальный метод определения?
Конечно, дл любого паттерна, принципа и даже парадигмы прогнаммирования есть границы применимости, которые описываются авторами патернов. Если задача попадает в эти границы, то соотвествующий паттерн\принцип стоит прмиенять.
В частности для SRP простое условие — в одном компоненте собрано несколько ответственностей.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, thesz, Вы писали:
T>>Отсюда следует один очевидный вывод — не существует идеальных способов борьбы со сложностью.[/q]
T>>Non sequitur.
T>>Вывод-то не следует!
IT>Назови мне идеальный способ. Пожалуйста, я тебя очень прошу!
Из одного параграфа не следует "вывода" второго. Меня больше ничего не интересует.
Если возвращаться к теме статьи, то ты не определил количественную меру сложности, поэтому не можешь сформулировать и закона сохранения (выглядящего, наверное, как-то так: для двух разбиений одной задачи sum(a_i*c_i)=sum(a_j*c_j), где a_i — веса метрик сложности одного разбиения c_i, а a_j и c_j — (такие же) веса и метрики сложности другого).
Если мы сформулируем это понятие количественно, то мы сможем обнаруживать и "идеальные для данных условий разбиения данной задачи". То есть, такие разбиения {c_i}, что любое {c_j}, отличное от него, будет иметь больший взвешенный суммарный вес. Если, конечно, считать, что a_i одинаково для наших условий — команды, времени и тп.
Как-то так.
Хотя бы сложность по Колмогорову упомянул, что ли.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>Если возвращаться к теме статьи, то ты не определил количественную меру сложности, T>Если мы сформулируем это понятие количественно,
А если не смогем количественно, не отказываться же от практических наблюдениий?
Вобще-то у MS есть количественные алгоритмы оценки в студии. Например Maintainability Index, показывающий сложность(или наоборот,простоту) поддержки кода. Врядли MS не старался его сделать получше, но что получилось всем прекрасно видно.
MaintainabilityIndex в Project и Namespace считается как среднее для классов. Если два класса по 50% то общий индекс 50%. Если добавить делегат(или пустой класс) то у него 100%, и среднее повысится (50%+50%+100%)/3=67%.
А можно ли сказать, что программу станет легче поддерживать если туда набросать много ненужных делегатов?
Да и Cyclomatic Complexity, при суммировании по всему коду не совсем то...
Количественные оценки было бы неплохо. Но есть ли для начала идеи, как хотя бы студийные метрики сделать хоть немного адекватнее? Или что еще добавить туда? Хотя они и не все аспекты создания ПО смогут охватить, но если будут в алгоритмическом виде это повысит полезность.
Здравствуйте, gandjustas, Вы писали:
IT>>Ты статью читал? G>Читал. Ответь на вопрос выше.
Сначала мы с моими вопросами разберёмся, а потом на твои будем отвечать.
G>Конечно, дл любого паттерна, принципа и даже парадигмы прогнаммирования есть границы применимости, которые описываются авторами патернов. Если задача попадает в эти границы, то соотвествующий паттерн\принцип стоит прмиенять. G>В частности для SRP простое условие — в одном компоненте собрано несколько ответственностей.
Это всё бла-бла-бла. Как формально определить ответственности? У тебя или у авторов паттерна есть критерий?
Для меня, например, алгоритм разбора xml, алгоритм преобразования и алгоритм генерации текста — это разные ответственности. Для тебя, как я понимаю, — нет. Всё вместе это называется предпочтения. У меня они свои, у тебя свои. Там где начинаются предпочтения заканчивается логика. И наоборот. Бороться с предпочтениями можно только формальными методами. Я ещё раз повторю свой вопрос. У тебя есть формальные правила для определения применимости SRP?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, thesz, Вы писали:
T>Из одного параграфа не следует "вывода" второго. Меня больше ничего не интересует.
Понятно.
T>Если возвращаться к теме статьи, то ты не определил количественную меру сложности, поэтому не можешь сформулировать и закона сохранения
Не определил по одной простой причине — её не существует.
T>Хотя бы сложность по Колмогорову упомянул, что ли.
Блин, ещё один измеряльщик. Ну тогда сравни мне сложность восприятия безобразно оформленного кода, алгоритмическую сложность кода, объём кода, сложность обучения, необходимую для понимания кода, и сложность понимания поставленной задачи. При этом, желательно, чтобы формула была универсальной для любого программиста.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Silver_s, Вы писали:
S_>Здравствуйте, thesz, Вы писали:
T>>Если возвращаться к теме статьи, то ты не определил количественную меру сложности, T>>Если мы сформулируем это понятие количественно, S_> А если не смогем количественно, не отказываться же от практических наблюдениий?
Да ты посмотри на его практические наблюдения. NS на NS и NS погоняет.
А всё потому, что циферек нет.
Кстати, в дедлайне есть намёк на то, как интуицию переводить в количество.
S_>Количественные оценки было бы неплохо. Но есть ли для начала идеи, как хотя бы студийные метрики сделать хоть немного адекватнее?
Это дело автора статьи.
Хотя есть старые добрые LOC. Очень много показывают.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, thesz, Вы писали:
T>>Если возвращаться к теме статьи, то ты не определил количественную меру сложности, поэтому не можешь сформулировать и закона сохранения IT>Не определил по одной простой причине — её не существует.
Это отговорка.
T>>Хотя бы сложность по Колмогорову упомянул, что ли. IT>Блин, ещё один измеряльщик. Ну тогда сравни мне сложность восприятия безобразно оформленного кода, алгоритмическую сложность кода, объём кода, сложность обучения, необходимую для понимания кода, и сложность понимания поставленной задачи. При этом, желательно, чтобы формула была универсальной для любого программиста.
Взвешенная сумма? Полином?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>>>Если возвращаться к теме статьи, то ты не определил количественную меру сложности, поэтому не можешь сформулировать и закона сохранения IT>>Не определил по одной простой причине — её не существует.
T>Это отговорка.
Ну давай попробуем найти твою количественную меру. Мы её тут в соседней ветке с DarkGray уже месяц ищем. В основном занимаемся сравнением мягкого с тёплым и пушистым.
IT>>Ну тогда сравни мне сложность восприятия безобразно оформленного кода, алгоритмическую сложность кода, объём кода, сложность обучения, необходимую для понимания кода, и сложность понимания поставленной задачи. При этом, желательно, чтобы формула была универсальной для любого программиста.
T>Взвешенная сумма? Полином?
Сумма чего?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Это всё бла-бла-бла. Как формально определить ответственности? У тебя или у авторов паттерна есть критерий?
Конечно есть. http://en.wikipedia.org/wiki/Single_responsibility_principle
IT>Для меня, например, алгоритм разбора xml, алгоритм преобразования и алгоритм генерации текста — это разные ответственности. Для тебя, как я понимаю, — нет.
С чего ты взял? это разные отвественности и они уже реализуются разными компонентами, объект xml отвечает за разбор xml_я, file за генерацию текста, а сам метод Convert за преобразование.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, thesz, Вы писали:
T>>>>Если возвращаться к теме статьи, то ты не определил количественную меру сложности, поэтому не можешь сформулировать и закона сохранения IT>>>Не определил по одной простой причине — её не существует. T>>Это отговорка. IT>Ну давай попробуем найти твою количественную меру. Мы её тут в соседней ветке с DarkGray уже месяц ищем. В основном занимаемся сравнением мягкого с тёплым и пушистым.
Честное слово, я в этом не виноват.
IT>>>Ну тогда сравни мне сложность восприятия безобразно оформленного кода, алгоритмическую сложность кода, объём кода, сложность обучения, необходимую для понимания кода, и сложность понимания поставленной задачи. При этом, желательно, чтобы формула была универсальной для любого программиста. T>>Взвешенная сумма? Полином? IT>Сумма чего?
Количественных характеристик?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
IT>>Ну давай попробуем найти твою количественную меру. Мы её тут в соседней ветке с DarkGray уже месяц ищем. В основном занимаемся сравнением мягкого с тёплым и пушистым.
T>Честное слово, я в этом не виноват.
Ну извини что так получилось. Так будем искать количественную меру или будем заниматься демагогией?
IT>>>>Ну тогда сравни мне сложность восприятия безобразно оформленного кода, алгоритмическую сложность кода, объём кода, сложность обучения, необходимую для понимания кода, и сложность понимания поставленной задачи. При этом, желательно, чтобы формула была универсальной для любого программиста. T>>>Взвешенная сумма? Полином? IT>>Сумма чего?
T>Количественных характеристик?
Каких, чего? Конкретней, пожалуйста, для каждого вида сложности. Нам понадобятся количественные характеристики для определения (я начну, а ты продолжай):
— сложности восприятия кода, даже не знаю что предложить, DG пытался здесь притулить количество вариантов рассмотрения.
— алгоритмической сложности, DG говорил о количестве вариантов поведения кода.
— объёма кода, видимо количество строк или мегабайт.
— сложности обучения
— гибкости
— сложности понимания поставленной задачи (ещё один вид, который я бы выделил в отдельный).
Интересны количесвенные характеристики каждого вида и функции, с помощью которых их можно было бы привести к единой мере для дальнейших манипуляций.
Если нам не помогут, то мы тоже никого не пощадим.
Если нам не помогут, то мы тоже никого не пощадим.
