Ear Bleeding Java Generics

In my previous post, I blather on about my adjustment to Java from C#.

Now that I’ve had a little while, I’ve been adjusting a bit better.

I am realizing that a simplistic “port” is not what I am doing.

I am doing a “translation”.

I do not let curly braces fool me.

Just because both are present in C# and Java does not mean that I can express the same concepts in the same way.

Sometimes I cannot even express a concept in a similar way.

I started with my C# classes that deal with boards and mazes.

In C#, these are highly genericized.

So, I set out to write them in Java in a highly genericized manner.

Doing this was a mistake.

Why?

Three reasons.

One, I think my original solution may have been a bit on the “clever” side. The one true thing about all clever code is that it will come back to bite you later. I use generic types for the contents of a board cell, the contents of a maze cell (which is actually a subclass of board cell), the contents of a portal between maze cells. Relying on the language feature in C# that enables me to instantiate these classes, I used them mercilessly. In Java I needed to switch over to interfaces and factory classes, because the templates started to get really confusing.

Two, there was a significant design flaw in my C# code. This is common with organically grown code like this. I have a number of static (read “global”) objects for dealing with things like the item and creature lists. Recently, I decided that this was not the best way to go about things.  I also don’t have one large “game” object, which I normally do in cases like these, to contain all of the subordinate game objects and state. I decided to restructure so that the static classes were no longer static, and that the various tables would be put together into a single tableset, and this tableset object would be given to the various other classes that need them.

When translating to Java, I noticed that things would be a lot easier if everything knew what its parent was, and could talk up and down the hierarchy. There should be the big Game object, which is the parent of the tableset and the maze (which is the chief other object in the game), and so I attempted to do this with typed generics in Java, with a nifty interface (also generic) that allows specification of a type of parent. I was going along quite well until I got to a class that would need five template parameters, at which point I decided to ditch generics entirely, and use interfaces and the “Object” class for the parent.

Don’t get me wrong. I’m fine with generics, but my limit is type parameters. After that, my ears start to bleed.

C# Events, Finite State Machines, and Generic Delegates

I’ve written a lot of finite state machines over the years, so many times that I’ve gotten quite sick of writing the boilerplate for it.

I’m currently working in C# and Silverlight, so I wanted to put together a decent boilerplate for an FSM that met my needs.

Here are my needs:

1. My type I use for my “state” variable is typically either an enum or a string. I need my FSM to be flexible enough to handle either.
2. The C# way of notifying other objects without violating encapsulation is through the use of events and subscriptions to those events.
3. I must be able to perform stack operations on the state.  Often, a state like the help screen or the menu screen isn’t a state on the state diagram, but rather one that we escape into from any state.
4. The FSM must not require any sort of interface to be exposed from state classes (this is sort of a restatement of #2, which is to use events).

Here’s the code.

public delegate void StateTransitionDelegate(StateType theNewState);
public class FiniteStateMachine
{
	public event StateTransitionDelegate OnStateStart;
	private StateType state = default(StateType);
	private Stack stateStack = new Stack();
	public StateType State
	{
		get
		{
			return state;
		}
		set
		{
			state = value;
			Refresh();
		}
	}
	public void Refresh()
	{
		if (OnStateStart != null)
		{
			OnStateStart(state);
		}
	}
	public void Push()
	{
		stateStack.Push(State);
	}
	public void PushAndSet(StateType theNewState)
	{
		Push();
		State = theNewState;
	}
	public bool Pop()
	{
		if (stateStack.Count > 0)
		{
			State = stateStack.Pop();
			return true;
		}
		else
		{
			return false;
		}
	}
	public void ClearStack()
	{
		stateStack.Clear();
	}
}

One of the “nagging issues” for me is that the initial state in the FSM is the “default” value of StateType.  In the case of an enum, it’ll typically be the first one defined.

However, when I am constructing my FSM, the event knows nothing of who it should notify, so I cannot tell everyone which state I’m in, even if I wanted to or tried.

This means that I need to do one of the following:

1. Use a “junk” enum value at the start of the list that indicates “I’m in neutral, or some pre-starting state, uninitialized”, and then later set to a legit useful state value later.
2. Call Refresh() on the FSM once I’m done setting up the list of notifiers.

Neither of these are a big deal.

The really cool part of this is that the FSM has no concept of the internals of the items who added delegates to the event.  Similarly, the objects that do state changes similarly have no clue how everytnig else in the code works.  In my previous schemes, I often had some sort of IState interface that was needed to make this all work. Yay events!