8. Dragon ADR Damage Make¶
ADR - Architecture Design Records
8.1. Problem¶
Dragon makes damage
8.2. Option 1¶
>>> dragon.attack()
>>> dragon.hit()
>>> dragon.hurt()
>>> dragon.damage()
>>> dragon.wound()
Bad: dragon <-> enemy
Bad: not directed, all methods could mean making damage or receiving damage
Rationale:
Some method names has stronger emphasis on who is making damage to whom.
Consider this: dragon.hurt()
- is that dragon who makes damage or takes
damage?
dragon ---> enemy
dragon -> enemy
dragon <-> enemy
dragon <- enemy
dragon <--- enemy
8.3. Option 2¶
>>> dragon.deal_damage()
>>> dragon.hurt_someone()
>>> dragon.make_damage()
Good: dragon ---> enemy
Bad: to specific
.hurt_someone()
,.deal_damage()
8.4. Option 3¶
>>> dragon.take_damage()
Bad: dragon <--- enemy
8.5. Option 4¶
>>> dragon.damage(ENEMY)
>>> dragon.attack(ENEMY)
>>> dragon.hit(ENEMY)
>>> dragon.wound(ENEMY)
>>> dragon.make_damage(ENEMY)
>>> dragon.take_damage(ENEMY)
Bad: MVC



Problem:
>>> class BankAccount:
... def transfer(destination_account, amount):
... destination_account.deposit(amount)
Bad: other bank of will not share their source code with you, to make a transfer
8.6. Option 5¶
>>> hero.health -= dragon.damage()
Good: simple
Good: can use
@property
for validation if neededBad: encapsulation
8.7. Option 6¶
>>> hero.wound(dragon.hit())
Bad: readability
Bad: requires knowledge of API
Bad: this is responsibility of a controller
8.8. Option 7¶
>>> dragon.get_damage()
Good: readability
Good: easy to add validation if needed
Bad: name
get_damage()
indicate a getter ofdamage
field
8.9. Decision¶
>>> dmg = dragon.make_damage()
Good: dragon ---> enemy
Good: readability
Good: encapsulation