认识达内从这里开始

面向对象编程开发我们在前几期的文章中已经给大家介绍过很多次了，而本文我们就通过案例分析来了解一下，面向对象编程原则类型与优势分析。

1、单一职责原则(SingleResponsibilityPrinciple)

定义：就一个类而言，应该仅有一个引起它的变化的原因。通俗的说，一个类只负责一项职责。

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

例如，类A拥有P1、P2两项职责，当需求变更导致需要修改P1，就有可能让原本正常的P2职责发生故障。

优势:

类的复杂性降低，实现什么职责都有清晰明确的定义;

可读性提高，复杂性降低，那当然可读性提高了;

可维护性提高，可读性提高，那当然更容易维护了;

变更引起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大的帮助。

2、开闭原则(Open-ClosePrinciple)

定义：软件实体应当对扩展开放，对修改关闭。通俗说，软件实体(类，模块、函数等等)应该可以扩展，但是不可修改。

原因：在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会给旧代码中引入错误。

总结：当软件需要变化时，我们应该尽量通过扩展的方式来实现变化，而不是通过修改已有的代码来实现。

3、里氏替换原则(LiskovSubstitutionPrinciple)

定义：任何基类可以出现的地方，子类一定可以出现。通俗的说，一个软件实体如果使用的是一个父类，那么一定适用于其子类，而且它察觉不出父类对象和子类对象的区别。也就是说，子类能够替换父类被使用。

原因：需要在子类B拓展一个F2方法，方法F2需要用到父类A已实现的F1方法，假如在类B将F1方法重写，可能会导致F2方法没达到预期的结果。

因此：

子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。

子类中可以增加自己特有的方法。

当子类的方法重载父类的方法时，方法的前置条件(即方法的形参)要比父类方法的输入参数更宽松。

当子类的方法实现父类的抽象方法时，方法的后置条件(即方法的返回值)要比父类更严格。

子类尽量不要去重写父类已实现的方法，子类可以去实现父类里没有实现的方法

4、接口隔离原则(InterfaceSegregationPrinciple)

定义：客户端不应该依赖它不需要的接口;一个类对另一个类的依赖应该建立在小的接口上。

原因，接口I1有3个方法声明F1、F2、F3，但是类A只需要实现F1、F2，为了保证程序正常编译，不得不去实现一个不做任何业务的F3方法。这样就导致接口臃肿，沉余代码过多。

因此，尽量细化接口，我们要为各个类建立专用的接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。

采用接口隔离原则对接口进行约束时，要注意以下几点：

接口尽量小，但是要有限度。但是如果过小，则会造成接口数量过多，使设计复杂化。

为依赖接口的类定制服务，只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务，才能建立小的依赖关系。

提高内聚，减少对外交互。使接口用少的方法去完成多的事情。

5、依赖倒置原则(DependenceInversionPrinciple)

定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象;抽象不应该依赖细节;细节应该依赖抽象。抽象可以解释为抽象类和接口，细节解释为实现类。

原因：假如有类A原本是依赖类B，现在有需求改动，需要改为对类C的依赖，那么我们就得对类A进行调整，因此，我们对类A改动的时候，会对原有程序带来意外的风险。

因此，将类B、C相同的行为抽象为接口I1，而类A依赖成I1，那么类A可以通过接口I1间接与类B、C进行关联。从而减少对类A的修改，以后需求修改只要添加类D、E对接口I1的实现即可，降低类A与其他低层类之间的耦合，形成了面向接口编程，同时也满足了开闭原则。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。