Re[25]: Закон сохранения сложности
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 29.07.09 04:16
Оценка:
Здравствуйте, 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 простое условие — в одном компоненте собрано несколько ответственностей.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.