实用主义和过度设计？

实用主义和过度设计？

2010年11月3日，注定互联网值得纪念的一天，腾讯QQ和360直接火并。我个人对这个事件的发展表示非常的遗憾和失望，这事说到底是中国互联网业的一个耻辱。但无论如何，请你记住一点，谁先挑起的这场“战争”，是那个每天号召保护用户安全，实际骨子里想的都是消灭竞争对手的360。我也希望此次事件后，中国的互联网业能更加自律一点，我们所有人也能能更加正直，真相，有独立思考性一点，当然这个希望也只是狗屁奢望一个。

耻辱的历史也是历史，我们要牢记。既然是值得纪念的一天，已经停写半年多的blog也继续开张吧，有点耐力继续下去，今天和大家一起讨论FLASH小游戏的设计想法，大体目的是，希望在自己的游戏中以后能比较容易增加CP（外部内容提供商）要求的小游戏。我考虑了半天，希望在FLASH和我们的游戏两部都提供一组接口，让两边可以互相调用。而服务器内部也是用接口和SO直接进行调用。

大致的关系图如上，但注意其中的GAME DATA是一个泛指，可能多种数据，设计希望的目的是，

l          小游戏的个数应该是很多的，但是种类是归纳的。（这点可能是最被挑战的）

l          让游戏服务器和客户端都脱离游戏业务逻辑和游戏数据，而只关注接口和其他外层的交互，。

l          FLASH和客户端的接口发生交互，而不和服务器发生任何直接联系，资源下载服务器除外。

l          游戏服务器DLL通过接口和游戏服务器进行交互，

l          FLASH都是CP制作，我希望暴漏给CP的接口让CP越简单越好。（当然接口也会限制策划设计游戏的灵活性）

比如回合制游戏的客户端和FLASH接口就应该有

l          FLASH调用客户端的接口，开始某个关卡

l          客户端回调FLASH的接口，关卡的游戏数据

l          FLASH调用客户端的接口，回合制游戏每个步骤的操作

l          客户端回调FLASH的接口，用户操作回合后的游戏数据

l          客户端回调FLASH的接口，回合制游戏结束了

想完后感觉挺OO的，感觉有点远程过程调用的设计思路，不觉有点飘忽。

比较出乎意料的是开会大家都觉得我的逻辑抽象接口想法过于抽象，不能应对复杂的游戏业务逻辑。他们更加倾向与用单一进一出两个接口（一个接口让客户端调用FLASH，一个接口让FLASH调用客户端），让FLASH和游戏服务器的SO去定游戏的子协议。（这种方法说不上上流，在原来的3D小游戏框架里面我们已经是这样做的，我只是认为对于CP制作的小游戏，让他们关注协议层以及网络接口是错误的）。另外大家的还有一个想法是在这是第一次尝试，不要一开始将就搭建复杂的框架。最后向其他同事妥协了，但同事开始郁闷了……关键是我自己也在怀疑。

抽象肯定是好的，接口的抽象比如带来约束，但是这些约束能否适应未来需求的变化呢？

难道说这到底是一个需求问题？开发同事多年来被反复强奸后已经分不清到底是因为需求导致的变更还是自己设计问题导致了变更呢（骨子里认为两者兼而有之，很多不合理的需求，开发居然不会拒绝，后面又说需求是邪恶的）。又或是我自己多年来OO的毒过多？总是用一些过度设计的想法解决问题，因为子协议的方法已经玩过一次了希望玩点新鲜的？

又或者说本质上这就是一个工作量的问题？因为如果采用简单的一进一出的接口，客户端以后也不用关注接口设计了，客户端最大的摆脱了和这些设计（以后服务器SO模块每个小游戏的开发工作大一些）。而我希望用接口抽象的另外一个好处是，这样设计可以降低以后小游戏的服务器端SO设计难度。（现在越发觉得这个是真相……我好邪恶）

是更加抽象好？还是实用主义第一？

疑惑很多，慢慢想，我还年轻，也许希望后面有答案。

11月3日，PK了3场，胜率0，预测腾讯QQ和360的PK最后的结果是XX部委出来说话双方都安静了，但360扣扣保镖消失，也立此存照