透切理解面向对象三大基本特性是理解面向对象五大基本原则的基础. 推荐博文： [面向对象的三大基本特征，五大基本原则](https://www.cnblogs.com/fzz9/p/8973315.html) ## **封装：** 封装就是隐藏对象的属性和实现细节，仅对外公开接口，控制在程序中属性和方法的读和修改的访问级别。 外界只能通过接口使用该对象，而不能通过任何形式修改对象内部实现，正是由于封装机制，程序在使用某一对象时不需要关心该对象的数据结构细节及实现操作的方法。 封装是面向对象的特征之一，是对象和类概念的主要特性。 **继承：** 继承机制实现了代码的复用，多个类公用的代码部分可以只在一个类中提供，而其他类只需要继承这个类即可。 它可以使用现有类的所有功能，并在无需重新编写原来的类的情况下对这些功能进行扩展。 通过继承创建的新类称为“子类”或“派生类”，被继承的类称为“基类”、“父类”或“超类”。 继承最大的好处是子类获得了父类的全部变量和方法的同时，又可以根据需要进行修改、拓展。 **多态：** 就是指一个类实例的相同方法在不同情形有不同表现形式。多态机制使具有不同内部结构的对象可以共享相同的外部接口。这意味着，虽然针对不同对象的具体操作不同，但通过一个公共的类，它们（那些操作）可以通过相同的方式予以调用。 ## **五大基本原则** **单一职责原则SRP(Single Responsibility Principle)** 是指一个类的功能要单一。比如在职员类里，将工程师、销售人员、销售经理这些情况都放在职员类里考虑，其结果将会非常混乱，在这个假设下，职员类里的每个方法都要if else判断是哪种情况，从类结构上来说将会十分臃肿。 **开放封闭原则OCP(Open－Close Principle)** 一个模块在扩展性方面应该是开放的而在更改性方面应该是封闭的。比如：一个网络模块，原来只服务端功能，而现在要加入客户端功能， 那么应当在不用修改服务端功能代码的前提下，就能够增加客户端功能的实现代码，这要求在设计之初，就应当将服务端和客户端分开，公共部分抽象出来。 这个原则对我们在设计类的时候很有帮助，坚持这个原则就必须尽量考虑接口封装，抽象机制和多态技术！ **里氏替换原则(the Liskov Substitution Principle LSP)** 子类应当可以替换父类并出现在父类能够出现的任何地方，里氏代换原则是对“开-闭”原则的补充。 比如：公司搞年度晚会，所有员工可以参加抽奖，那么不管是老员工还是新员工， 也不管是总部员工还是外派员工，都应当可以参加抽奖，否则这公司就不和谐了。 **依赖倒置原则(the Dependency Inversion Principle DIP)** 具体依赖抽象，上层依赖下层。假设B是较A低的模块，但B需要使用到A的功能， 这个时候，B不应当直接使用A中的具体类： 而应当由B定义一抽象接口，并由A来实现这个抽象接口，B只使用这个抽象接口：这样就达到 了依赖倒置的目的，B也解除了对A的依赖，反过来是A依赖于B定义的抽象接口。通过上层模块难以避免依赖下层模块，假如B也直接依赖A的实现，那么就可能造成循环依赖。一个常见的问题就是编译A模块时需要直接包含到B模块的cpp文件，而编译B时同样要直接包含到A的cpp文件。 **接口分离原则(the Interface Segregation Principle ISP)** 模块间要通过抽象接口隔离开，而不是通过具体的类强耦合起来 不应强迫客户端实现一个它用不上的接口，或是说客户端不应该被迫依赖它们不使用的方法，使用多个专门的接口比使用单个接口要好的多！ 比如，为了减少接口的定义，将许多类似的方法都放在一个接口中，最后会发现，维护和实现接口的时候花了太多精力，而接口所定义的操作相当于对客户端的一种承诺，这种承诺当然是越少越好，越精练越好，过多的承诺带来的就是你的大量精力和时间去维护！ **迪米特法则** 迪米特法则（Law of Demeter）又叫作最少知识原则（Least Knowledge Principle 简写LKP），就是说一个对象应当对其他对象有尽可能少的了解,不和陌生人说话。 英文简写为: LoD.迪米特法则可以简单说成：talk only to your immediate friends。 对于面向OOD来说，又被解释为下面几种方式：一个软件实体应当尽可能少的与其他实体发生相互作用。每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。 　　迪米特法则的初衷在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖，因此，很容易使得系统的功能模块功能独立，相互之间不存在（或很少有）依赖关系。 迪米特法则不希望类直接建立直接的接触。如果真的有需要建立联系，也希望能通过它的友元类来转达。因此，应用迪米特法则有可能造成的一个后果就是：系统中存在大量的中介类，这些类之所以存在完全是为了传递类之间的相互调用关系——这在一定程度上增加了系统的复杂度。 有兴趣可以研究一下设计模式的门面模式（Facade）和中介模式（Mediator），都是迪米特法则应用的例子。