学习设计模式心得（第一章）

lovingkiss 2008-06-23 09:58:30

大话设计模式(程杰)
我在井底，并不影响我对天空的向往！
踏入一个陌生的领域，感受一个全新的思想——非科班出身的我之读后感
从没有接触过设计模式，开发中也没有接触过真正意义上的三层开发，甚至真正意义上的面向对象，都没有做的那么好，虽然已经尽量降低耦合度，但是做的并不是特别好；系统的了解一下设计模式，将自己的开发习惯对比一下，找到自己的不足；
既然一样要编码，为什么不尽量将编码耦合度降低？为什么不将代码做到自己力所能及的优化呢？
经过优化的代码比普通的代码一般要精炼、易读易懂、结构清晰；
作为程序员，怎样去评定自己开发理念上的进步呢？这个不光是要有足够多的不断完善的类库、模块、控件，还要在打开一年前的代码，可以很快地指出很多不足（编码以及思想），最重要的是对业务流程的理解要更加的驾轻就熟。
----------------------------------------------------------------------------------------------------
第一章：代码无错就是优？——简单工厂模式
前言：很多初学者，都有这种想法，实现了功能，没有错误就是好的程序，能看懂的就是好的流程；其实，参考大型控件包或者高手类库的源代码，在类、继承、接口、泛型的使用上，虽然可以让有经验者看得清晰明了，却反而让初学者不易看懂，但封装之后的效果是易用易懂，初学者更容易接受，有经验者反而会觉得有限制，需要扩展。没有别的原因——大家所在层面不同阿。
将业务逻辑和代码逻辑、界面逻辑混在一起，实在不能说是好代码啊。尤其是一个团队当中，A开发的程序可能需要B的维护，B开发的类和模块，C可能需要，资源共享、代码开放才是团队精神，而不单纯的是每个人完成自己代码的一部分，保证了接口，就是好的合作。独立的模块化开发，也是要有规范的，并不是完成了自己的工作就Ok的。
中国太多的小公司采用手工作坊式的开发模式，在里面出来的人，大多如此，积重难返，这不能简单的评论对错，开发要根据具体情况和环境而定，混乱的代码可能让程序员在里面保留一席之地而不至于被炒鱿鱼、让购买软件的公司无法摆脱持续“维护”的状态而不断的产生业务——中国特色，此非技术问题。^_^
代码无错——却可能带来无限的后遗症；不要把优化代码的工作放到开发之后——这里不是说刻意的优化，而是要把这种理念融入到编程的灵魂当中，高手——随手挥洒，不局限于任何招式，但不能为了耦合而耦合，达不到无招胜有招的境界，过度耦合反而有害。
（我不是高手，却梦想着高手的风范）
内容：编程不止是技术更是一门艺术
代码需要 1、可维护 2、可复用 3、可扩展 4、灵活性好
面向对象：通过封装、继承、多态把程序的耦合度降低；设计模式使得程序更加的灵活、易于修改，并且易于服用。
编程的一个原则：尽可能的避免重复，初学者程序内Ctrl+C 和 Ctrl+V出现的频率很高。（复制尽量出现在不同系统中，程序内部尽量降低复制的概率和复制的代码量）；当重复的代码多到一定的程序，维护的时候，就是一场大灾难。(即使可以保证代码的无错，到处复制，也不是好现象；)
业务的封装：业务逻辑和界面逻辑分离，降低耦合度，只有分开，才可以达到容易维护和扩展。
紧耦合VS.松耦合：设计的代码成型后尽量不动，利用继承和多态，来完成对类、接口的扩展。
聚合(Aggregation)表示一种弱的“拥有”关系。体现的是A对象可以包含B对象，但B对象不是A对象的一部分；
例如：大雁从属于雁群在雁群的类里面有大雁的集合；例如行列集合和Datatable的关系；
合成(Composition，也有翻译为组合)，是一种强的“拥有”关系，体现了严格的部分和郑体的关系，部分和整体的生命周期一样。
例如：大雁拥有翅膀，实例大雁的同时，实例翅膀类；
依赖例如：大雁依赖水和空气的存在
工厂模式：计算器类的分布
A、计算类：抽象类，抽象返回结果方法；
B、加法类、减法类…继承计算类，利用多态实现返回结果的方法；
C、工厂类：实现对计算模式的实例选择；
例如客户端代码：
Operation oper; //定义为计算类；
Oper=OperationFactory.CreateOperate(“+”) //根据选择，实例化具体的计算类；
Double Result=Oper.GetResult(); //返回结果；
工厂模式：将计算、界面、实例分离，维护以及扩展的时候，根据具体情况对相应的部分进行修改，保证具体修改的时候，其余部分尽量保持原态不动；
本章重点：继承、多态、虚方法、方法重写、抽象类、接口

...全文