Вызов метода из параллельного миксина в Python без нарушения MRO или обязанностей ⇐ Python

[Anonymous]

Я работаю над многофункциональным довольно старым игровым ботом со следующей реализацией:
В разных файлах/папках есть множество миксинов (каждый наследует GameBase). Каждый миксин:

- использует атрибуты + базу HTTP для отправки личных API-запросов, стандартизации и обработки ответов

- реализует некоторую конкретную активность для сублокации,

- несет четкую единственную ответственность: обработку определенного действия или группы действий, связанных с ее сублокацией.

- например, StreetLocation имеет более 20 субобработчиков (имена обработчиков в примерах ниже изменены, чтобы скрыть оригиналы)

- self.eat() здесь предпочтительнее, чем self.stomach.eat() - он должен быть делегирован внутри.

- имена функций уникальны, не вызывают проблем MRO и не полагаются на порядок наследования прямо сейчас.

Код: Выделить всё

class GameBase:  # contains all available bot attributes + HTTP communication base methods

class *Handler(GameBase)  # ~50 different hanldlers, ~20 for StreetLocation

MixinGroups:
class StreetLocation(ArenaHandler, FightHandler, CrystalHandler, TalkHandler, ........)
# inherits every sublocation handler + organizes/controls them.
# Provides high-level API methods to the bot.

class HouseLocation(SomeHouseHandler1, SomeHouseHandler2)
# inherits sublocation handlers + organizes/controls them.
# Provides high-level API methods to the bot.

class ShopLocation(SomeShopHandler1, SomeShopHandler2)
# inherits sublocation handlers + organizes/controls them.
# Provides high-level API methods to the bot.

class GameBot(StreetLocation, HouseLocation, ShopLocation)
# Final bot interface. Orchestrates game actions over timers and high-level apis provided by MixinGroups (big-location mixins), decides what to call and how to behave in all.

Проблема в организации кода. В данном случае мне нужно использовать вызов из параллельного миксина. Мне нужно добавить метод в StreetLocation.TalkHandler (TalkHandler наследуется группой миксинов StreetLocation), например TalkHandler.get_angry_in_talk(). При определенных условиях он должен вызвать StreetLocation.FightHandler.headshot().
Важно:

- вызов должен использовать self.headshot(),

- я не могу переопределить headshot() в TalkHandler и меня не должно волновать реализация headshot в TalkHandler.

- я не могу сломать существующий MRO с добавлением или удалением слоев и не должен полагаться на порядок наследования,

- TalkHandler должен оставаться сосредоточенным на действиях, связанных с общением, но иметь возможность использовать вызов метода параллельного миксина.

- IDE и линтеры должны распознавать вызовы методов - если возможно,

- Я знаю о потенциальных проблемах с большими объектами, но это важно только для рассмотрения лучшего дизайна. Миксины всегда объединяются в объекты местоположения, и сам класс миксина не должен использоваться непосредственно вне финального класса — используется только финальный класс. И этот вызов не должен менять дерево наследования.
В настоящее время проблем с MRO нет, поскольку имена методов не конфликтуют. Каждый файл выполняет определенное действие с четкими обязанностями, а неклассифицированные вспомогательные функции нежелательны.
Ограничения и цели:

1. get_angry_in_talk() должен правильно вызывать self.headshot() под self..

2. TalkHandler не должен брать на себя/выполнять несвязанные обязанности.

3. Существующий MRO должен оставаться в силе; не полагаться на порядок наследования.

4. Избегайте введения заполнителей/нереализованных методов в базовом классе. Базовый класс не должен иметь нереализованных методов специально для этого случая (или должен?).

5. Автодополнение IDE и распознавание методов должны продолжать работать.
Вопросы:

1. Разумно ли реализовать этот метод (get_angry_in_talk) внутри TalkHandler, не вызывая побочных эффектов в других миксинах или проблем MRO? (поскольку pylance не смог определить, откуда взялся self.headshot, но код будет работать нормально)

2. Каковы лучшие практики вызова методов из параллельных миксинов в Python при сохранении разделения обязанностей?

3. Не лучше ли разместить этот метод на уровне «локации» (StreetLocation), а не в миксине подлокации? - Но я боюсь, что это нарушит разделение ответственности, поскольку оно по-прежнему принадлежит TalkHandler.
(например, у меня есть конфликт между Q1 и Q3 и мне нужны рекомендации по Q2)
Я нахожу это разделение местоположения/подлокации с оркестровкой довольно чистым, поскольку я могу легко найти, какой код связан с каким-то конкретным местоположением/подположением, и легко изменить его (по крайней мере, если для этого не требуется вызов параллельного миксина - его довольно легко найти/изменить). что-то).
Если этот дизайн считается плохим, то какие существуют альтернативы, которые не полагаются на массу несвязанных вспомогательных функций, со строгим разделением обязанностей, с общим числом около 50 подлокаций, где ~20 — это только обработчик StreetLocation? (при условии, что у меня нет желания перезаписывать так много чьего-то кода, который, на мой взгляд, четко разделен по обязанностям)

Подробнее здесь: https://stackoverflow.com/questions/798 ... or-respons