How to achieve flexible Object Composition?
This is a very hard question to usefully answer IMO, mostly because the model is vastly oversimplified.
Public Sub Fight(ByRef State As Object) Debug.Print State.Name & " slashes at the foe!" State.Stamina = State.Stamina - 1 End Sub
If I made a Barbarian Warrior that fought with a massive warhammer, "slashes at the foe!" would sound like some funny understatement. Who/what is the foe? I know this is all theoretical & simplified (right?), but if we're talking about a game, then the foe needs to actually die at one point, doesn't it?
If we look at how a traditional JRPG might go about this, a
Fight method would need to know the state of both the fighter and its target (let's keep the target singular for now), so for a start, it might go like this:
Public Sub Fight(ByVal fighterState As Object, ByVal targetState As Object) '... End Sub
Basically the role of a
Fight method would be to assess/implement the changes that need to happen on
targetState based on a number of factors involving both
targetState. As such, a better name for it might be
Attack, and we can assume that the
fighterState contains information about what piece of weaponry is currently equipped and whether that weapon "slashes", "pierces", "crushes", or simply "hits" the target. Similarly, the
targetState can be assumed to contain information about what pieces of armor are equipped on the target, and whether and how this equipment is able to deflect/nullify or reduce the amount of damage received. With such mechanics, we can even have a
PoisonBlade slashing the target to deal what was calculated a 76 HP damage, plus a recurring 8 HP poison damage every turn unless the target consumes (or is otherwise given) an
Antidote item to cure their poison state.
Now, whether the fighter is a
Fighter or a
Paladin, or a
BlackMage, makes no difference: what the game mechanics needs isn't different properties and members in each character class. In fact, game mechanics couldn't care less what the character classes are, mechanics are the same for everyone regardless:
Fight is a UI command, an ability like any other. The character is a
BlackMage and has no weapon equipped? Fight off - and deal 1 HP damage, if any. The character is a
Paladin and can decide to "fight" or "cast"? UI commands, not character class design.
How we design class modules is not quite like they do in textbooks with
Dog where the
Dog goes "woof" and the
Cat goes "meow" and all the code did was invoke
Animal.Talk in both cases and poof, glittering polymorphism-through-inheritance!
What I'm getting at is, real-world code doesn't do
Dog classes, not any more than a real-world JRPG game would define different types for each possible character class in the game - an
Enum, maybe, and different assets and resources, definitely; adding a new character class to your game should be adding data, not code. But the game mechanics don't need to be bothered with how different a
Paladdin can be to a
BlackMage or a
RedWizard, because the different skills and abilities of a
Paladin vs those of a
Fighter or a
BlackBelt are where composition should come into play.
See they're not different methods, they're different objects.
Fighter doesn't have "no concept of mana", it's a
PlayableCharacter instance that might be composed of a
CharacterStats object where both the
MP and the
MaxMP properties begin the game at
So we take a step back and look at the big picture, and without writing a single line of code, we visualize how things need to coexist and what needs to be responsible for what, in order for the game to be able to make a
Paladin slash at a
Dragon: as we break down the required components and work out how they all relate to each others, we quickly realize that there's no need to force composition to happen anywhere, it just happens, out of necessity!
In a language that supported class inheritance, you might have
CharacterAbility as the base/abstract class for things like
UseItemAbility, and other classes, each with wildly different implementations for their
Execute method. In VBA you can't do that, so instead you might have an
ICharacterAbilityCommand interface, and
UseItemAbility classes that implement it.
Now we can picture a
CombatController class that knows everything about every actor: there's an instance of a
Red Dragon that yields 380 XP and 1200 gold, has a
WingSpikeAbility, and of course a
FireBreathAbility - its
CharacterStats are such that its
FireBreathAbility will deal somewhere between 600 and 800 fire-elemental damage to our Paladin.
Ha! Noticed that? Just by uttering how things interact with each other, we know that
ICharacterAbilityCommand.Execute needs to take the
CharacterStats of the executing character in order to be able compute just how fierce that dragonfire is. That way we can later reuse the
FireBreathAbility for a weaker
Wyvern monster. And since we're taking in a
CharacterStats object, whether they're the stats of a Paladin, the stats of a Black Mage, the stats of a Red Dragon or those of a Slime, makes no difference whatsoever.
And that sounds very much exactly like the problem you were trying to tackle in the first place - just slightly more abstracted, such that you don't write code that reads like a Dragon Warrior battle transcript ;-)
By having the
CharacterEquipment affect the character's
CharacterStats on equip, and any stats-affecting transient skills baked into the stats as soon as they're acquired/equipped/activated, we remove the need for
ICharacterAbilityCommand.Execute to need anything other than the
CharacterStats of the valiant knight/player, and the
CharacterStats of the dragon/monster.
@Robert, I actually like your code. However, I'm not sure it qualifies as composition. Actually, I think you've discovered a 'mixin' pattern, sort of, (or maybe even the visitor pattern) so congratulations on that. Here is composition as I see it.
So with the default member trick, we ship a Base property that allows access to all the base's classes methods (but not private state, which is a good thing IMHO). But because writing
foo.Base.Bar in code is ugly, we pull a trick to make the Base property the default member so that it can be replaced with just a pair of brackets. Thus, the composition becomes less ugly to look at and no need for a subclass to replicate all the base class's methods.
'* 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
The Fighter class
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
The Paladin.cls class as exported to disk and amended to pull the default member trick.
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