设计模式——简介

软件领域中的设计模式为开发人员提供了一种使用专家设计经验的有效途径。

设计模式运用了面向对象编程语言的重要特性：封装、继承、多态。

设计模式分三大类：创建型模式（Creational Pattern）、结构型模式（Structural Pattern）、行为型模式（Behavioral Pattern）

创建型模式对类的实例化过程进行了抽象，能够将软件模块中对象的创建和对象的使用分离。

结构型模式关注于对象的组成以及对象之间的依赖关系，描述如何将类或者对象结合在一起形成更大的结构，像搭积木可以通过简单积木的组合形成复杂的、功能更为强大的结构

行为型模式关注于对象的行为问题，是对在不同的对象之间划分责任和算法的抽象化。不仅仅关注类和对象的结构，而且重点关注它们之间相互作用。

总结：创建型模式提供创建对象的机制，增加已有代码的灵活性和可复用性。结构型模式介绍如何将对象和类组装成较大的结构，并同时保持结构的灵活和高效。行为模式负责对象间的高效沟通和职责委派。

设计模式六大基本原则：单一职责原则、开闭原则、里氏替换原则、依赖倒置原则、接口隔离原则、迪米特原则（最少知识原则）

开闭原则：一个软件实体如类、模块和函数应该对修改封闭，对扩展开放。(修改封闭理解：开发过程中通常会将某些简单重复的逻辑封装成函数接口。便于其他人使用，保证后续逻辑修改能同步到所有地方。扩展开放理解：复杂模块的数据结构采用单独的数据类管理，便于对数据字段进行增删)

单一职责原则：一个类只做一件事，一个类应该只有一个引起它修改的原因。(将变化因素拆分多个类实现，确保后续最小修改量。将各功能实现前置逻辑要求隔离，确保代码逻辑长期有效。实际开发中考虑到时间成本并不会过多过细的拆分，一般待实际细节需求时拆分。对于某些复杂模块的拆分和后续扩展，都由实际开发经验来在未有细致需求之前就预留处理)

里氏替换原则：子类应该可以完全替换父类。在使用继承时，只扩展新功能，而不要破坏父类原有的功能。(理解：继承的概念就包含了子类可以完全替换父类使用，这里强调子类只扩展新功能。对于某些子类只想替换父类某个函数调用的处理过程，也采用继承实现，但这里可以算扩展新功能吗？替换某函数处理过程，可能完全不同于父类的处理逻辑，即不会完全能替换父类使用，仅数据存储结构一致，待思考？)

依赖倒置原则：细节应该依赖于抽象，抽象不应依赖于细节。把抽象层放在程序设计的高层，并保持稳定，程序的细节变化由低层的实现层来完成。(理解：主要说明整个程序设计思路时从上到下，从抽象到具体。但我一直处于业务开发过程中，对此理解为需要相对稳定的底层框架基础，即需要先制作很多基本模块的基本接口。后续才好处理其它依赖于已有模块的复杂模块。基本没有规划抽象接口的经验)

迪米特法则(最少知道原则)：一个类不应该知道自己操作类的细节，换言之，只和朋友谈话，不和朋友的朋友谈话。(理解：降低程序复杂度的方法，使单个类不必过于细节膨胀，简化类与类之间的暴露接口)

接口隔离原则：客户端不应依赖它不需要的接口。如果一个接口在实现时，部分方法由于冗余被客户端空实现，则应该将接口拆分，让实现类只需依赖自己需要的接口方法。(理解：使接口最小化，便于稳定。关于拆分，拆分后接口定义名如何处理，原有接口不便于替换，即使原有接口名可能与实际逻辑关系不大或变动后。这里需要完整的接口替换处理，同步各开发，寻找使用地方，后续调试使用，兼容稳定等需求)

曾经看到一个开发主管，出过一个APP的开发接口方案。说明了应具备的底层接口、接口名、参数名，实现逻辑描述等。类似顶层设计方案，规划了整个方案中的核心接口，分隔了业务逻辑开发。很好的实现了各程序员的隔离开发和通力合作，及对各自负责模块的优化处理等。

学习网站：常用设计模式有哪些？

后续深入各模式时再总结。。。