读四人组的设计模式是一种释怀

         如果让你苦苦干想着怎么样让系统变的更有弹性，的确是件很困难的事情。特别对于我们学生来说，缺少开发经验，每天都捧着那几本基础入门教材就想做出一个弹性十足的模块也并非容易之事。谈到设计模式，许多人都一知半解，或者有许多人都没听过“内聚”与“耦合”。模式固然重要，但也不能死套模式，就像四人组说的，如果你写个“HelloWord”都要找个模式的话，那么你的确已经“生病了”！
        我喜欢把简单的问题更简单，喜欢把复杂的问题变简单。可惜，自己常常感到很难做到。我喜欢带着快乐去学习一门技术，的确这很难。四人组恰恰让我做到了。

下面是一个“交流”，我与老师的交流，或者也可以看成是一件争论，没有对错，今天是对的，明天说不定就是错的。技术没有停止的脚步，只有前进的步伐，这也是我开这个博客的意义。希望与大家一起交流我们共同热爱的计算机技术。

复杂的事情变简单话的法办在我看来，无非于使用“图”了。当然，之前你得先补习补习UML.

这幅图是老师的：

先不要急着一来就开始找错误，因为本来就没有错误。每个人的见解都不一样，但是我们的目的只有一个，让它更好。老师的这幅图很标准，也很简洁。我到认为在软件设计中，看着越舒服的，就可能存在越多的问题。四人组给了我足够多的提示：不要对实现编程，你要学会使用接口。而这一切，都是为了高内聚，低耦合。也许大家都知道（连我这样还没有工作了的，正在上大二的人都知道），目前的软件开发，如果按成本计算的话，后期的维护费用可未惊人（危险间定有机遇），原因只有一个，很难维护，或者不容易维护。说起来也不怪，如果之前你设计出了一堆没有弹性的模块，那么维护的确是件“玄事”。这就是设计中的一大“忌讳”，只顾着对实现设计。就像我所说的：危险间定有机遇，如果在设计的时候，我们就提供了应对需求中可能变化的地方提供足够的弹性，那么我们在后期维护的时候就会变的游刃有余。的确，此时的设计又并非是件“玄事”啦。

 

这是我的图：

对着接口编程，并且把可能变化的地方抽取出来，单独定义成一个接口。就算后期我们需要在需求中添加一辆坦克，我们也不怕了。我们不仅可以继续复用车辆类，而我们也不用担心改变它而影响其他模块间的变化。使用Java语言所带来的好处。新的特性一定有可以使用的地方，不然我们使用它（接口）干什么呢？你没有想到吧？

 

对，这就是设计模式，一个好的模式能让我们不用动太多的脑筋就能有个不错的开始。也许这个里面还有许多缺陷，但是，好的开始是成功的一半。博客是用来交流的，希望大家可以一起交流，一起进步。

个人原创，禁止各种手法或者理由转载。请大家尊重我，谢谢。如需转载，请直接联系我。