Implement Gear DecoratorsmediumImplement Gear Decorators
Imagine an RPG character getting ready for a fight. They begin with modest stats, then equip a sword, a shield, or speed boots one layer at a time. Each item should enhance the character it wraps, without needing to know whether that character is bare or already wearing other gear.
Your task is deliberately focused: implement only GearDecorator, SwordDecorator, ShieldDecorator, and SpeedBootsDecorator. The Combatant contract, BasicCharacter, and the GameCharacter test harness are already implemented in the starter code.
Every decorator must still behave like a Combatant, answering the same three questions: attack power, defense, and description.
GearDecorator(inner)stores the wrappedCombatantand forwardsattackPower(),defense(), anddescription()unchanged.SwordDecoratoradds10attack and appends" + Sword".ShieldDecoratoradds15defense and appends" + Shield".SpeedBootsDecoratoradds5attack,5defense, and appends" + Speed Boots".
A concrete decorator should override only the behavior it changes. For example, a sword can inherit GearDecorator's defense forwarding instead of reimplementing it.
The provided GameCharacter builds and manages the chain for the tests:
- A new character starts at
10attack,5defense, and"Basic Character". equip(kind)accepts"sword","shield", or"boots", up to six items.unequipLast()removes only the outermost item.attackPower(),defense(), anddescription()read from the current outermost layer.gearCount()reports the number of equipped items.statLine()returns"<description> | ATK: <attack> | DEF: <defense>".
Items may repeat, and every layer counts. Two shields therefore raise defense from 5 to 35. The examples call GameCharacter because it is the public harness, but your code belongs only in the four marked decorator classes.
Example 1:
Input:
Output:
Explanation: A bare character reports the base values from the concrete component, because there are no layers above it yet.
Example 2:
Input:
Output:
Explanation: The sword adds ten attack and passes defense through. The shield adds fifteen defense and passes attack through. Together they read 20 and 20.
Constraints
kindis a lowercase word of at most20characters.- At most
6pieces of gear are equipped on one character. - At most
100calls in total are made across all methods.
Starter Code
Only the decorator classes are unfinished. Define each complete class at its marked location. The shared contract, base component, and public test harness are already implemented; do not rewrite them.
How the design is graded
needs 7/10 to pass- Shared decorator base
Full marks when `GearDecorator` implements `Combatant`, stores the wrapped combatant, and delegates `attackPower`, `defense`, and `description` to it by default. Lose points heavily when it creates a fresh basic character, stores gear names, or omits a forwarding method.
- Gear-specific behavior
Full marks when `SwordDecorator` adds 10 attack and ` + Sword`, `ShieldDecorator` adds 15 defense and ` + Shield`, and `SpeedBootsDecorator` adds 5 to both stats and ` + Speed Boots`, while preserving every value they do not change. Lose points for duplicated base constants or incorrect text.
- Composable independent layers
Full marks when every concrete decorator wraps any `Combatant`, repeated gear accumulates, and descriptions reflect wrapping order without inspecting the wrapped object's concrete type. Lose points for special-casing combinations, mutating the supplied harness, or printing to stdout.
Passing every test is not enough on its own. A submission is accepted only when the design also clears the bar.
| Call | Returns |
|---|---|
| new GameCharacter() | null |
| description() | "Basic Character" |
| attackPower() | 10 |
| defense() | 5 |
A bare character reports the base values from the concrete component, because there are no layers above it yet.
Run checks these cases. Submit also runs a larger hidden set.