Я не совсем понимаю назначение этой структуры классов, которую вы описываете (имена классов меня смущают), но в целом вам могут прийти на ум несколько вещей:
Почти всегда лучшим решением является попытка переосмыслить вашу модель классов, оценивая, например, следует ли вам, например, разделить обязанности классов по-другому, чтобы вы могли лучше использовать наследование и полиморфизм способ.
"Проблема в том, что объект, который я использую,
имеет тип AnimatedCharacter, поэтому я
не могу просто положить его в переменную
тип CharacterPhysics. "
Если вы хотите поместить AnimatedCharacter в переменную типа CharacterPhysics, первая должна расширять последнюю, или у вас должен быть общий интерфейс (или суперкласс) для обоих, а затем введите переменную как таковую. Если это невозможно, мое мнение таково, что вам, вероятно, следует попытаться переосмыслить и реорганизовать всю структуру вашего класса, предполагая, что у вас есть веская «объектно-ориентированная» причина для желания сделать это в первую очередь;).
Если вышеупомянутое невозможно, есть некоторые другие уловки, которые вы можете оценить в вашем контексте:
- Использование mixins может работать как «множественное наследование бедняков». У Дерека Вишусена есть несколько примеров того, как реализовать их в AS3 на flexonrails.net .
- «Вид», реализующий шаблон декоратора с flash.utils.Proxy . Проблема с этим подходом состоит в том, что вы откладываете много проверок ошибок от времени компиляции до времени выполнения, но хорошо то, что вам не нужно вручную писать «проксирующие» реализации всех методов «украшенного» объекта , но вместо этого напишите только одну (
callProperty()).