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

G>А где здесь отвественности, которые стоило бы разделить?

Парсинг XML, алгоритм преобразования, генерация выходного потока. Тоже самое как и случае с компилятором: парсинг, преобразования, генерация.

G>Применять здесь SRP абсолютно незачем.

В данном примере это очевидно и мне и тебе, да и всем остальным.

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

Ну сам немного подумай. В приведённом примере нужно добавить только одну строчку, а после применения SRP много больше чем одну.

G>Правильное прмиенение SRP уменьшает связность между различным функционалом, что позволяет вносить изменения в одном месте не беспокоясь что что-то сломается в другом.

Правильность — это оптимальное внесение сложности применяемым инструментом. Т.е. правильность — это как раз следствие, которое мне сейчас обсуждать не интересно.

G>Видиимо увеличивается только в случае неправильного применения SRP.

Но ведь увеличивается?

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

Т.е. теперь ты уже не согласен со своим предыдущим утверждением? SRP не добавляет сложности?

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

В моём примере с XML -> TXT SRP можно применить во всей красе. В результате мы получим три компонента: парсер XML, модуль преобразования, генератор TXT. В результате твоя точная метрика даст усложнение кода в разы.

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

Правильно. А где граница между ведёт к усложнению или получишь упрощение?