Почему бы не иметь потокобезопасный объект посередине, который служит платформой связи между ними? Этот класс будет иметь свои собственные события, а также свойства и методы, которые обеспечивают способы ввода и извлечения необходимой информации. Вы могли бы даже пойти на шаг дальше, и если у вас одновременно работают несколько мастеров и платформ автоматизации, если они уникально идентифицируемы, я бы установил хэш идентификатора мастера для идентификатора платформы, и ваш объект мог бы обрабатывать сообщения для нескольких пар на одном уровне. время. Для этого нужно быть очень осторожным, чтобы все было поточно-ориентированным, и чтобы общение, которое вы осуществляете, использует только информацию, относящуюся к этой паре мастер-платформа.
Я знаю, что это широкий ответ, но я бы посмотрел на этот подход раньше любого другого. Это дает вам желаемое разделение интересов, а также предоставляет вам коммуникационную платформу, которая может быть настолько универсальной, насколько вы ее себе представляете.
Наконец, слово совета, которое вам, вероятно, не нужно. Вы не должны делать класс связи зависимым от чего-либо, что может привести к возникновению проблемы циклических ссылок. Я хотел бы сделать класс настолько независимым, насколько это возможно, любые объекты, которые ему требуются, должны быть отделены от объектов, которые требуются волшебнику / платформе, если только они не являются достаточно общими по своей природе, чтобы у вас было истинное разделение интересов.
Надеюсь, это поможет.