cocos2d-x开发: 如何从项目中分离出接口范例

cocos2d-x开发,包括核心模块接口开发和脚本部分的业务逻辑实现.从上层应用需求开始说,脚本在做业务逻辑实现的时候, 很多时候都需要依赖底层的接口功能,但是不是所有的人都可以游刃有余的去明白该怎么使用下层的接口,这不仅仅是语言的区别,其中还包括接口开发者在设计之初就期望的使用方式问题,所以一般都应该提供接口使用demo,由于我都是使用lua,所以我习惯的称之为unittest,接口功能测试则是以testcase的方式呈现.其实也就只是一种叫法. p> 

p>先来说一下为什么我会做这样子的区分,我见过一些项目,要不然就是不提供使用范例,就是将各种测试都写在项目的入口文件那里.假如我们的引擎进入luaEngine之后进入的是src/main.lua文件中.那么按照很多没有分离好的项目的做法就会出现在main.lua文件中做一个变量.然后判断是进入游戏,还是进入测试,还是进入工具模式等等.程序员嘛,我们可以不纠结于这个实现的过程,结果也算是实现了各个方面的功能.不过,我还是要来分析一下: 项目开发毕竟是多个部分合作开发的,我们并不希望策划在使用我们提供的工具的时候还要自己手动去改配置文件.另外,由于初期就是为了方便将各种测试都堆叠在项目的某个文件里面,当然好的习惯不一定会被大家学习,这种坏习惯就很容易传染.后面每一个人就都会习惯这种简单的测试方法,认为这种测试堆叠的方法是理所当然的.最后的结果就是,堆测试的文件基本就是没法看了.

p> 

p>最后也是最主要的一点,我认真思考了一下,做下层接口,写范例代码是为了什么？其实就是作为对api不足的补充,更好的是某种情况下,达成某正规范,是可以让大家很快的熟悉接口的使用方法.我始终坚信,接口的设计者在实现的时候就应该会想到该如何更好的去使用自己写的接口.上面说了很多,希望能够准确的表达我的意思, 如果看不懂, 可以看下面我的思路以及实现,相信还是很容易看得懂的.

p> 

p>我先想到的是将除了项目业务逻辑实现部分的其他相关,像是工具呀,接口范例呀这些都分离出来,要做到这样子并不难,无非是在项目脚本目录的同级目录穿件一个新的文件夹,另外提供一个新的入口文件.就像下面这样子:

p> 

p> 

p>1 frameworks

p>2 runtime

p>3 res

p>4 src

p>5      --main.lua  --我们通常看到的游戏入口文件

p>6      --Tests

p>7              --TestsController.lua -- 测试入口

p>8      --Tools   -- 如果需要,工具部分入口.

p> 

p>结合我前面的出发点,我不希望更改脚本或者是配置文件做到这样子.不过也好解决,我们都知道,无论是在win下还是在linux下面,应用程序在运行的时候是可以解析命令行参数的.当然在Linux下面就是解析main函数的argc和argv,而在win下面也是同样,我们可以解析lpCmdLine,或者是__argc,__targv(tchar.h).关于win下面的这部分因为涉及到unicode的问题,所以我才会写成这个样子的,不过大家应该都会明白的.说到这里,应该很好明白如何去实现这部分的功能了.我以win32为例,代码如下:

p> 

p> 

p> 1 AppDelegate.h

p> 2 public:

p> 3     void setCmdLine(const std::string& cmdline)

p> 4     {

p> 5         this->M_cmdline_ = cmdline;

p> 6     }

p> 7     std::string getCmdLine() const

p> 8     {

p> 9         return this->M_cmdline_;

p>10     }

p>11 private:

p>12     std::string getCmdByFlag(const std::string& flag, const std::string& defaultValue);