Re[24]: Закон сохранения сложности
От: IT Россия linq2db.com
Дата: 28.07.09 13:38
Оценка:
Здравствуйте, gandjustas, Вы писали:

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

G>И так все разделено? Объекты xml и file отвечают за парсинг и генерацию соотвественно, а сам метод за проеобразования.

Так и в компиляторе у нас есть file и file, но почему-то народ над ними строит лексеры, парсеры, генераторы и пр. Не знаешь почему?

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

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

А я и показал. Бестолковое применение SRP приводит к усложнению. Точнее любое применение SRP приводит к усложнению, а вот положительный эффект под вопросом.

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

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

Пока ты не дашь точный и однозначный критерий когда применять SRP надо, а когда не надо, все эти разговоры будут переливанием из пустого в порожднее. Я для наглядности дал два примера, в обоих из которых применить SRP можно. Но в одном случае это даёт эффект, а во втором бессмысленно. Для наглядности. Ты же утверждаешь, что я не прав, потому что в случае XML -> FILE применение SRP не нужно. Я с тобой соглашусь, что я не прав, если ты мне дашь точное правило для определения границы, где нужно применять SRP, а где не нужно, где у нас белое, а где чёрное.

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

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

Любую программу не просто можно написать плохо, любая программа написана плохо. В том числе из-за того, что нет точного критерия когда и где нужно применять тот или иной паттерн.

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>>Правильно. А где граница между ведёт к усложнению или получишь упрощение?

G>Граница в правильном применении. Определение выше.

Ты про эту воду в ступе:

Правильность — соответсвие инструмента задаче.


А как определеить соответствие? У тебя есть универсальный метод определения?
Если нам не помогут, то мы тоже никого не пощадим.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.