|
![]() |
#1 |
Участник
|
Цитата:
Соответственно примерно по таким же законам надо работать. Какой документ лучше, вот такой? Цитата:
Цитата:
У этих животных хвосты длинные
Если надо поддерживать всех животных (допустим добавить, что хвост покрыт шерстью), то изменение требует анализа всех вариантов. Если нас волнует только кенгуру нам проще найти поиском ее и уточнить какой хвост у него. Могут быть промежуточные варианты - например нас волнуют все, кроме кенгуру. Так же и фреймворки - например SysOperation эквивалентен разделу в начале документа, где написано: - бывают операции - у операций бывают параметры - если не сказано обратного, то надо : - загрузить параметры из SYsLastValue - спросить параметры согласно типам - сохранить их в SysLastValue - выполнить операцию Далее для конкретной операции описываются параметры (DataContract) и что она делается. Диалог, сохранение и восстановление уже описаны и не надо повторять. Не надо уточнять как работать с разными версиями (там хранится по именам). Если хочется, особенного, можно описать это или атрибутами или кодом в UI Builder. Описанные параметры и операцию можно использовать из других частей документа без дополнительных описаний. RunBase эквивалентен фразе в начале документа: "Есть операции, которые могут показывать диалог и запускаться. Как связаны "показать диалог" и "запуститься" я не знаю, так же операция может сохранить состояние и восстановить ее, как именно - лично дело каждой операции" То есть надо каждый раз повторять: метод main, диалог (создания и получения), сохранение и восстановление и работу с версиями (все же аккуратно поддерживают восстановление из старых версий в unpack, да?). Я вот конкретно иногда забывал добавить строчку в getFromDialog или копировал но не правил и от этого были ошибки. P.S. Это тут было? https://www.youtube.com/watch?v=GRr4xeMn1uU |
|
|
За это сообщение автора поблагодарили: ta_and (4). |
![]() |
#2 |
Участник
|
Цитата:
Если требования для изменений пойдут построчно (наиболее реалистичный вариант, IMHO), то удобнее будет документ с независимыми строками. Если же требования для изменений будут относиться ко всем строкам сразу (маловероятный вариант, IMHO), то удобнее окажется документ "У этих животных хвосты длинные". То есть, выбор варианта документа обусловлен нашим прогнозом на то, как в будущем пойдут требования для изменения проектируемой системы. И тут, о чудо, на практике часто оказывается, что копипаста совсем не так уныла как казалась, потому что она дает возможность вносить изменения независимо от других частей системы, что повышает надежность системы. IMHO, конечно ![]() |
|
|
За это сообщение автора поблагодарили: ax_mct (3), mazzy (2), Ace of Database (2). |
![]() |
#3 |
Участник
|
Цитата:
Цитата:
Если требования для изменений пойдут построчно (наиболее реалистичный вариант, IMHO), то удобнее будет документ с независимыми строками. Если же требования для изменений будут относиться ко всем строкам сразу (маловероятный вариант, IMHO), то удобнее окажется документ "У этих животных хвосты длинные".
Мне кажется тут первый список понятнее - ясно кто подчиняется общему умолчанию а кто нет. У этих животных хвосты длинные: - Лиса - Бобер - Кенгуру (кроме австралийских короткохвостых) - Собака - У лисы длинный хвост. - У бобра недлинный хвост. - Кенгуру имеет длинный хвост (кроме австралийских короткохвостых). - Такой же хвост и у собаки. Цитата:
То есть, выбор варианта документа обусловлен нашим прогнозом на то, как в будущем пойдут требования для изменения проектируемой системы.
В случае кода, мы можем тоже провести замену, или воспользоваться каким-нибудь инструментом для рефакторинга (рефакторинги начинающиеся с inline) Цитата:
И тут, о чудо, на практике часто оказывается, что копипаста совсем не так уныла как казалась, потому что она дает возможность вносить изменения независимо от других частей системы, что повышает надежность системы.
IMHO, конечно ![]() Я не против дублирования в принципе, просто оно должно быть обосновано. |
|
![]() |
#4 |
Участник
|
Цитата:
Сообщение от belugin
![]() Так же и фреймворки - например SysOperation эквивалентен разделу в начале документа, где написано:
- бывают операции - у операций бывают параметры - если не сказано обратного, то надо : - загрузить параметры из SYsLastValue - спросить параметры согласно типам - сохранить их в SysLastValue - выполнить операцию Далее для конкретной операции описываются параметры (DataContract) и что она делается. Диалог, сохранение и восстановление уже описаны и не надо повторять. Не надо уточнять как работать с разными версиями (там хранится по именам). Если хочется, особенного, можно описать это или атрибутами или кодом в UI Builder. и если в случае с RunBase это делается легко и просто, то в случае с SysOperation(где та-же видимость и метки задаются атрибутами) такая "простая" с виду модификация потребует кучу усилий т.е. люди которые делали RunBase продумывали такие вещи, модифицировать SysOperation же довольно сложно |
|
![]() |
#5 |
Участник
|
|
|
Теги |
sysoperation framework |
|
|