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

bnk>Если все интерфейсы и протоколы взаимодействия фиксированы, ты можешь контролировать (проектировать) только ту часть, которая связана собственно с функциональностью.
bnk>Я бы тогда вообще не парился по этому поводу, а напротив, радовался — за тебя все уже спроектировали, тебе осталось только реализовать как сказано, добавив свой кусочек.

Когда надо добавить именно локальный "кусочек" (например, расширение Explorer'а в винде, чтобы показывать свои пункты в контекстных менюшках), то отдельный этап проектирования даже в голову не приходит.

А когда нужно сделать, например, драйвер, который не просто тупо программирует устройство и обслуживает прерывания, но и расширяет его функциональность, гоняя какие-нибудь асинхронные обработки в параллельных потоках, то классическое проектирование мало что дает. Выстраиваешь изящную иерархию и вроде бы корректное взаимодействие, а потом оказывается, что уведомление о каком-нибудь событии присылается в неподходящем контексте. Делаешь, как советует дядя Боб, 100500 мелких функций, вызывающих одна другую в разных комбинациях, а потом выясняется, что эти комбинации должны работать на разных приоритетах, где доступны не все ресурсы и не все возможности API. Делаешь меньше критических секций, используя их для крупных блоков кода — получаешь тормоза, делаешь больше — получаешь дедлоки. Надежных способов бороться со всем этим не придумали — только разнообразные костыли и эмпирика.

А еще, когда делаешь подобные расширения — они часто вообще не заработают, пока не напишешь практически все. Для пресловутого интерактивного приложения, в котором за менюшки дергает только юзер, можно написать функции-затычки — тестировщику этого достаточно. А в сложносвязанной подсистеме нужно написать 80-90% всего когда, чтобы она более-менее зашевелилась. И это тоже сильно напрягает — фигачишь неделю, месяц, и даже не знаешь, будет оно нормально работать в таком виде, или придется переписывать половину. Отсюда и прокрастинация.