Здравствуйте, gandjustas, Вы писали:

IT>>Увеличивается сложность восприятия кода, растёт объём, в определённой степени проседает гибкость. Это подробно разобрано в статье.
G>От применения SRP гибкость не проседает. Или это не SRP.

Да ну?

Было:

void ConvertXmlToFile(xml, file)
{
    file.Put(xml.Get("123"));
}

Вариант после применения SRP предлагаю додумать самому. Не забудь только про временную структуру данных и разнесение по методам или классам алгоритмов парсинга xml и генерации txt.

Теперь модифицируем:

void ConvertXmlToFile(xml, file)
{
    file.Put(xml.Get("123"));
    file.Put(xml.Get("456"));
}

В данном случае это одна понятная и простая строчка кода. Для варианта с SRP, который, даже не надеюсь, ты нам здесь представишь, это будет не одна и боюсь даже не две строчки. Увеличение сложности модификации в полный рост.

G>Немного растет объем и немного увеличивается слжность чтения, но сильно уменьшается сложность изменения. Крмое того выделенные классы могут более удачно повторно использоваться, что приведет еще и к сокращению объема кода.

Немного растёт, классы могут. Главное, что сложность модификации растёт, т.е. гибкость кода страдает.

G>Совокупная сложность падает.

Правильно. Но не всегда. В одном случае падает, в другом увеличивается. Падает тоже не просто так. Увеличивается всегда, но при правильном применении падает больше, но увеличивается всегда. Ещё не понятно? Тогда ещё раз. Применение (абсолютно) любого инструмента ведёт к усложнению кода и совокупный эффект является большим вопросом.

G>>>В конкретном случае может быть что сложность изменения вообще не интересет, а интересует исключительно объем кода.
IT>>Главное, что упорядочивание кода может привести к усложнению.
G>Не может, см выше. Только в случае неправильного наведения порядка.

'Только в случае' для меня достаточно. Дело в том, что случаи бывают разные и главная проблема в том, что не все из них очевидны. Чем выше сложность системы, тем менее очевидны такие случаи. SRP в этом смысле как раз очень показательный принцип. Когда нужно остановиться, где та грань, после которой применение паттерна или принципа даёт обратный эффект? У тебя есть точная метрика?

IT>>Упорядочивание может усложнять код, что полностью соответствует закону сохранения сложности И понятно почему.
G>Не понятно и не соотвествует. "Может" не означает что будет усложнять всегда.

Всегда и не нужно. Лично мне достаточно того, что я понимаю одну простую вещь — любой (абсолютно) инструмент может быть использован как во благо, так и совсем наоборот. На практике это означает критическое отношение к любому (абсолютно) паттерну или принципу. Даже к полюбившимся в этой ветке упорядочиванию и абстрагированию, т.к. упорядочивание и абстрагирование всегда в 100% случаях автоматически ведёт к усложнению, а вот для достижения упрощения ещё нужно попотеть.

G>Хотелось более формальный критерий получить когда упорядочивание, примененное правильно, будет усложнять код.

За формальностями к VGn.