About class interfaces
Don't expect anything specially brilliant here. This is just an story that show how mastering interfaces can help you in your daily work ( as it has helped in mine )
I think I've blogged about it before, but here I go again. The last three months I've been working developing an AS2 framework to build games. We are approaching our first deadline ( next Friday ), so we don't have too much free time.
So, yesterday, I started the development of five games which are quite similar. We've called them "the disposition games", because, well, you have to place some items on screen in the right order. There are a given number of spots , and when you place one of the given items over it, some rules are checked, and then the item is placed or is moved back to its initial position.
There are five different games ( one is about placing children in the school bus, another one is about choosing the order of some tasks that must be completed before going on vacation… )
The architecture of the games is quite simple. There's a main class ( called "World" that aggregates another class called "Scenario" which contains the logic of the game ). So the world class is in charge of controlling the gaming time, sending data to server, loading the graphic and sound assets. The five games are so similar, that we've tried to build them with as much common code as possible.
We decided that we'll have a swf ( dispositionMotor )where the world is initialized, and that will load another swf ( nameOfGame.swf ), where the scenario and the game rules are contained. There will we only one "dispositionMotor" and five different "nameOfGame".
Right. So, now, there are two possibilities: first, we could have five different "world" classes, each one initializing the correct scenario, or we could try to have just one general "world" that could initialize different scenarios ( this one, this one!! )
Well, our world will have this line of code ( apart from another 400 ):
var controller: deIScenarioController = mcTimeline.getController( newMCContainer );
controller.initScenario( );
this.theScenario = controller.getInterface( );
Where mcTimeline is the timeline where the scenario swf is loaded.
In the first frame of the scenario swf, we have the following code:
this.getController = function( arg: MovieClip )
{
//Instantiates de scenario controller but returns an interface
var myController: cwScenarioController = new cwScenarioController( arg );
return deIScenarioController( myController );
}
The class cwScenarioController looks like
class Code.Ents.cwScenarioController extends ClipController implements deIScenarioController
{
private var theScenario: cwScenario;
private var theClip: MovieClip;
function cwScenarioController( clipParam: MovieClip )
{
super( clipParam );
this.theClip = clipParam.movieClip;
//this.theScenario.initLists( );
}
public function initScenario( param: Object )
{
this.theScenario = new cwScenario( );
this.theScenario.parentClip = this.theClip;
this.theScenario.initLists( param );
}
public function getInterface( ): deIScenario
{
return deIScenario( this.theScenario );
}
}
The interface dIScenarioController code:
interface Code.Ents.deIScenarioController
{
public function initScenario( param: Object );
public function getInterface( ): deIScenario;
}
So, now we have a reference to the controller methods in our world class, not to the controller itself, so we don't mind what the controller class does. We have a reference to methods like initScenario, but we don't mind about its implementation
And the method getInterface( ) of the class cwScenarioController returns another interface, which the world uses to communicate with the different scenarios.
A long post, but after a 13 hours coding sessions, it's been really relaxing..