Подходит ли шаблон проектирования цепочки ответственности для решения Python, работающего на аппаратных компонентах

Question

У меня есть решение ООП, написанное на Python, которое в основном сфокусировано на управлении различными аппаратными компонентами, такими как камера, серво, датчики приближения и т. Д.

У меня есть куча менеджеров операций.Менеджер операций - это, по сути, класс, в котором определено несколько открытых методов.Правила, которые я определил, следующие:

1. Different operation managers can call each other’s public methods
2. Multiple operation managers are involved into one specific use-case
3. Operation manager's method execution depends on the result of the previous operation manager (if previous was successfully executed - execute this one, otherwise terminate)
4. Each operation manager must be able to report its failure to a common channel (logging)
5. There’s no need for a transactional behavior (rollback)

Я стремлюсь здесь, чтобы иметь возможность

• легко интегрировать новый диспетчер операций
• Beвозможность протестировать конкретный вариант использования (набор операций диспетчера операций)
• Привести уровень абстракции и разделить разные диспетчеры операций.

Я искалв CoR , но все еще не уверен, лучший ли это вариант для меня или нет.

Answer 1

Неа.Цепочка ответственности полезна для пошаговой обработки чего-либо, когда каждый компонент может или не может быть вовлечен, или может или не может прекратить полное выполнение.Он описывает линейное упорядочение «шагов» и обычно реализуется в терминах связанного списка «ссылок» - конкретных объектов, отвечающих за обработку определенных данных.HTTP перехватчики являются классическими примерами.Для не -линейного упорядочения используется граф, и он не имеет ничего общего с цепочкой ответственности GoF: "маленький", потому что связанный список является своего рода графом по своей природе.

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

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

ЧтоЯ описал, что не шаблон, по крайней мере, не шаблон GoF, хотя, безусловно, является хорошей отправной точкой для специализации ваших требований и ожиданий.