Здравствуйте, 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>>void ConvertXmlToFile(xml, file)
G>>{
G>> file.Put(xml.Get("123"));
G>>}
G>>
G>>объект xml — занимается парсингом, file — выводом, а сама функция — преобразование.
G>>Что тут можно от чего отделить и какой код в результате будет?
IT>Ты статью читал?
Читал. Ответь на вопрос выше.
IT>>>Правильно. А где граница между ведёт к усложнению или получишь упрощение?
G>>Граница в правильном применении. Определение выше.
IT>Ты про эту воду в ступе:
IT>IT>Правильность — соответсвие инструмента задаче.
IT>А как определеить соответствие? У тебя есть универсальный метод определения?
Конечно, дл любого паттерна, принципа и даже парадигмы прогнаммирования есть границы применимости, которые описываются авторами патернов. Если задача попадает в эти границы, то соотвествующий паттерн\принцип стоит прмиенять.
В частности для SRP простое условие — в одном компоненте собрано несколько ответственностей.