параметр context (типа B) формируется системой и доступен только для чтения, и переломной встала задача искусственно подсунуть свой context (типа D) с необходимыми методами и данными.
это вам для тестов надо, или «вообще»? если «вообще», то вы что-то не так спроектировали. жаль — не понятна суть задачи… задумайтесь — вы хотите в существующий класс, который имеет свой контекст — подсунуть чужой. как поведут себя остальные внутренние методы? какой контекст они будут использовать во время вашего «специального вызова», до и после него? а если какая-то функция сохранит что-то из «другого контекста», как это повлияет на поведение класса?
не знаю что вы делаете, но есть пару вариантов:
0. если вы пишете тесты — используйте моки или стабы (если это действительно необходимо)
1. BD — просто «соединение» + влияет на context
тут все просто — фабрика: IBdContext getBdContext(C BD), почти как у вас
2. BD — умная, не просто что-то делает а и что-то запоминает + влияет на context
почти тоже самое, но «C BD» может оказаться фабрикой, и как минимум синглтоном.
3. context — просто объект + влияет на BD
паттерн мост. делайте свои реализации IContext, и передавайте им в конструктор «C BD»
4. context — умный, не просто что-то делает а и что-то запоминает + влияет на BD
фабрика IContext(C BD)
5. все умные и что-то помнят — фантазируйте. что-то не так с дизайном.
6. все «тупые» — используйте статические хелперы.
999. задумайтесь, если вам «на мгновенье» надо подсунуть «инопланетный объект» — что то не так.
НО!:
А. если это методы «компарации» — передавайте контекст как опциональный параметр к функции
Б. если у вас древовидная структура с гибкой логикой — используйте композит.
(какой вопрос — такой ответ)
