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

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

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

IT>Парсинг XML, алгоритм преобразования, генерация выходного потока. Тоже самое как и случае с компилятором: парсинг, преобразования, генерация.
И так все разделено? Объекты xml и file отвечают за парсинг и генерацию соотвественно, а сам метод за проеобразования.

G>>Применять здесь SRP абсолютно незачем.
IT>В данном примере это очевидно и мне и тебе, да и всем остальным.
Тогда к чему пример был?
Вроде как цель была показать пример где применение SRP увеличивает сложность.

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

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

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

G>>Видиимо увеличивается только в случае неправильного применения SRP.
IT>Но ведь увеличивается?
Любую программу можно написать плохо, давайте теперь дакажем что не стоит применять ни один паттерн, ООП и вообще писать надо только на ассемблере.

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

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

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

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

объект xml — занимается парсингом, file — выводом, а сама функция — преобразование.
Что тут можно от чего отделить и какой код в результате будет?

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

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