Examples generic data fetching.

gistfile1.java

package at.nocheat.examples;

/**
 * Examples for accessing data with a central storage (not complete, not 100%
 * correct). This object actually might be the general PlayerData object to be
 * obtained from the actual DataBroker, we leave out Player/name arguments to
 * leave that open.
 * 
 * I am using CheckType to confine the data types, there could be other types of
 * data stored, so one might name methods differently (getCheckData).
 * 
 */
public class DataBroker {
	public static interface CheckType {
	}

	public static interface MovingData {
	}

	public static interface DataObject {
	}

	/**
	 * Likely not to happen, since we have generic check registration. Also
	 * static access as with ncp is out of the question (imnsho).
	 */
	public MovingData getMovingData() {
		// Check if data instance is present, check if factory present, or
		// return null.
		return null;
	}

	/**
	 * Creepy: return some general Object, even if using some "DataObject" that
	 * check data has to extend from. Now the check has to do instanceof checks
	 * and cast.
	 * 
	 * A variation would be public DataObject getData(CheckType checkType,
	 * Class<?> dataType) for
	 */
	public DataObject getDatasimple(CheckType checkType) {
		// Check if data instance is present, check if factory present, or
		// return null.
		return null;
	}

	/**
	 * Passing the class could help doing the generics (though not entirely
	 * elegant). Passing the class allows direct lookup for efficiency.
	 * 
	 * To my reading of future compatibility questions (npcs...) having data
	 * objects linked inside of a container object for the player is the choice
	 * to make, so this might be my current preference.
	 * 
	 * Variation would be to add a CheckType argument for multiple data types
	 * per check type.
	 */
	public <T> T getData(Class<T> dataType) {
		// Internally casting may be used but function and type-safety should be
		// guaranteed for the normal case.
		// Check if data instance is present, check if factory present, or
		// return null.
		return null;
	}

	/**
	 * Minimal generic variant. Not sure about lookup speed!
	 * 
	 * @return
	 */
	public <T> T getData(CheckType checkType) {
		return null;
	}

	// ////////////////////////
	// Other approaches:
	// ///////////////////////

	// The central access is only used to store factories and access mappers,
	// for fast access those are used directly by the checks.
	// In such design the central data managing interface is also serving as a
	// broker rather, the methods to get a players data may still be present but
	// are not meant to be highly optimized.
	// For fast access the mappers/access-objects which handle only the precise
	// types of data can be retrieved from here,

	// Disadvantage: this demands to store players data in a map with player
	// names as keys or similar and not all check data objects in one central
	// player data object.
	// This actually might be a show-stopper for general use.

	/** Fast access object. */
	public static interface DataAccess<T> {
		/**
		 * This one should actually be a mapper not just for one player, but all
		 * players (or other contexts).
		 */
		public T getData();
	}

	/**
	 * Slow access method to get the fast access object.
	 * 
	 * Typical problem to be expected: <br>
	 * What with reloading and changing the data factories?
	 * <ul>
	 * <li>Might add a callback object.</li>
	 * <li>Demand checks to register listeners (inconvenient).</li>
	 * <li></li>
	 * </ul>
	 * 
	 * Depending on how this works out, there could also be a class argument.
	 * 
	 * @return
	 */
	public <T> DataAccess<T> getDataAccess(CheckType checkType) {
		// Check registry etc.
		return null;
	}

}