面向对象设计原则和23个设计模式的笔记.docxVIP

PAGE 1 面向对象设计原则和23个 设计模式的笔记 面向对象三大特点： 封装： 封装，也就是把客观事物封装成抽象的类，并且类可以把自己的数据和方法只让可信的类或者对象操作，对不可信的进行信息隐藏。 不关注处理过程了，只有对象和其职能。 只允许设定的对象访问自身信息，其余私人信息隐藏。 作用：封装可以隐藏实现细节，使得代码模块化，局域化，简单； 继承： 继承的父类最好是接口，最好连属性都没有。 少用实现继承（库内使用较多），多用组合。 忘了多重继承，除非实现多接口。 作用：扩展已有代码模块；代码重用（库内使用较多），多态的基础 多态： 静态--编程时采用父类型-针对接口编程 动态--执行时才实际映射成具体的子类 作用：静态时针对接口编程，执行时才体现实际的效果 面向对象设计原则： 单一职责原则（SRP）： 就一个类而言，应该仅有一个引起它变化的原因；当职责越多，耦合越多，易遭破坏 软件设计真正要做的就是发现职责并将这些职责相互分离 把职责分离到单独的类中,因为每一个类都是变化的轴线，当需求变化时,该变化会反映为类的职责的变化，如果一个类承担了多余一个的职责,那么引起他变化的原因就会有多个。职责定义为“变化的原因”。 如果一个类承担的职责过多,就等于把这些职责耦合在了一起,一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力，这种耦合会导致脆弱的设计，当变化发生时，设计会受到意想不到的破坏。 另一方面，如果应用程序的变化方式总是导致这两个职责同时变化，那么就不必分离它们，实际分离它们就会导致不必要的复杂性的臭味。 SRP是所有原则中最简单的也是最难以正确应用的原则之一。 开放封闭原则： 软件实体应该可以扩展，但是不可修改。 软件要容易维护又不容易出问题的最好方法是多扩展，少修改。 无论模块多么封闭，都会有无法封闭的变化，事先构造抽象隔离这些变化。 面对新需求，对程序的改动是通过增加新代码进行的，而不是更改现有的代码。 OCP的关键是抽象，对于代码的改动是通过增加新代码进行的，而不是更改现有代码，因此他就不会引起像不遵循OCP原则那样的连锁改动。 通常，我们更愿意一直等到确实需要那些抽象时再把他放进去，“我们愿意被第一颗子弹射中，但是我们不会再被同一支枪射得其他子弹射中”。 可以按照以下的一些方法完成这项工作: 我们首先编写测试.测试描绘了系统的一种使用方法,通过首先编写测试,我们迫使系统成为可测试的,在一个具有可测试的.在一个具有可测试性的系统中发生变化时,我们可以坦然对之,因为我们已经构建了使用系统可测试的抽象,并且通常这些抽象中的许多都会隔离以后发生的其他种类的变化. 在许多方面,OCP都是面向对象设计的核心所在,遵循这个原则可以带来面向对象技术所声称的巨大好处(灵活,可重用,可维护性),然而,并不是说只要使用一种面向对象的语言就是遵循了这个原则,对于程序中的每个部分都肆意进行抽象同样不是一个好主意,正确的做法是,开发人员应该仅仅对程序中呈现出频繁变化的那部分作出抽象.拒绝不成熟的抽象和抽象本身一样重要. 依赖倒转原则 高层模块不应该依赖低层模块，两个都应该依赖于抽象 抽象不应该依赖于细节，细节应该依赖于抽象 即要针对接口编程，不要对实现编程 本应该是高层的策略设置模块去影响低层细节实现的模块的，包含高层业务规则的模块应该优先并独立于包含实现细节的模块，无论如何高层模块都不应该依赖于低层模块。 我们更希望能够重用的是高层策略模块，如果高层模块独立于底层模块，那么高层模块就能更容易的被重用，该原则是框架的设计核心原则。 所有结构良好的面向对象的架构都具有清晰的层次定义，每个层次通过一个定义良好的、受控制的接口向外提供一组内聚的服务。 每个较高的层次都为它所需要服务声明一个抽象接口，较低层次实现了这些抽象接口，每个高层类都通过接口使用下一层，这样高层就不依赖于低层。低层反而依赖于在高层中声明的抽象服务接口。 这种倒置不仅仅是依赖关系的倒置。它也是接口所有权的倒置。 依赖倒置可以应用于任何一个类向另一个类发送消息的地方。 违反DIP，高层策略没有和底层实现分离，抽象没有和具体细节分离，没有这种分离，高层策略就自动的依赖于低层模块，抽象就自动的依赖于具体细节。 里氏代换原则（LSP） 子类型必须替换掉它们的父类型。 适用于父类的一定适用于子类 LSP让我们得到一个非常重要的结论:一个模型，如果孤立的看，并不具有真正意义上的有效性，模型的有效性必须通过他的客户程序来表现。 如果一组类都支持一个公共的职责，那么它们就应该从一个公共的超类继承该职责。如果公共的超类还不存在，那么就创建一个，并把公共的职责放入其中，毕竟这样一个类的有用性是确定无疑的。 有一些简单的启发规则可以提供一些有关违反LSP的提示，这些规则都和以某种方式