/*
* Abstract Unifier class to select objects from different sources.
*/

abstract class childObjectUnifier
{
    protected $currentObjectLocation;

    public function __construct()
    {
        $this->currentObjectLocation = get_class($this);
    }

    public function getData()
    {
        switch ($this->currentObjectLocation)
        {
             case 'currentServerLoginObject':
                    return $this->currentServerLoginFunction();
                    break;

             case 'remoteServerLoginObject':
                    return $this->remoteServerLoginFunction();
                    break;

             default:
                    die('Current user load not available');
        }
    }
}

/*
* Login Object which exists on the current server.
* This object could still be hit on the current server if the current user load is not high.
* Better utilizes the current server.
*/

class currentServerLoginObject extends childObjectUnifier
{
    public function currentServerLoginFunction()
    {
         return 'Some function on the current server';
    }
}

/*
* This login object could exist remotely, for e.g. a restfull/soap/xml-rpc service
* which could be hit if the current server load is climbing.
* Could possibly use a dedicated 'login' server if user load is exceedingly high on current machine.
*/

class remoteServerLoginObject extends childObjectUnifier
{
    public function remoteServerLoginFunction()
    {
        return 'Some function on the remote server';
    }
}

/*
* The game theory pattern which decides which objects to instantiate based on logical
* decisions made by solid data.
* In this example the current user load.
*/

class GameTheoryPattern
{
    public $currentObject;

    function __construct($iCurrentUserLoad)
    {
        $this->currentObject = $this->baseObjectUponStrategicData($iCurrentUserLoad);
    }

    private function baseObjectUponStrategicData($iCurrentUserLoad)
    {
         switch ($iCurrentUserLoad)
         {
             case $iCurrentUserLoad < 1000:
                    return new currentServerLoginObject();
                    break;

             case $iCurrentUserLoad >= 1000 :
                    return new remoteServerLoginObject();
                    break;

             default:
                    die('Current user load not available');
        }
    }
}

//GetCurrentUserLoad
$iCurrentUserLoad = 1000;

//Create Login Object based on the Game Theory Pattern
$oLogin = new GameTheoryPattern($iCurrentUserLoad);

//Call an function from the unifier class
echo $oLogin->currentObject->getData();

?>

It should be pretty self explanatory – due to the high level comments

feel free to add suggestions or comments – since i’m pretty sure there could be a better way, but for now, just to convey the message it should be sufficient.

as a developer, we kind of try and convince ourselves that developing for mobile and developing for a desktop browser is kind of the same thing.  but we all know that this is a stalling technique for the inevitable, since invariably it becomes a whole different field of play.

every little feature you add, every little flow created and every branch of navigational hierarchy is a challenge on its own.

enter the game theory pattern

this is was where my idea of a game theory patterns came into play.  game theory is a branch of applied mathematics, most notably used in social sciences (economics, biology, engineering etc.).  it is also used a bit in computer science, although referred to in that field as artificial intelligence.

thanks wikipedia

game theory allows someone to apply a bit of mathematics to capture data from a situation and use that data to build a strategic base, which allows you to make decisions to determine your success.

take for example morning traffic – you have 2 routes to take to work – one a bit longer than the other, but the longer route is less likely to be busy.

what do you do?  most of us will take the pro’s and con’s of both routes and use that to base our decision upon.

game theory works exactly, well almost, the same.  except you will probably use a bit of math to finalize your decision (average speed, distance etc.)

so why not use game theory in development, especially in a field like mobile, which is very limiting and very frustating at first.  but the good kind of limitation, the kind of limitation that could possibly create innovation.  the guys behind a phenomenon like twitter decided to limit people to 140 characters.  and despite this limitation, people have found innovative ways to increase the effect of that 140 character limited textual communication.

game theory would allow us to mathematically decide on feature sets, the use of algorythms, objects and could even change the flow of an application.

say on an example mobile application we have 3 major features – chat, activity, content sharing.

which one do we choose as our killer feature, and which would probably make the application more bloated and more problematic to use.  why not use the main variable in the equation to help you decide – the user.

i often secretly chuckle to myself, when a system gets developed for one purpose and all the users start using it for a totally different end result, no one really every thought of, or intended for.  you could use this to your advantage with game theory.

a simple case could be made using application flow as an example.  we have a menu with chat, activity feed and shared content.  which one is more important, which one would you make easier to access for the user.  by simply adding a click count to each feature, you could sort a menu by popularity, rather than obvious choice as this will invariably change someday.

if users decide this month, chat is the next best thing, let chat be number one on your menu – and i know some user interface expert will maintain that consistency is important, but if users consistently choose chat as their most important feature, what would the issue be?

this would change the way you develop and architecture software as well.  since you know chat is gaining in popularity according to your available data, then you should be able to utilize servers better for your chat functionality.  write scaling scripts which would use databases sharding.  and on the other hand, allow your game theory pattern to simplify things – why use a 40 slave/master instances of a database if all you need is one.  eliminate unnecessary overheads in that way – more layers makes for more complexity, makes for more overhead, and will eventually kill your application.

i’ve still got to convince a couple of people to maybe try this game theory pattern approach to development and if, by chance, martin fowler reads this article:

‘please martin, consider this pattern as a topic for a new book! ’