不要使用不理解或不适用的架构或设计模式

 摘自《实战Flash游戏开发》 --<13.4 不要使用不理解或不适用的结构或设计模式>

==========================================================

......我曾亲眼见到人们做过这样的蠢事。

这种是游戏臃肿不堪的做法属于设计过度，与粗鄙简陋的设计不足正好相反，它完全就是一种“犯罪”，就像人们在开发中所犯的罪一样。

比如说，试图将一个非常复杂的设计模式用在一个非常简单的实现上。

由于受到来自Flash行业内的纵容与怂恿，在遇到棘手的紧急情况时，有些开发者就以来许多现有的OOP框架来加快开发速度。

但如果开发者并不能真正地理解架构且不知道如何有效地实现架构，那么整个项目必然会无缘无故地被塞进数量惊人的冗赘代码，而且开发者经常还必须要“重写”架构的预期运行方式，因为从一开始这个架构就被用错了地方。

 

最近我不得不对又一个项目作了一番改动，它是用MVC架构创建起来的，并且它严格遵守着同名的设计模式(MVC)。

但为了保持架构的层次体系，相关代码被分散到了至少20各不同的类文件中。

有些类代码只有1到2各关联的方法或属性，这使得调试过程就像是走在一条洒满面包渣的小路上。

这是个典型的设计过度的例子。

这个游戏的机制还没有复杂多变到必须要用类似这般健壮的系统才能解决的地步，但是，开发者将良好的程序设计与OOP架构这两个概念混为一谈了，所以无论如何他们总要试试看。结果导致游戏出现的Bug可能要用双倍的时间去修补，因为你将很难查出游戏的各部分所用的逻辑代码究竟会藏在哪里。

==========================================================

 

>>评论

RIA开发何尝不是如此。一说到RIA必谈架构 / 框架，框架似乎变成了必需品，是解决所有问题的“银弹”。

框架不是必需品，也不存在“银弹”！

我们通常讨论的架构都是通用型的，能够解决一般性问题，但不能解决个性问题。

实际应用中，要么不使用通用框架、要么自主开发适合特定应用的架构、要么改造框架。

 

类比举例来说：

像google、百度、阿里巴巴、开心网这样的大型企业，它们也使用Linux，也使用Mysql之类的软件，但是都是经过再加工的，自定义的。

以此来满足特定需求。