设计模式

https://blog.csdn.net/zhengzhb/article/details/7187278

https://www.jianshu.com/p/8dafef6e2128
https://blog.csdn.net/zhengzhb/article/details/7187278

java对象的各种关系

楼主的经典语录“总结着总结着就是高手了，看着看着就是菜鸟了”。真所谓学而不思则惘。

https://blog.csdn.net/self_study/article/details/51234377

符合设计原则：多用合成/聚合、少用继承，从而减少类之间的耦合

适配器模式还经常用于处理不兼容类型的统一输出问题。例如ListView的输入有很多种类型，但输出都是View，适配器就可以做到这一点。

https://blog.csdn.net/zhengzhb/article/details/7278174
子类可以扩展父类的功能，但不能改变父类原有的功能。

定义：不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责。
问题由来：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。

解决方案：遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，也不会使职责P1发生故障风险。

     说到单一职责原则，很多人都会不屑一顾。因为它太简单了。稍有经验的程序员即使从来没有读过设计模式、从来没有听说过单一职责原则，在设计软件时也会自觉的遵守这一重要原则，因为这是常识。在软件编程中，谁也不希望因为修改了一个功能导致其他的功能发生故障。而避免出现这一问题的方法便是遵循单一职责原则。虽然单一职责原则如此简单，并且被认为是常识，但是即便是经验丰富的程序员写出的程序，也会有违背这一原则的代码存在。为什么会出现这种现象呢？因为有职责扩散。所谓职责扩散，就是因为某种原因，职责P被分化为粒度更细的职责P1和P2。

————————————————
https://blog.csdn.net/zhengzhb/article/details/7281833
里氏替换原则通俗的来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能。它包含以下4层含义：

子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
子类中可以增加自己特有的方法。
当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。
当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。
————————————————
版权声明：本文为CSDN博主「国韭一五七三」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/zhengzhb/article/details/7281833

 依赖倒置原则的核心就是要我们面向接口编程，理解了面向接口编程，也就理解了依赖倒置。

---

面向过程的开发，上层调用下层，上层依赖于下层，当下层剧烈变动时上层也要跟着变动，这就会导致模块的复用性降低而且大大提高了开发的成本。

面向对象的开发很好的解决了这个问题，一般情况下抽象的变化概率很小，让用户程序依赖于抽象，实现的细节也依赖于抽象。即使实现细节不断变动，只要抽象不变，客户程序就不需要变化。这大大降低了客户程序与实现细节的耦合度。
五
11111111111
对于接口大小的把握，有那度。需要经验做支持。个人觉得拿不准的情况下，做小比做大好点。因为后期做加法比做减法容易。