Solid约碍则.pptxVIP

Solid 原则 基本概念 程序设计领域， SOLID (单一功能、开闭原则、里氏替换、接口隔离以及依赖反转)是由罗伯特•C•马丁在21世纪早期 引入的记忆术首字母缩略字，指代了面向对象编程和面向对象设计的五个基本原则。当这些原则被一起应用时，它们使得一个程序员开发一个容易进行软件维护和扩展的系统变得更加可能SOLID被典型的应用在测试驱动开发上，并且是敏捷开发以及自适应软件开发的基本原则的重要组成部分。 Solid S 单一功能原则 ：单一功能原则 认为对象应该仅具有一种单一功能的概念。 Solid O 开闭原则 ：开闭原则 认为“软件体应该是对于扩展开放的，但是对于修改封闭的”的概念。 SOLID L 里氏替换原则 ：里氏替换原则 认为“程序中的对象应该是可以在不改变程序正确性的前提下被它的子类所替换的”的概念。 SOLID I 接口隔离原则 ：接口隔离原则 认为“多个特定客户端接口要好于一个宽泛用途的接口”的概念。 SOLID D 依赖反转原则： 依赖反转原则 认为一个方法应该遵从“依赖于抽象而不是一个实例” 的概念。依赖注入是该原则的一种实现方式。 单一功能原则的讨论 当需要修改某个类的时候原因有且只有一个（THERE SHOULD NEVER BE MORE THAN ONE REASON FOR A CLASS TO CHANGE）。换句话说就是让一个类只做一种类型责任，当这个类需要承担其他类型的责任的时候，就需要分解这个类。在所有的SOLID原则中，这是大多数开发人员感到最能完全理解的一条。严格来说，这也可能是违反最频繁的一条原则了。单一责任原则可以看作是低耦合、高内聚在面向对象原则上的引申，将责任定义为引起变化的原因，以提高内聚性来减少引起变化的原因。责任过多，可能引 起它变化的原因就越多，这将导致责任依赖，相互之间就产生影响，从而极大的损伤其内聚性和耦合度。单一责任，通常意味着单一的功能，因此不要为一个模块实 现过多的功能点，以保证实体只有一个引起它变化的原因。 本原则的应用： Unix/Linux是这一原则的完美体现者。各个程序都独立负责一个单一的事。 Windows是这一原则的反面示例。几乎所有的程序都交织耦合在一起。 另外举个例子：报表的内容和报表的格式都会变化改变，但是这两种变化的性质不同，一个是实质内在，一个是表面上的，SRP认为这是问题的两个方面， 其实代表不同的责任，应该将它们分离放入不同的类或模块中，而不应该放在一起，否则的话，因为不同原因发生变化，导致对方变动，比如报表格式变新的样式， 这个变化是不应该涉及到内容的。 开闭原则的讨论 软件实体应该是可扩展，而不可修改的。也就是说，对扩展是开放的，而对修改是封闭的。这个原则是诸多面向对象编程原则中最抽象、最难理解的一个。 对扩展开放，意味着有新的需求或变化时，可以对现有代码进行扩展，以适应新的情况。 对修改封闭，意味着类一旦设计完成，就可以独立完成其工作，而不要对类进行任何修改。 可以使用变化和不变来说明：封装不变部分，开放变化部分，一般使用接口继承实现方式来实现“开放”应对变化，说大白话就是：你不是要变化吗？，那么我就让你继承实现一个对象，用一个接口来抽象你的职责，你变化越多，继承实现的子类就越多。 开闭原则的讨论 OCP的要点在于：作为开发人员，别人偶尔会向我们提供基类，偶尔也会为其他开发人员生成基类框架，供其使用。这些使用者应当仅能使用这些基类，但 不能对其进行修改。这一点是必要的，因为其他使用者也可能依赖于由基类提供的功能。如果允许使用者修改这些基类，可能会导致连锁反应，不仅会影响到应用程 序中的各方面，还会影响到企业内的应用程序。还有一个问题，使用者有时可能会收到基类的升级版本。使用者在升级之前，必须找出一种方法用来处理其对该基类 先前版本中所做的自定义。 于是，问题变为：那么，如果我需要修改这个基类的工作方式，那应当怎么做呢？OCP的另一部分中给出这一答案；基类应当开放，可进行扩充。在这里，扩充是指创建一个由此基类继承而来的派生类，它可以扩充或重载基类功能，以提供使用者所需要的特定功能。这样，使用者就能使用类的修改版本，而不会影响到类的其他使用者。使用者还可以在将来更轻松地使用基类的升级版本，因为他们不用担心丢失自己的修改内容。 本原则的应用： 对于面向对象来说，需要你依赖抽象，而不是实现，23个经典设计模式中的“策略模式”就是这个实现。对于非面向对象编程，一些API需要你传入一个你可以扩展的函数，比如我们的C语言的qsort()允许你提供一个“比较器”，STL中的容器类的内存分配，ACE中的多线程的各种锁。对于软件方面，浏览器的各种插件属于这个原则的实践。 里氏替换原则的讨论 软件工程大师Robert C. Marti