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

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

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

IT>Да ну?

IT>Было:

IT>

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

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

G>>Немного растет объем и немного увеличивается слжность чтения, но сильно уменьшается сложность изменения. Крмое того выделенные классы могут более удачно повторно использоваться, что приведет еще и к сокращению объема кода.
IT>Немного растёт, классы могут. Главное, что сложность модификации растёт, т.е. гибкость кода страдает.
С чего ты взял что сложность модификации растет?
Правильное прмиенение SRP уменьшает связность между различным функционалом, что позволяет вносить изменения в одном месте не беспокоясь что что-то сломается в другом.

G>>Совокупная сложность падает.
IT>Правильно. Но не всегда. В одном случае падает, в другом увеличивается. Падает тоже не просто так. Увеличивается всегда, но при правильном применении падает больше, но увеличивается всегда.
Видиимо увеличивается только в случае неправильного применения SRP.

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

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

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

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

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