Здравствуйте, Евгений Музыченко, Вы писали:

vsb>>При таком подходе главное стараться писать код максимально изолированно

ЕМ>Когда есть возможность оформлять функциональные блоки изолированно, проблем возникает минимум. Самые затыки начинаются, когда нужно делать взаимодействие со внешними подсистемами, которые могу вызывать я, а они — меня. А когда все это еще и асинхронно и многопоточно — вообще вилы. Ближайший пример — фильтры DirectShow.

На мой взгляд этот вопрос стоило бы проработать подробней. Я не знаю API DirectX, но уверен, что всё можно оформить изолированно, с юнит-тестами и потом всё "сцепить" воедино, если поставить такую задачу. Добавить промежуточные интерфейсы где-то, например. Многопоточность — сложная тема, но и там есть свои паттерны, позволяющие бороться со сложностью и изолировать куски кода. Например когда архитектура построена в виде акторов, с одной стороны каждого актора можно тестировать, как обычный однопоточный объект, с другой стороны фреймворк, который обеспечивает запуск и взаимодействие акторов уже считается достаточно протестированным и обеспечивает многопоточность без багов. Проблемы начинаются, когда потоками рулят вручную, с общим состоянием, ручной синхронизацией на мютексах или подобных примитивах. Такой код действительно не протестировать адекватно, поэтому его нужно по возможности избегать, если взглядом окинуть всё не получается.

Впрочем у тебя своя специфика с реалтаймом. То, о чём я пишу, достигается с некоторым оверхедом, для твоих задач его может быть слишком много, а может быть и не много.

Здравствуйте, Евгений Музыченко, Вы писали:

vsb>>При таком подходе главное стараться писать код максимально изолированно

ЕМ>Когда есть возможность оформлять функциональные блоки изолированно, проблем возникает минимум. Самые затыки начинаются, когда нужно делать взаимодействие со внешними подсистемами, которые могу вызывать я, а они — меня. А когда все это еще и асинхронно и многопоточно — вообще вилы. Ближайший пример — фильтры DirectShow.

На мой взгляд этот вопрос стоило бы проработать подробней. Я не знаю API DirectX, но уверен, что всё можно оформить изолированно, с юнит-тестами и потом всё "сцепить" воедино, если поставить такую задачу. Добавить промежуточные интерфейсы где-то, например. Многопоточность — сложная тема, но и там есть свои паттерны, позволяющие бороться со сложностью и изолировать куски кода. Например когда архитектура построена в виде акторов, с одной стороны каждого актора можно тестировать, как обычный однопоточный объект, с другой стороны фреймворк, который обеспечивает запуск и взаимодействие акторов уже считается достаточно протестированным и обеспечивает многопоточность без багов (ну почти без багов, дедлок скорей всего всё ещё возможен, но всё же многие баги устраняются). Проблемы начинаются, когда потоками рулят вручную, с общим состоянием, ручной синхронизацией на мютексах или подобных примитивах. Такой код действительно не протестировать адекватно, поэтому его нужно по возможности избегать, если взглядом окинуть всё не получается.

Впрочем у тебя своя специфика с реалтаймом. То, о чём я пишу, достигается с некоторым оверхедом, для твоих задач его может быть слишком много, а может быть и не много.