原文地址：http://www.android-doc.com/androiddocs/2017/0911/3389.html
1，面向对象三大特性：
封装：封装是把过程和数据包围起来，对数据的访问只能通过已定义的接口。
继承：
多态：多态就是指程序中定义的引用变量所指向的具体类型和通过该引用变量发出的方法调用在编程时并不确定，而是在程序运行期间才确定，即一个引用变量倒底会指向哪个类的实例对象，该引用变量发出的方法调用到底是哪个类中实现的方法，必须在由程序运行期间才能决定。因为在程序运行时才确定具体的类，这样，不用修改源程序代码，就可以让引用变量绑定到各种不同的类实现上，从而导致该引用调用的具体方法随之改变，即不修改程序代码就可以改变程序运行时所绑定的具体代码，让程序可以选择多个运行状态，这就是多态性。
2，程序设计的6大原则
（一）单一职责原则（地址：https://baike.baidu.com/item/%E5%8D%95%E4%B8%80%E8%81%8C%E8%B4%A3%E5%8E%9F%E5%88%99/9456515?fr=aladdin）:
我把关键内容整理一下
(1)原理：如果一个类承担的职责过多，就等于把这些职责耦合在一起了。一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当发生变化时，设计会遭受到意想不到的破坏。而如果想要避免这种现象的发生，就要尽可能的遵守单一职责原则。此原则的核心就是解耦和增强内聚性。
（2）问题由来：之所以会出现单一职责原则就是因为在软件设计时会出现以下类似场景：
T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。也就是说职责P1和P2被耦合在了一起。
（3）产生原因：没有任何的程序设计人员不清楚应该写出高内聚低耦合的程序，但是很多耦合常常发生在不经意之间，其原因就是：
职责扩散：因为某种原因，某一职责被分化为颗粒度更细的多个职责了
（4）解决办法：遵守单一职责原则，将不同的职责封装到不同的类或模块中。
（二）里氏替换原则：（参考地址：http://blog.csdn.net/zhengzhb/article/details/7281833）
文章中有一句总结写的很好：子类可以扩展父类的功能，但不能改变父类原有的功能。
具体包含了以下4点：
（1）子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
（2）子类可以实现自己特有的方法
（3）当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。
（4）当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。
（三）依赖倒置原则（参考地址：http://blog.csdn.net/zhengzhb/article/details/7289269）：
我觉得自己理解的还不够好，下次再阅读是加入理解。
（四）接口隔离原则（参考地址http://blog.csdn.net/zhengzhb/article/details/7296921）：这个原则主要是说将接口模块化，不要让接口过于庞大，使得在其他类实现该接口时实现了很多自己用不到的方法。
（五）迪米特法则（参考地址：http://www.jianshu.com/p/14589fb6978e）： 简单来说就是一个类A在决定要让其他类B调用时，要保证只给B需要的方法，将其他方法设置为protected，这样类B也就知道这些展示给我的才是我需要用的到的，其他的是自己所不需要展示的。
（六）开闭原则（参考地址：http://blog.csdn.net/zhengzhb/article/details/7296944）：
总结：其实在最初接触java时，我很质疑反射的存在。我一度认为这是脱了裤子放屁的行为。但是，再后来我用反射实现了需求时。我才知道，这是个很强大的功能。其实，我想说的是所谓的原则就像是义务一样。我们可以按照原则来，也可以不按照。我们在最开始使用这些原则时是痛苦的，因为他限制了我们的很多方式。因此，写代码的速度会下降。但是，正是因为有这些规则，在我们项目需要该需求的时候才会方便很多。因为代码之间的联系（耦合）确实很少。我们之前可能要一个一个找的内容，现在只需要修改一块的代码就可以了。
网友评论