作者简介 原创微信公众号郭霖 WeChat ID： guolin_blog
本篇来自MichaelX的投稿，分享了 面向对象程序设计 的6个原则，希望能对大家有所帮助。
MichaelX的博客地址：
http://blog.csdn.net/Xiong_IT
前言
相信有过开发经验的人都有过这种体验：让你接手一个的项目，2种情况。A.这个项目已经被好几个人，甚至好几代程序员开发维护过；B.这个项目等待你的全新开发。不给你设时间期限，你更愿意选择哪一个？我相信99.9%的人都会选择B这种开发模式。有木有？？
Why？因为不想改一个bug引起n个bug。说到底，就是因为已有的项目架构没有做好，或者没有适时的做架构调整，假如你接手的是旧代码，可能为了添加一个功能，因为架构不具备扩展性，你也许只能在原有的基础上修改几行代码，甚至修改几百上千行代码来达到目的，以此来埋下诸多隐患待下一个接盘侠搞定。那么就引出了今天的话题？什么样的代码才具备可扩展性呢？
Open Close Principle
OCP原则（开闭原则）：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。
wtf???太抽象了！！！在笔者的理解中，OCP 是6大原则的最高纲领，所以才如此抽象，晦涩难懂。用面向对象的语言来讲，OCP 是一个最抽象的接口，而其余的5大原则只是OCP 的子类接口，他们一起定义了 OOP 世界的开发标准，常用的23中设计模式更是只能算作这6大原则的实现抽象类，咱们开发的代码实践才是真正的具体子类。
publicinterfaceOCP{
voidopenExtention();
voidcloseModifiability();}
Q:What is OCP？
A:OCP是啥咧？它告诉我们，咱们编写的代码应该面向扩展开放，而尽量不要通过修改现有代码来拥抱需求变更。这里，代码可以指的是一个功能模块，类，或者方法。
Q:Why do we need to follow this principle？
A:我们为什么要遵循OCP原则呢？地球人都知道代码后期需求变更的痛苦，如果不利用扩展来适应变更，那迎来的将是代码被修改的千疮百孔。
Q:How do we practice this principle？
A:我们如何实践这条原则？能用抽象类的别用具体类，能用接口的别用抽象类。总之一句：尽量面向接口编程。这里之所以说“尽量”是因为凡事都有度，别让你来个hello world你还给整个接口再实现。
talk is cheap，show your the code.
需求：老王开车去东北。
简单，开撸。老王来了，大家藏好自己媳妇儿。
要车就给你一辆咯
东北到了
老司机要发车了，赶紧打卡上车。滴，学生卡，咳咳咳，拿错卡了。
Perfect，完美！
现在需求变了，老王实现了2017年定下的小目标，挣了1个亿，买了架私人飞机，他不想开车去东北了，太low，他要开飞机去东北。
需求2：老王开飞机去东北
简单，给老王加个属性，加几个方法就实现了嘛？代码就不撸了。OK，又是一次完美变化！？
需求又变了，老张和老王是穿一条裤裆长大的发小，老张看老王这都开上飞机了，他的车是不是可以借来
需求3：老张开车去东北开一开？
这，这，这，简单，重新撸一遍老王在需求1的代码就行了，不就改个名的事吗？
来来来，需求又变了，老张有急事去东北，老王就把飞机也借给老张用了。
需求4：老张开飞机去东北
这，这，这，这，这，这，简单，把老王在需求2的代码重撸一遍就是了。
来来来，需求又变了，老王这回不去东北了，他想开飞机去广东那儿去探望下老丈人，顺便兜兜风。
需求5：老王开飞机去广东
需求6：老张开车去广东
需求7：老王要开飞机去美国
需求8：小王要开车去西藏
需求...
这，这，这，这这这，R&D小哥一口老血喷在屏幕上，卒，享年25岁。
在这里，笔者建议，将人物，交通工具，目的地抽象化，接口化，就可以适应需求的频繁变更了。上类图：
客户端代码作如下调整：
老王的代码如下：
运行结果是：
出发咯
目的地东北到了.
现在，在需求的变更过程中，客户端的代码变化是不是小多了呢？
注意：开闭原则对扩展开放，对修改关闭，并不意味着不做任何修改，低层次模块的变化，必然要有高层模块进行耦合，否则就是一个孤立无意义的代码片段。
在业务规则改变的情况下高层模块必须有部分改变以适应新业务，改变要尽量地少，放置变化风险的扩散
—秦小波《设计模式之禅》
Single Responsibility Principle
SRP原则（职责单一原则）:应该有且只有一个原因引起类的变更。
publicinterfaceSRPextendsOCP{
voidonlyDoOneThing();}
通俗点来讲，一个类，一个方法只应该做一件事情。举2个栗子：
1.当一个类A有R1，R2两个职责时，当 R1 的职责发生变更时，你需要修改 类A，当 R2 发生变更时，你又需要修改 类A，这时，已经有2个原因可能会引起类的变化了，类A 就已经职责不单一了，就需要职责拆分，比如拆分成 类A1，A2：A1类 负责 R1 职责，A2类 负责 R2 职责了。
2.再比如有一个方法M，它负责 计算 和 打印 两个职责
有一天，你想要修改下计算规则，改为
c=a+b+1;
此时，你修改了方法M。又一天，你想修改下打印规则，改为：
System.out.println("打印的是 ="+（c+1）);
你又修改了方法M，此时，超过了2个原因让你去修改它，所以这个方法应该拆分为待返回值得 计算cal 和 打印print 两个方法。每个方法都只做一件事情。
那它是如何体现扩展性的呢？
拿一个Android中最常见的 ImageLoader 的设计来举例子，ImageLoader 主要需要实现 2个功能：下载图片，缓存图片。
假如，我们把所有的功能全部放在一个 ImageLoader类 中，假设下载要改方式呢？缓存要改策略呢？你通通要改 ImageLoader，你如何保证修改某个功能的过程中另一个功能依旧完好，没被污染？拆分职责，使用 ImageCache接口 及 其子类 实现进行缓存，和 ImageLoader 建立关联，职责单一了，你再在每个单一的职责类里面去修改相关代码，这样其他功能代码被污染的概率大大降低。
当然，这里只是随意举的例子，划分单一职责这个度很难把握，每个人都需要根据自身情况和项目情况来进行判断。
Liskov Substitution Principle
OCP原则(里氏替换原则)：所有引用基类的地方必须能透明地使用其子类的对象
publicinterfaceLSPextendsOCP{
voidliskovSubstitutionPrinciple();}
通俗点讲：只要 父类 能出现的地方 子类 就可以出现，而且替换为 子类 也不产生任何异常错误，反之则不然。这主要体现在，我们经常使用抽象类/基类做为方法参数，具体使用哪个子类作为参数传入进去，由调用者决定。
这条原则包含以下几个方面：
子类必须完全实现父类的方法
子类可以有自己的个性外观（属性）和行为（方法）
覆盖或者实现父类方法时，参数可以被放大。即父类的某个方法参数为HashMap时，子类参数可以是HashMap，也可以是Map或者更大
覆盖或者实现父类的方法时，返回结果可以被缩小。即父类的某个方法返回类型是Map，子类可以是Map，也可以是HashMap或者更小
Dependence Inversion Principle
DIP原则（依赖倒置原则）：高层模块不要依赖低层模块，所以依赖都应该是抽象的，抽象不应该依赖于具体细节而，具体细节应该依赖于抽象
低层模块：不可分割的原子逻辑就是 低层模块
高层模块：低层模块的组装合成后就是 高层模块
抽象：Java中体现为基类，抽象类，接口，而不单指抽象类
细节：体现为子类，实现类
通俗点讲，该原则包含以下几点要素：
模块间的依赖应该通过抽象发生，具体实现类之间不应该建立依赖关系
接口或者抽象类不依赖于实现类，否则就失去了抽象的意义
实现类依赖于接口或者抽象类
总结起来，一句话：”面向接口编程“。
Interface-Segregation Principle
ISP原则（接口隔离原则）:客户端不应该依赖它不需要的接口；类间的依赖应该建立在最小的接口上
通俗点讲：使用接口时应该建立单一接口，不要建立臃肿庞大的接口，尽量给调用者提供专门的接口，而非多功能接口。
这里我想举个例子就是 Android 中的事件处理 Listener 设计，大家都知道，我们想给 button 添加点击事件时，可以使用如下代码：
button.setOnClickListener(clickListener);
想给它添加长按事件时，可以使用如下代码：
button.setOnLongClickListener(longClickListener);
还有其他比如 OnTouchListener 等事件接口，它为什么不直接提供一个通用的接口IListener呢？然后回调所有的事件给调用者处理，而要提供这么多独立的接口，这就是遵循了ISP原则的结果，每个接口最小化了，Activity/button 作为调用者，我可以选择性的去处理我想处理的事件，不关心的事件Listener我就不去处理，依赖。
Low of Demeter
LoD法则（迪米特法则）：又称最少知识原则（Least Knowledge Principle， LKP），一个对象应该对其他对象有最少的了解。
通俗点讲：一个类应该对自己需要耦合或者调用的类知道越少越好，被耦合或者调用的类内部和我没有关系，我不需要的东西你就别public了吧。
迪米特法则包含以下几点要素：
只和朋友类交流：只耦合该耦合的类
朋友间也是有距离的：减少不该public的方法，向外提供一个简洁的访问
自家的方法就自己创建：只要该方法不会增加内部的负担，也不会增加类间耦合
感谢和参考
秦小波：《设计模式之禅》
Mr.simple：《Android 源码设计模式解析与实战》
java-my-life
http://www.cnblogs.com/java-my-life
规则只是规则，大家不应该死守规则，应该持辩证的态度去看待这6大原则，才能更好地达到实践应用的目的。
感谢以上作者和博客的规范化引导以及诸多博主的博客才渐渐让我懂得实践设计模式与应用架构。笔者将会未来陆续更新《设计模式系列》in Android博客，后续博客中，均参考了以上书籍和博客。
完。。。。。。。。。。。。。。。。。。。。。
文章原创作者GuoLin 书籍推荐
郭林大神原创android 书籍：《第一行代码 android》
网友评论