单一职责原则

就一个类而言，应该仅有一个引起它变化的原因

一个类不应该搞得很复杂，当傅老师黑魂教程中处理玩家数据时新建一个ActorData来装载玩家数据，ActorController来改变数据。一个类承担某种职责。

里氏替换原则

子类型必须能够代替掉它们的父类型

可以理解为多态，只有子类可以替换掉父类，软件单位的功能不受到影响时，父类才能真正的被复用，而子类也能够在父类的基础上增加新行为。如果鸟类里面加入了飞的功能，那么企鹅类是不会飞的，所以不能继承。由于子类型的可替换性才使得使用父类类型的模块无需修改的情况下可以扩展

开放封闭原则

软件实体（类、模块、函数等）应该可以扩展，但是不可修改

原来的代码能跑就不要去动它，要修改可以将其组合或者继承变成新的类进行扩展，书上有一点说的很好，在最开始的时候假设程序不会发生变化，当变化发生时再去创建抽象隔离，以此简化发生的同类变化，emm，虽然重构麻烦，如果项目不是很大可以考虑，毕竟为了后面长期变化做准备，刚看完的时候就是想太多，设计来设计去根本没动手，不如先动手做一个原型以后再改

依赖倒置原则

1. 高层模块不应该依赖低层模块，应该都依赖于抽象

2. 抽象不应该依赖于细节，细节应该依赖于抽象

高层模块通过调用低层模块中的函数进行数据处理。

高层模块关联抽象，高层模块可以调用抽象类中的函数，而不同低层模块可以复用函数，只需要实例化不同的低层模块便能达到灵活切换不同的低层模块函数。

也叫依赖倒转原则，依赖倒转是面向对象设计的标志，整个程序所有的依赖关系都应该是终止于抽象类或接口。

迪米特法则

如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用，如果一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。

也叫最少知识原则，就像mvc架构升级到mvp架构一样，取消了m到v的直接联系。在类的结构设计上，每一个类都应当尽量降低成员的访问权限。

迪米特法则其根本思想，是强调了类之间的松耦合。我们在程序设计时，类之间的耦合越弱，越有利于复用，一个处在弱耦合的类被修改，不会对有关系的类造成波及。也就是说,信息的隐藏促进了软件的复用。”

合成/聚合复用原则

尽量使用合成/聚合，尽量不要使用类继承

