设计模式
参考 模式分析，模式难点，模式解决问题，优点，缺点，模式应用场景，模式代码（基于dart)
六大原则
开闭原则（Open-Closed-Principle）
核心：一个软件实体应当对拓展开放，对修改关闭。即：软件实体应尽量在不修改原有代码的情况下进行拓展。
里氏代换原则（Liskow-Substitution-Principle）
核心：所有引用基类（父类）的地方，都必须能透明地使用其子类的对象。
一个软件实体如果使用的是一个父类，那么一定适用于其子类，而且他察觉不出父类对象和子类对象的区别。也就是说，在软件里面，把父类都替换成它的子类，程序的行为没有变化。简单地说，子类必须能够替换掉它们的父类型。
依赖倒转原则（Dependency-Inversion-Principle）
核心: 抽象不应该依赖于细节，细节应当依赖于抽象。换言之，要针对接口编程，而非针对实现编程。
思想: 抽象不应该依赖于细节，细节应当依赖于抽象。换言之，要针对接口编程，而不是针对实现编程。依赖倒转其实可以说是面向对象设计的标志，用哪种语言来编写程序不重要，如果编写时考虑的都是如何针对抽象编程而不是针对细节编程，即 程序中所有的依赖关系都是终止于抽象类或者接口，那就是面向对象的设计，反之就是面向过程化设计了。
原则：
- 高层模块不应该依赖于低层模块。两个都应该依赖于抽象。
- 抽象不应该依赖细节。细节应该依赖于抽象。
单一职责原则（Single-Responsibility-Principle）
核心：一个类只负责一个功能领域中相应的职责，或者可以定义为：就一个类而言，应该只有一个引起它变化的原因。
思想：如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。【Eg:游戏的界面组成与逻辑组成分离】
接口隔离原则（Interface-Segregation-Principle）
核心：使用多个专门的接口，而不使用单一的总接口。即 客户端不应该依赖于那些它不需要的接口。
迪米特法则（Law-Of-Demeter）
核心：一个软件实体应当尽可能少地与其他实体发生作用。（无熟人难办事）
思想：也叫最少知识原则。如果两个类不彼此通信，那么这两个类就不应当直接地发生相互作用。如果其中一个类需要另一个类的某一个方法的话，可以通过第三者转发这个调用。（不要和陌生人说话）
原则：在迪米特法则中，对于一个对象，其朋友包括如下几类：
- 当前对象 this
- 以参数形式传入到当前对象方法中的对象
- 当前对象的成员对象
- 若当前对象的成员你对象是一个集合，那么集合中的对象也都是朋友
- 当前对象所创建的对象
