Cut back on the usage of conditionals while programming and you will probably spot the needed abstractions more easily. Why am I saying this? In my previous post I told you about my application without conditionals. It wasn’t very hard to program even though it was a bit more challenging. I think the outcome is much more readable, less error prone, less code and more accurate abstractions. Let’s get into some of the details.

Design decision analysis

Player factory over ‘factory method’ in Combatant. This was one of the latter decisions I made. The final code looks like this:

public class AutomatorCombatant implements Combatant {
public Player create(String playerName, Army army, Stats stats) {
   return new PlayerAutomator(playerName, army, stats);
public String toString() {
   return "Automator";

The createMethod is sort of a factory-method. In my opinion This adheres more to the Open Closed Principle than a ‘regular’ factory. If I want to add a new combatant/player type. I only need to create those classes and in this case change a player selector to be able to use them in my application. If I had chosen the player-factory style I would be forced to update the factory add player classes and finally the player selector.

An application without conditionals is probably not worth pursuing. On the other hand the extra time added thinking about a design and removing unnecessary if/elses or not introducing a switch-statement out of habit might be worth it.


About Ola Ellnestam

Agile Coach, Systems developer, Agile Practitioner and father of three.

Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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