合成(Composition，也有翻译成组合）和聚合(Aggregation)都是关联的特殊种类。聚合表示一种弱的‘拥有’关系，体现的是A对象可以包含B对象，但B对象不是A对象的一部分;合成则是一种强的‘拥有’关系，体现了严格的部分和整体的关系，部分和整体的生命周期一样。优先使用对象的合成/聚合将有助你保持每个类被封装，并集中在单个任务上。这样类和类继承层次会保持较小规模，并且不太可能增长为不可控制的庞然大物。

大雁有两个翅膀，翅膀与大雁是部分和整体的关系，并且它们的生命周期是相同的，于是大雁和翅膀就是合成关系。而大雁是群居动物，所以每只大雁都是属于一个雁群，一个雁群可以有多只大雁，所以大雁和雁群是聚合关系。”

接口隔离原则

大话设计模式没讲此原则，个人猜测作者应该是认为和单一职责原则差不多吧

客户端不应该依赖它不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口上。

将一个复杂且大的接口拆分成小的几个接口，是每一个接口的功能更单一。更灵活。

拓展

MVC

-Model(数据层):负责管理业务逻辑和处理网络或数据库API。
-View(视图层):让数据层的数据可视化。在Android中对应用户交互、UI绘制等。
-Controller (逻辑层)∶获得用户行为的通知，并根据需要更新Model。

优点

Model类没有对Android类的任何引用，因此可以直接进行单元测试。Controller不会扩展或实现任何Android类，并且应该引用View的接口类。通过这种方式，也可以对控制器进行单元测试。如果View遵循单一责任原则，那么它们的角色就是为每个用户事件更新Controller，只显示Model中的数据，而不实现任何业务逻辑。在这种理想的作用下，UI测试应该足以覆盖所有的View的功能。
总结以上介绍我们发现，MVC模式高度支持职责的分离。这种优势不仅增加了代码的可测试性，而且使其更容易扩展，从而可以相当容易地实现新功能。

缺点

代码相对冗余。我们知道，MVC模式中View对Model是有着强依赖的。当View非常复杂的时候，为了最小化View中的逻辑，Model应该能够为要显示的每个视图提供可测试的方法——这将增加大量的类和方法。
灵活性较低。由于View依赖于Controller和TModel，Ul逻辑中的一个更改可能导致需要修改很多类，这降低了灵活性，并且导致UI难以测试。
可维护性低。Android的视图组件中，有着非常明显的生命周期，如Activity、Fragment等。对于MVC模式，我们有时不得不将处理视图逻辑的代码都写在这些组件中，造成它们十分臃肿。
所以,Android中最初的MVC架构问题显而易见:过于臃肿的
Controller层大大降低了工程的可维护性及可测试性。

MVP

Model(数据层)。负责管理业务逻辑和处理网络或数据库API。

View(视图层)。显示数据并将用户操作的信息通知给Presenter。

Presenter(逻辑层)。从Model中检索数据，应用UI逻辑并管理View的状态，决定显示什么，以及对View的事件做出响应。

优点

相对于MVC，MVP模式设计思路的核心是提出了Presenter层，它是View层与Model层沟通的桥梁，对业务逻辑进行处理。这更符合了我们理想中的单一职责原则。

缺点

1. 接口粒度难以掌控。MVP模式将模块职责进行了良好的分离。但在开发小规模App或原型时，这似乎增加了开销——对于每个业务场景，我们都要写Activity-View-Presenter-Contract这4个类。为了缓解这种情况，一些开发者删除了Contract接口类和Presenter的接口。另外，Presenter 与View的交互是通过接口实现的,如果接口粒度过大，解耦程度就不高，反之会造成接口数量暴增的情况。
   从工程的严谨角度来说，这或许并不是缺点，只是创造一个良好工程架构带来的额外工作量。

2. Presenter逻辑容易过重。当我们将UI的逻辑移动到Presenter中时，Presenter变成了有数千行代码的类，或许会难以维护。要解决这个问题，我们只可能更多地拆分代码，创建便于单元测试的单一职责的类。

3. Presenter和View相互引用。我们在Presenter和View中都会保持一份对方的引用，所以需要用subscribe和unsubscribe来绑定和解除绑定。在操作UI的时候，我们需要判断UI生命周期，否则容易造成内存泄漏。

MVVM

Model(数据模型):与ViewModel配合，可以获取和保存数据。

View(视图):即将用户的动作通知给ViewModel(视图模型)。

ViewModel(视图模型):暴露公共属性与View相关的数据流，通常为Model和View的绑定关系。

优点

如果MVP模式意味着Presenter直接告诉View要显示的内容，那么在MVVM中, ViewModel会公开Views可以绑定的事件流。这样ViewModel不再需要保持对View的引用，但发挥了Presenter一样的作用。这也意味着MVP模式所需的所有接口现在都被删除了。这对介意接口数量过多的开发者来说是个福音。
View还会通知ViewModel进行不同的操作。因此，MVM模式支持View和ViewModel之间的双向数据绑定，并且View和ViewModel之间存在多对一关系。View具有对ViewModel的引用，但ViewModel没有关于View的信息。因为数据的使用者应该知道生产者，但生产者ViewModel不需要知道，也不关心谁使用数据。

缺点

1）需要更多精力定位Bug。由于双向绑定，视图中的异常排查起来会比较麻烦，你需要检查View中的代码，还需要检查Model中的代码。另外你可能多处复用了Model，一个地方导致的异常可能会扩散到其他地方，定位错误源可能并不会太简单。
2）通用的View需要更好的设计。当一个View要变成通用组件时，该View对应的Model通常不能复用。在整体架构设计不够完善时，我们很容易创建一些冗余的Model。