Week 16 – Design Patterns

1. Factory

Creates objects without exposing the instantiation logic to the client and Refers to the newly created object through a common interface. (oodesign.com)

The tower defense app makes use of three interfaces so far.

1. The first interface is called "IStatusBar". It is responsible for the status right at the top while being in the game. This interface enables us to interact with the status bar more easily.
2. The second interface is called "ISettingsManager". This interface is used for all functionalities which enable a user to toggle the app settings. Using this interface, we can always call just one method and provide a setting type as an enum which makes the change of settings very handy.
3. The third interface is called "IMoneyListener" and controls the change of money while being ingame. For example, if a player upgrades a tower, the money-change information is passed from the UpgradeAndSell-activity to the game.

Concerning the naming style for our project, all interfaces start with an "I" and all abstract classes start with an "A" to immediately recognize the type of those classes. Especially, this convention simplifies reading outside of Android Studio, e.g. on GitHub.

2. Abstract Factory

Offers the interface for creating a family of related objects, without explicitly specifying their classes. (oodesign.com)

Abstraction is one of the most important design patterns in the tower defense game. It is used in many parts of the project. In this section, we want to point out the most interesting usages of abstraction.

• Tower: A player is able to build several different towers such as an ArtilleryTower, a FreezerTower or a BoombasticTower. All those towers consist of common functions (coordinates, image-attribute, damage, range, ...) and tower-specific functions (freezing, area damage, tower rotation, ...).
• Bullet: A bullet becomes fired by a tower. Commonly, a bullet has got attributes like coordinates, a target position and a target enemy. In its specific implementations (Bomb, SnowFlake, Projectile, ...), changing functionalities (freezing, detecting multiple enemies, ...) are defined.
• Enemy: Enemies also share several attributes such as coordinates, life points, revenue and many more. In its implementations, more specific things are defined, e.g. the rotation of its image, its behaviour when being hitted or its values.

"AMatch", "AWave", "AMenu" and "ATimerUsage" are more examples of abstraction in our project and the whole structure of using this design pattern enables us to create and adjust new implementations of all those types, which is a very big advantage when adding new features or adjusting consisting features for more than one implementation. As a result, it reduces the amount of code massively.

3. Object Pool

reuses and shares objects that are expensive to create. (oodesign.com)

In an earlier state of our project, we had a class called "ObjectStorage". In this class, all needed object-instances for keeping the app operating have been maintained (e.g. GameActivity, Game, MatchField and many more). Some weeks/months ago, this was a very easy-to-use solution but performance intensive as well because the Android framework is not designed for holding a lot of instances which are not permanently necessary. Because this design pattern is not suitable for our project anymore, we got rid of it in the beginning of the 4th semester.

Conclusion

Summarizing, we can conclude that design patterns are already used in our project from the beginning of development, which probably enables us to develop new features comparatively quickly. Because of some restrictions due to our framework and the requirements of the app itself, we are not trying to apply as many design patterns as possible and stick to the patterns which suit best to our project.