Как добиться гибкой композиции объектов?

@ Роберт, мне действительно нравится твой код. Однако я не уверен, что это можно назвать композицией. На самом деле, я думаю, вы обнаружили своего рода шаблон «микширования» (или, может быть, даже шаблон посетителя), так что поздравляю с этим. Вот композиция, как я ее вижу.

Таким образом, с помощью трюка с членом по умолчанию мы отправляем свойство Base, которое разрешает доступ ко всем методам базовых классов (но не к частному состоянию, что, ИМХО, хорошо). Но поскольку писать foo.Base.Bar в коде некрасиво, мы прибегаем к хитрости, чтобы сделать свойство Base элементом по умолчанию, чтобы его можно было заменить всего лишь парой квадратных скобок. Таким образом, композиция становится менее уродливой, и нет необходимости в подклассе для репликации всех методов базового класса.

'* Test Module
Private Sub StartGame2()

    Dim oPaladin As Paladin
    Set oPaladin = New Paladin
    oPaladin().Name = "Pal"

    oPaladin().Fight '-> Pal slashes at the foe!
    Debug.Print oPaladin().Stamina '-> 99
    Debug.Print oPaladin.Mana
End Sub

Класс Истребитель

Option Explicit

Private pName As String
Private pStamina As Long

Private Sub Class_Initialize()
    pStamina = 100
End Sub

Public Property Get Name() As String
    Name = pName
End Property

Public Property Let Name(ByVal Value As String)
    pName = Value
End Property

Public Property Get Stamina() As String
    Stamina = pStamina
End Property

Public Property Let Stamina(ByVal Value As String)
    pStamina = Value
End Property

'* This is the function that uses the ability to fight.
'* It passes a reference to itself to the `CanFight` class
'* giving it access to its public properties.
'* This is my attempt at composition.
' Public Sub Fight()
'     FightAbility.Fight Me
'End Sub

Public Sub Fight()
    Debug.Print Me.Name & " slashes at the foe!"
    Me.Stamina = Me.Stamina - 1
End Sub

Класс Paladin.cls, экспортированный на диск и измененный для использования трюка с членами по умолчанию.

VERSION 1.0 CLASS
BEGIN
  MultiUse = -1  'True
END
Attribute VB_Name = "Paladin"
Attribute VB_GlobalNameSpace = False
Attribute VB_Creatable = False
Attribute VB_PredeclaredId = False
Attribute VB_Exposed = False
Option Explicit

Private moBase As Fighter

'* To do the default member trick
'* 1) Export this module to disk;
'* 2) load into text editor;
'* 3) uncomment line with text Attribute Item.VB_UserMemId = 0 ;
'* 4) save the file back to disk
'* 5) remove or rename original file from VBA project to make room
'* 6) Re-import saved file

Private Sub Class_Initialize()
    Set moBase = New Fighter
End Sub

Public Function Base() As Fighter
    Attribute Item.VB_UserMemId = 0
    Set Base = moBase
End Function


Public Function Mana() As String
    Mana = "I don't know what Mana even means"
End Function

Это очень сложный вопрос, чтобы с пользой ответить ИМО, в основном потому, что модель сильно упрощена.

Public Sub Fight(ByRef State As Object)
    Debug.Print State.Name & " slashes at the foe!"
    State.Stamina = State.Stamina - 1
End Sub

Если бы я сделал Варвар-воин, который сражался массивным боевым молотом, "рубит врага!" прозвучит как забавное преуменьшение. Кто/что такое враг? Я знаю, что это все теоретическое и упрощенное (верно?), но если мы говорим об игре, то враг должен умереть в какой-то момент, не так ли?

Если мы посмотрим, как традиционная JRPG могла бы сделать это, метод Fight должен был бы знать состояние как бойца, так и его цели (давайте пока оставим цель в единственном числе), поэтому для начала это может выглядеть так:

Public Sub Fight(ByVal fighterState As Object, ByVal targetState As Object)
    '...
End Sub

По сути, роль метода Fight будет заключаться в оценке/внедрении изменений, которые должны произойти в targetState, на основе ряда факторов, включающих как fighterState, так и targetState. Таким образом, лучшим названием для него могло бы быть Attack, и мы можем предположить, что fighterState содержит информацию о том, какое оружие в настоящее время экипировано и является ли это оружие «рубящим», «протыкающим», «раздавливающим» или просто «ударяющим». цель. Точно так же можно предположить, что targetState содержит информацию о том, какие элементы брони экипированы на цели, и способно ли и каким образом это снаряжение отражать/обнулять или уменьшать количество получаемого урона. С такой механикой мы можем даже нанести PoisonBlade порез цели, чтобы нанести рассчитанный урон в 76 HP, плюс повторяющийся урон от яда в 8 HP каждый ход, если только цель не потребляет (или не получает иным образом) предмет Antidote для лечения своего отравления. .

Теперь не имеет значения, является ли боец ​​Fighter, Paladin или BlackMage: игровая механика нуждается не в разных свойствах и членах в каждом классе персонажей. На самом деле игровой механике все равно, какие классы персонажей, механика одинакова для всех независимо от того: Fight — это команда пользовательского интерфейса, такая же способность, как и любая другая. Персонаж BlackMage и у него нет оружия? Отбиться - и нанести 1 урона ХП, если есть. Персонаж является Paladin и может решить «сразиться» с или «кастом»? Команды пользовательского интерфейса, а не дизайн классов персонажей.

Мы разрабатываем модули классов не совсем так, как в учебниках с Animal, Cat и Dog, где Dog говорит "гав", а Cat говорит "мяу", и весь код вызывал Animal.Talk в обоих случаях и пуф, сверкающий полиморфизм- сквозное наследство!

Я имею в виду, что в реальном коде не используются классы Cat и Dog, точно так же, как реальная JRPG не определяет разные типы для каждого возможного класса персонажей в игре — Enum, может быть, и разные активы и ресурсы, однозначно; добавление нового класса персонажей в вашу игру должно быть добавлением данные, а не кода. Но игровой механике не нужно беспокоиться о том, насколько Paladdin может отличаться от BlackMage или RedWizard, потому что разные навыки и способности Paladin отличаются от навыков и способностей Fighter или BlackBeltявляются, где сочинение должен вступить в игру.

Смотрите, они не разные методы, они разные объекты.

Fighter не имеет «понятия маны», это экземпляр PlayableCharacter, который может быть составленный объекта CharacterStats, где свойства MP и MaxMP начинают игру с 0.

Итак, мы делаем шаг назад и смотрим на общую картину, и не написав ни строчки кода мы визуализируем, как вещи должны сосуществовать и что за что отвечать, чтобы игра могла сделать Paladin косую черту Dragon: как мы разбираем необходимые компоненты и выясняем, как они все связаны друг с другом, мы быстро понимаем, что нет необходимости, чтобы композиция сила происходила где угодно, это просто случается по необходимости!

В языке, который поддерживает наследование классов, у вас может быть CharacterAbility в качестве базового/абстрактного класса для таких вещей, как FightAbility, CastSpellAbility, UseItemAbility и других классов, каждый из которых имеет совершенно разные реализации для своего метода Execute. В VBA вы не можете этого сделать, поэтому вместо этого у вас может быть интерфейс ICharacterAbilityCommand и классы FightAbility, CastSpellAbility, UseItemAbility, которые его реализуют.

Теперь мы можем представить класс CombatController, который знает все о каждом актере: есть экземпляр KillableGameCharacter по имени Red Dragon, который дает 380 XP и 1200 золота, имеет BiteAbility, ClawAbility, WingSpikeAbility и, конечно же, FireBreathAbility - его CharacterStats такие что его FireBreathAbility нанесет нашему паладину от 600 до 800 урона от стихии огня.

Ха! Заметил это? Просто произнося, как вещи взаимодействуют друг с другом, мы знаем, что ICharacterAbilityCommand.Execute нужно взять CharacterStats исполняющего персонажа, чтобы иметь возможность вычислить, насколько свиреп этот драконий огонь. Таким образом, мы можем позже повторно использовать FireBreathAbility для более слабого Wyvern монстра. И поскольку мы принимаем объект CharacterStats, не имеет значения, являются ли они статистикой Паладин, статистикой Черный маг, статистикой Красный дракон или слизь.

И это звучит очень точно так же, как проблема, которую вы пытались решить в первую очередь, - просто немного более абстрактно, так что вы не пишете код, который читается как стенограмма битвы воин-Дракон ;-)

За счет того, что CharacterEquipment влияет на CharacterStats персонажа при экипировке, а любые временные навыки, влияющие на характеристики, запекаются в характеристиках, как только они приобретаются/экипируются/активируются, мы устраняем необходимость в том, чтобы ICharacterAbilityCommand.Execute требовалось что-либо, кроме CharacterStats доблестного рыцарь/игрок и CharacterStats дракона/монстра.