设计模式初阶段总结

ID:75926 · 发表于 2015-4-2 22:03

　　　　寒假回家原计划是好好摸摸ANDROID的，结果因为手贱拿错书搞了范例大全回家，一水儿的范例代码，只能用来当手册或者习题册，想学点理论的话这玩意儿不适合，所以就搁置了。还好顺手带了本讲设计模式的书回来，姑且看一看，小小总结一下第一阶段的学。

　　　　我坚信，一切所谓的思想和方法都是在建立在一种本质和基础之上的，那就是要以最短时间开发出最优秀的产品。话虽然说的没错，作为学生的我，那种脱离实际的学生式的空想让我忽略了很多十分重要的东西。比如说，实际开发过程，接手一个项目，不可能像学校里做试卷那样是个定死的题目，而是一串时刻都在变化的需求（夸张了点，大方向基本不会变，小变化经常出现）。再比如说，实际开发过程并不会是单打独斗，而是和诸位同僚一起共事合作，这种情况下的程序设计不可能任自己天马行空，如何跟他人的代码恰接是个十分关键的问题。

　　　　结合这几点和某次实际的经验，感触很深。觉得那种“土方法”编程是不可能在实践中得以生存的（自己随手编个小程序那不叫实践，我说的是日后工作时干的项目）。书上曾有一文以”代码无错就是优？“为开头，我觉着很能警示人。面对书上提出的种种异常苛刻的编程环境，我无从下手。但我很清楚，这并不只是假设，是作者自身十几年工作历程中经常会出现的很现实的情况。

　　　　说了很多废话，先谈谈对最根本的思想”依赖倒转原则“和”高内聚，低耦合“的理解。首先这两个概念非常精辟地概括了OO中的最重要的注意事项。也正是这两个概念才能使得OO比之传统的编程有其过人之处，而不会只是一种没有意义的只是为了标新立异的概念而已。根据我的理解，没有这两个概念支持下的OO编程不回归C语言式的面向过程的老路子而不必很装逼地面向对象。书中在描述以上两个概念的过程中不断让我想到电脑主板这样一个很具象的事物。之所以这么认为是因为我觉得，最完美的OO编程就好比是这么一台电脑，一个程序就是这台使用中的机箱。如何构建这样一台可以使用的机箱？先做一个基础，或者可以称其为框架，就像主板。主板上有各种插槽，以实现其功能为目的的各种插槽。再往上面插上各种需要的模块，通过电路或者导线或者其他什么的连接在一起，就可以使用。这样做的一个显而易见的好处就是：某一模块坏了不必把整台电脑都废了换新的，显卡坏了换显卡，内存坏了换内存，仅此而90已。而且买电脑的时候选购显卡并不需要考虑内存是怎么样的，是什么样的牌子或者型号，只要考虑是否跟主板上的插槽对应的起来就行（当然有点绝对，实际配电脑的时候还是很有讲究的，这里只是一种理想情况，稍后会有说明）；待到买内存的时候也只需要考虑是否能对应得上内存插槽。如果国际上有一个统一的规范和标准的话，全世界所有的厂商都可以尽情地生产通用的设备，而不需要定制，这也是电脑硬件发展如此迅速的主要原因之一。
　　　　扯远了，言归正传。以上的例子就是”高内聚，低耦合“的体现——显卡内聚度极高，但是却不与搭载在主板之上的其他设备相耦合，一切看起来是这么完美和令人兴奋。但也可以看出来，这条原则要求的是尽可能高的内聚和尽可能低的耦合，绝对而纯粹的内聚是不存在的，没有耦合也是不可能的。就好比买显卡的时候总不能太过分，总应该与其他外设处于同一水平层面，否则电脑将出现很多意想不到的情况。

　　　　关于依赖倒转，我理解的还很不足，至少应用到实践中还是十分生疏困难甚至于无从下手。依赖倒转讲究的是编程要面向接口依赖接口而不能依赖具体的实现和细节。关于这个概念我自己也有一个例子。比如说金字塔，那么高的堆起来，上面的石头压在下面的石头上，可以比作上面的石头紧密的依赖着下面的石头。如果提出来要换一层的石头，那么如果要换最底层的石头的话，毫无疑问，整座金字塔都要拆了然后才能换；如果是要换最高层的石头，直接换了就成，工作量差距之大显而易见。我觉得软件开发就是堆叠金字塔，但是按本文开头所说的”需求时刻在变化“这一观点来看，如果不谨慎处理变化，很有可能就要面对拆了整座金字塔或者大部分金字塔的窘境了。为了避免这种惨剧，需要把最不容易变化的放在最下面，而最容易变化的放在最顶上，这样皆大欢喜。而越是抽象的类或对象，其变化的可能性就越低。这也正是面向对象区别于面向过程的最显著的特征，他们之间的差距也正是以这点最为显著。

　　　　说了很多，没有一句谈到二十三种模式中的任何一种，因为我觉得那是没有必要的。我一直的思想也是种依赖倒转：把绝大多数精力花在最为本质的概念和思想上，而把具体的实现方式和具象的存在放在稍微次要的位置。实际并不是考试，实践中所有东西都是开放的，没必要死记硬背什么，但是那些思想，必须深深地印在脑海里，骨髓里，永远传唱……

帐号		自动登录	找回密码
密码			立即注册