设计模式----看大话设计模式笔记（一）

 

OOP编程原则：

 

1.开闭原则（OCP : Open-Close Principle）：对扩展开放，对修改封闭

2.依赖倒置（DIP： Dependency Inversion Principle）: 依赖于抽象，不依赖于具体

3.替换原则（LSP）: 父类能够出现的地方，子类都能够出现。

4.接口隔离原则（ISP）: 接口功能尽可能单一，不要做功能繁多臃肿的接口

5.单一职责原则（SRP）： 就一个类而言，应该仅有一个引起它变化的原因。 如果一个类的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会抑止这个类完成其他职责的能力。

6.合成聚合原则（CARP）： 聚合/组合优于继承

7.迪米特拉原则，最少知道原则（LoD）：就是说一个对象应当对其他对象尽可能少的了解。即只直接与朋友通信，或者通过朋友与陌生人通信。

朋友的定义（或关系）：

（1）当前对象本身。

（2）以参量的形式传入到当前对象方法中的对象。

（3）当前对象的实例变量直接引用的对象。

（4）当前对象的实例变量如果是一个聚集，那么聚集中的元素也都是朋友。

（5）当前对象所创建的对象。

实现：

（1）在类的划分上，应当创建有弱耦合的类。类之间的耦合越弱，就越有利于复用。

（2）在类的结构设计上，每一个类都应当尽量降低成员的访问权限。一个类不应当public自己的属性，而应当提供取值和赋值的方法让外界间接访问自己的属性。

（3）在类的设计上，只要有可能，一个类应当设计成不变类。

（4）在对其它对象的引用上，一个类对其它对象的引用应该降到最低。

（5）尽量限制局部变量的有效范围. 

 

 

过程：

1.程序编码目标： 可维护、可复用、可扩展、灵活性好

2.通过封装、继承、多态把程序的耦合性降低，使用设计模式使得程序更加灵活、容易修改、易于复用。

3.UML表示图例：

 

UML框图中属性或者方法前的 +表示public  - 表示private  #表示protected

聚合是一种弱的拥有关系，A对象可以包含B对象，但是B对象不是A对象的一部分。

合成是一种强的拥有关系，体现了强的部分和整体的关系，部分和整体的生命周期一样。

                    

 

 

设计模式：

 

1.简单工厂模式：

  

UML框图：

  

           

 

2.策略模式（strategy）：

 

面向对象编程并不是类越多越好，类的划分是为了封装，但分类的基础是抽象，具有相同属性和功能的对象的抽象集合才是类。

 

关键： 找变化点

 

策略模式：定义了算法家族，分别封装起来，让它们之间可以相互替换，此模式让算法的变化不会影响到使用算法的客户。

 

最重要的是这些算法是随时都可能相互替换的，这就是变化点。

 

封装变化，是面向对象很重要的思维方式！

 

UML框图：

 

 

策略模式解析：

    策略模式是一种定义一系列算法的方法，从概念上来看，所有这些算法完成的都是相同的工作只是实现不同，它可以以相同的方式调用所有的算法，减少各种算法类与使用算法之间的耦合

    策略模式的strategy类层次为Context定义了一系列的可供重用的算法或行为。继承有助于分析出这些算法中的公共功能。

    策略模式的优点是简化了单元测试，因为每个算法都有自己的类，可以通过自己的接口单独测试。

    不同的行为堆砌在一个类中，就很难避免使用条件语句来选择合适的行为。将这些行为封装在一个个单独的stategy类中，可以在使用这些行为的类中消除条件语句。

    策略模式就是用来封装算法的，但在实践中，我们发现可以用它来封装几乎任何类型的规则，只要在分析过程中听到需要在不同的时间应用不同的业务规则，就可以考虑使用策略模式处理这种变化的可能性。

    在基本的策略模式中，选择所用具体实现的职责由客户端对象承担，并转给策略模式的Context对象。

 

 

3.单一职责原则（SRP）：

    就一个类而言应该就一个引起它变化的原因。

 

    如果一个类承担过多的职责，就等于把这些职责耦合在一起，当一个职责发生变化时，就可能会消弱或者抑制这个类完成其他职责的能力。这种耦合是一种脆弱的设计，当变化发生时，会带来意想不到的破坏。

 

    软件设计要做的就是发现职责，并且把这些职责相互分离。如果你能够想到多于一个的动机去改变一个类，那个这个类就有多于一个的职责，就应该想办法考虑职责的分离。

 

 

4. 开闭原则：

 

    对修改封闭，对扩展开放 ( open for extension, closed for midification )

    

    面对需求，通过增加代码来实现，而不是修改现有的代码，这就是开闭原则的精神所在。

 

 

5. 依赖倒置原则：

    

    依赖于抽象而不依赖细节，使用接口、抽象类编程。

    

    里氏替换原则（LSP）： 子类型能够替换掉它对应的父类型。

 

    依赖倒置原则其实是面向对象编程的标志，程序中所有的依赖关系都终止于抽象类或者接口，那就是面向对象的设计，反之那就是过程化的设计。

 

6. 装饰者模式（Decorator）：

 

UML图：

    

    

Component 是定义一个对象接口，可以给这些对象动态的添加职责。ConcreteComponent是定义了一个具体的对象，也可以给这个对象添加一些职责。Decorator,装饰抽象类，继承了Component,从外类来扩展Component类的功能，但对Component类来说，是无需知道Decorator类的存在的。 至于ConcreteDecorator是具体的装饰对象，起到给Component添加功能的作用。

 

装饰者模式通过SetComponent()，即具体包装对象通过设置内部聚合的待包装对象，然后调用包装方法，来进行包装。 这样每个装饰对象的实现就和如何使用它分离开了，每个装饰对象不需要关系如何添加到对象链当中。

 

装饰者模式是为已有功能动态的添加更多功能的一种方式。 当需要添加功能的时候，如果在主类中添加新的字段、新的方法，肯定可以完成，但是这样增加了主类的复杂度，而且增加的这些东西，仅仅是为满足一些在一些特殊情况下才会执行的特殊行为的需要。而装饰者模式提供了更好的解决方案，它把每个要装饰的功能放在单独的类中，并让这个类包装它要装饰的对象。当需要执行特殊行为的时候，客户代码就可以根据需要有选择、有顺序的包装对象了。

 

 

装饰者模式： 将类的核心功能和装饰功能区分开，可以去除相关类中重复的装饰逻辑。

 

 

7. 代理模式（Proxy）： 为其他对象提供一种代理，已提供对这个对象的访问。

 

UML图：

 

代理模式的适用场合：

    1）远程代理，为一个对象在不同的地址空间提供局部代表，这样可以隐藏为一个对象存在于不同地址空间的事实。

    2）虚拟代理，根据需要创建开销很大的对象，通过它来存放实例化需要很长时间的真实对象。

    3）安全代理，用来控制真实对象的访问权限。

    4）智能指引，当使用代理访问一个对象时，增加一些内务的处理。

 

8. 工厂方法（Factory Method）: 定义一个创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。

 

UML框图：

 

工厂方法模式实现时，客户端需要决定实现哪一个工厂来实现运算类，选择判断的问题，还是存在。工厂方法模式将简单工厂的内部逻辑判断移到了客户端来进行。

工厂方法较简单工厂而言，修正了其在开闭原则上的弊端，但是，每添加一个产品，都需要添加一个工厂类，增加了额外的开销。