《面向对象设计原则和23个设计模式的笔记》由会员分享，可在线阅读，更多相关《面向对象设计原则和23个设计模式的笔记（13页珍藏版）》请在金锄头文库上搜索。
1、面向对象设计原则和 23 个设计模式的笔记面向对象三大特点：封装:封装，也就是把客观事物封装成抽象的类，并且类可以把自己的数据和方法只让可信的类或者对 象操作，对不可信的进行信息隐藏。不关注处理过程了，只有对象和其职能。只允许设定的对象访问自身信息，其余私人信息隐藏。作用:封装可以隐藏实现细节，使得代码模块化，局域化，简单；继承：继承的父类最好是接口，最好连属性都没有。少用实现继承（库内使用较多），多用组合。 忘了多重继承，除非实现多接口。作用：扩展已有代码模块；代码重用（库内使用较多），多态的基础多态：静态-编程时采用父类型-针对接口编程动态-执行时才实际映射成具体的子类作用：静态时针对接口
2、编程，执行时才体现实际的效果面向对象设计原则：单一职责原则（SRP）：就一个类而言，应该仅有一个引起它变化的原因；当职责越多，耦合越多，易遭破坏 软件设计真正要做的就是发现职责并将这些职责相互分离 把职责分离到单独的类中,因为每一个类都是变化的轴线，当需求变化时,该变化会反映为类的职责 的变化，如果一个类承担了多余一个的职责,那么引起他变化的原因就会有多个。职责定义为“变 化的原因”。如果一个类承担的职责过多,就等于把这些职责耦合在了一起,一个职责的变化可能会削弱或者抑制 这个类完成其他职责的能力，这种耦合会导致脆弱的设计，当变化发生时，设计会受到意想不到 的破坏。另一方面，如果应用程序的变化
3、方式总是导致这两个职责同时变化，那么就不必分离它们，实际 分离它们就会导致不必要的复杂性的臭味。SRP 是所有原则中最简单的也是最难以正确应用的原则之一。开放封闭原则：软件实体应该可以扩展，但是不可修改。软件要容易维护又不容易出问题的最好方法是多扩展，少修改。无论模块多么封闭，都会有无法封闭的变化，事先构造抽象隔离这些变化。 面对新需求，对程序的改动是通过增加新代码进行的，而不是更改现有的代码OCP 的关键是抽象，对于代码的改动是通过增加新代码进行的，而不是更改现有代码，因此他就 不会引起像不遵循OCP原则那样的连锁改动。通常，我们更愿意一直等到确实需要那些抽象时再把他放进去，“我们愿意被第一
4、颗子弹射中， 但是我们不会再被同一支枪射得其他子弹射中”。可以按照以下的一些方法完成这项工作:我们首先编写测试.测试描绘了系统的一种使用方法,通过首先编写测试,我们迫使系统成为可测试 的,在一个具有可测试的.在一个具有可测试性的系统中发生变化时,我们可以坦然对之,因为我们已 经构建了使用系统可测试的抽象,并且通常这些抽象中的许多都会隔离以后发生的其他种类的变化.在许多方面,OCP都是面向对象设计的核心所在，遵循这个原则可以带来面向对象技术所声称的巨大 好处（灵活,可重用,可维护性）,然而,并不是说只要使用一种面向对象的语言就是遵循了这个原则,对 于程序中的每个部分都肆意进行抽象同样不是一个好主
5、意,正确的做法是,开发人员应该仅仅对程序 中呈现出频繁变化的那部分作出抽象.拒绝不成熟的抽象和抽象本身一样重要.依赖倒转原则高层模块不应该依赖低层模块，两个都应该依赖于抽象抽象不应该依赖于细节，细节应该依赖于抽象即要针对接口编程，不要对实现编程本应该是高层的策略设置模块去影响低层细节实现的模块的，包含高层业务规则的模块应该优先 并独立于包含实现细节的模块，无论如何高层模块都不应该依赖于低层模块。我们更希望能够重用的是高层策略模块，如果高层模块独立于底层模块，那么高层模块就能更容 易的被重用，该原则是框架的设计核心原则。所有结构良好的面向对象的架构都具有清晰的层次定义，每个层次通过一个定义良好的
6、、受控制 的接口向外提供一组内聚的服务。每个较高的层次都为它所需要服务声明一个抽象接口，较低层次实现了这些抽象接口，每个高层 类都通过接口使用下一层，这样高层就不依赖于低层。低层反而依赖于在高层中声明的抽象服务 接口。这种倒置不仅仅是依赖关系的倒置。它也是接口所有权的倒置。依赖倒置可以应用于任何一个类向另一个类发送消息的地方。违反DIP,高层策略没有和底层实现分离，抽象没有和具体细节分离，没有这种分离，高层策略 就自动的依赖于低层模块，抽象就自动的依赖于具体细节。里氏代换原则（LSP）子类型必须替换掉它们的父类型。适用于父类的一定适用于子类LSP 让我们得到一个非常重要的结论:一个模型，如果孤
7、立的看，并不具有真正意义上的有效性， 模型的有效性必须通过他的客户程序来表现。如果一组类都支持一个公共的职责，那么它们就应该从一个公共的超类继承该职责。如果公共的 超类还不存在，那么就创建一个，并把公共的职责放入其中，毕竟这样一个类的有用性是确定无 疑的。有一些简单的启发规则可以提供一些有关违反LSP的提示，这些规则都和以某种方式从其基类中 去除某功能的派生类有关，完成的功能少于其基类的派生类通常是不能替换其基类的，因此就违 反了 LSP。另外一种违反LSP的规则形式是在派生类的方法中添加了其基类不会抛出的异常，如果基类的使 用者不期望这些异常，那么把它们添加到派生类的方法中就会导致不可替代性
8、，此时要遵循 LSP 要么就必须改变使用者的期望，要么派生类就不应该抛出这些异常。OCP 是 OOD 中很多说法的核心。如果这个原则应用的有效，应用程序就会具有更多的可维护性， 可重用性以及健壮性，LSP是使用OCP成为可能的主要原则之一。迪米特法则（LoD）如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。法则强调类之间的松耦合。接口隔离原则ISP 这个原则用来处理“胖”接口所具有的缺点。如果类的接口不是内聚的，就表示该类具有胖的接口。换句话说，类的胖接口可以分解成多组方法，每一组方法服务于一组不同
9、的客户端程序。不应该强迫客户依赖于它们不用的方法。如果一个客户端程序依赖于一个含有它不使用的方法的类，但其他客户端缺要使用该方法，那当 其他客户端对这个类改变时，就会影响到这个类。创建模式抽象工厂模式（Abstract Factory）提供一个创建一系列相关或相互依赖对象的接口，而无需指定他们具体的类。 # 一个抽象工厂多个方法，每个方法创建一个（抽象）对象；不同工厂实例可得到不同风格对象集；优缺点创建操作和实际的产品对象集都独立出来更换产品对象集很方便接口已定义好能创建的集中对象个数，难扩展 -通过参数传入创建不同类（返回对象类型很难定 需要向下类型转换不安全）关联具体的工厂通常是单件通常用
10、工厂方法或原型来实现抽象工厂中的各方法建造者模式（Builder）将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。 #定义一个有创建各子部件方法（不返回）和返回组合好的父部件的接口，从而封装内部子对象创 建的细节 实现子类，以不同的创建方式实现这些方法，每个子类就是一种创建子部分方法外部通过创建导向器Director配置创建子部件的方式（顺序和约束），并得到组合好的父部件。最终产品不需要是抽象类，直接具体的复合类即可关联Builder 着重于一步步创建复杂对象，最后返回Abstract Factory 创建一系列多个对象，创建一个返回一个Composite通常是用Bu
11、ilder生成的工厂方法模式（Factory Method）定义一个用于创建对象的接口，让子类决定实例化哪一个类。 # 一个接口一个方法创建一个抽象对象，子类确定实现那个具体类。 通过传入参数生成不同对象避免为已确定的类型生成不同子类（写在父类中） 关联通常在Template Method中被调用原型模式（Prototype）用原型实例指定创建对象的种类，并通过拷贝这些原型创建新的对象。 #用来Clone 一个自身的对象，包含一个Clone的操作。 从一个对象再创建另外一个可定制的对象，而不需要知道任何创建的细节。 注意Clone过程中的浅拷贝和深拷贝的问题优缺点运行时刻增加删除新原型 定制新
12、的原型并加入到系统中很方便原型需要有Clone操作，已有类无Clone操作时，不能被原型化。关联Composite 和 Decorator 模式也常用到 Prototype 模式单件模式(SingleTon)保证一个类仅有一个实例，并提供一个访问它的全局访问点#只有一个实例，全局可访问类构造函数为保护类型，不允许直接构建，但允许子类化简单工厂模式(StaticFactory Method)由一个工厂对象决定创建出哪一种产品类的实例。#一个创建类一个创建方法传入不同参数创建不同对象关联Factory Method 模式将实例化那个具体类放到了工厂的子类来实现。简单工厂新加一个类需要修改代码，而工
13、厂方法只需要扩展一个子类结构模式适配器模式(Adapter)将一个类的接口转换成客户希望的另外一个接口。 # 类适配-多重继承实现适配 对象适配-组合实现适配关联Bridge 实现抽象与实现的分离可独立改变桥接模式(Bridge) 将抽象部分与它的实现部分分离，使它们都可以独立的变化 # 抽象和实现部分都可以独立的扩展 解决了继承机制的父子绑带关系优缺点 分离接口及其实现部分 抽象也可扩充，提高可扩充性关联Abstract Factory 可用于创建和配置一个特定的 Bridge 模式Adapter在已有系统但要升级时使用，Bridge在系统设计的时候就使用组合模式(Composite) 将对
14、象组合成树形结构以表示“部分-整体”的层次结构。# 使组合体和单体具有同一抽象类型，从而可以统一处理 每个子部件保留父部件的显示引用有利于遍历和消息传递 共享子部件涉及Flyweight模式以及多个父部件的定位特别关注父子部件的引用排序遍历传递定位等关联父子部件连接采用 Responsibility of ChainFlyWeight 模式共享子部件，但不再能引用父部件装饰模式(Decorator)动态的给一个对象添加一些额外的职责，就增加功能来说，装饰模式比生成子类更为灵活 # 在不影响已有的对象的情况下动态透明的添加额外职责，需要共用一个接口 原有类集不能通过子类进行扩充时用装饰者优缺点被装饰的组件类的接口尽可能的简单避免多个功能组合时可能产生的很多子类，通过每个子功能一个类，动态去组合。关联Decorator可以改变对象的外表，Strategy可以改变对象的内核外观模式(Facade) 为子系统中的一组接口提供一个一致的界面。# 为复杂的子系统提供一个简单接口 优缺点 有利于分层系统；有利于重用旧有的代码；减少接口，降低耦合 关联
