Home > Assignments > problem = new DecoratorProblem (problem);

problem = new DecoratorProblem (problem);

The Decorator Pattern is fun. In my game, I’ve decided that every Ship will have a Weapon and a Shield. My “decorators” are the specific types (sub-classes) of Weapons and Shields, namely RailCannon and TorpedoCannon, and HeatShield and BlastShield, respectively. The idea is that I instantiate a Ship with the default Weapon and Shield, then decorate the Weapon and Shield with the decorators to give the Ship some kick. This allows for multiple decorators to stack onto the default weapon and shields, so if I wanted to upgrade the RailCannon, I could just decorate the weapon with another RailCannon. This just stacks a new RailCannon onto the weapon, so it doesn’t really upgrade the RailCannon, it just doubles the effects of the RailCannon.

Unfortunately with the Decorator Pattern, an object does not know what objects are decorating it, and there is no way to remove a decorator. I noticed this problem when considering the ammunition for my Weapons. Currently, each Weapon has an ammunition, and every time fire() method is called, an ammunition check is made. If the check passes (ammo > 0), then the Weapon fires and decrements its ammunition. The problem is that when the ammunition runs out (ammo == 0), there is no way to refill the ammo because I cannot target the specific decorator. This wouldn’t be much of a problem if I could just remove the empty weapon, and replace it with a new weapon with more ammunition (to simulate a reload), but there’s no way to remove a decorator.

The good news is that I smell another design pattern within this mess of Weapons, RailCannons, and Projectiles. I could very well see decoupling pattern fitting perfectly between these classes, but that is something that I would realize and implement later. Unfortunately, I demand a solution to the problem now. The current options seem to be removing specific weapon ammunitions, and just have a single ammunition count that each weapon decorator can add to. Although this would be easily implemented, it’s not really an ammunition count; it’s a ‘how-many-times-you-can-fire’ count. An example of the problem can be seen here:

  1. A Ship has 3 weapons and an “ammunition” count. Weapon a adds 60 to the ammunition, weapon b adds 30 to the ammunition, and weapon c adds 10 to the ammunition.
  2. This makes the ammunition count equal to 60+30+10 = 100.
  3. Every time the Ship fires, it reduces the ammunition count by the number of decorators, 100 – 3 = 97, since each weapon fired once.
  4. Do this many more times, say 12 more fire()’s. Here the problem occurs. The Ship has fired all its weapons 13 times, but the ammunition of weapon c was only 10, yet weapon c fired 13 times. Moreover, there is still 97 – (12 x 3) = 61 ammunitions left.

Obviously, this wouldn’t be a practical solution.

There also exists the easy-way-out solution of removing ammunition altogether and just allow Ships to fire() infinitely, or at least not be restricted by ammunition. If I chose this option, I would probably try and add a new restriction, like Temperature, that would limit how often a Weapon can be fired within a certain time.

Categories: Assignments Tags: ,
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: