软件开发设计模式与设计原则

原来这些设计模式的理念都是相同的- https://mp.weixin.qq.com/s/neagxQCwXIyTYEABOiq9zQ

> 设计原则
-- 六大设计原则：
1.单一职责原则（Single Responsibility Principle - SRP）
2.开放封闭原则（Open Closed Principle - OCP）
3.里氏替换原则（Liskov Substitution Principle - LSP）
4.最少知识原则（Least Knowledge Principle - LKP）
5.依赖倒置原则（Dependence Inversion Principle - DIP）
6.接口隔离原则（Interface Segregation Principle - ISP）

-- 其他设计原则：
1. 组合/聚合复用原则（Composition/Aggregation Reuse Principle - CARP）
  当要扩展类的功能时，优先考虑使用组合，而不是继承。这条原则在 23 种经典设计模式中频繁使用，如：代理模式、装饰模式、适配器模式等。可见江湖地位非常之高！
2. 无环依赖原则（Acyclic Dependencies Principle - ADP）
  当 A 模块依赖于 B 模块，B 模块依赖于 C 模块，C 依赖于 A 模块，此时将出现循环依赖。在设计中应该避免这个问题，可通过引入“中介者模式”解决该问题。
3. 共同封装原则（Common Closure Principle - CCP）
  应该将易变的类放在同一个包里，将变化隔离出来。该原则是“开放-封闭原则”的延生。
4. 共同重用原则（Common Reuse Principle - CRP）
  如果重用了包中的一个类，那么也就相当于重用了包中的所有类，我们要尽可能减小包的大小。
5. 好莱坞原则（Hollywood Principle - HP）
  好莱坞明星的经纪人一般都很忙，他们不想被打扰，往往会说：Don’t call me, I’ll call you. 翻译为：不要联系我，我会联系你。对应于软件设计而言，最著名的就是“控制反转”（或称为“依赖注入”），我们不需要在代码中主动的创建对象，而是由容器帮我们来创建并管理这些对象。

-- 其他设计原则：
1.不要重复你自己（Don’t repeat yourself - DRY）
  不要让重复的代码到处都是，要让它们足够的重用，所以要尽可能地封装。
2.保持它简单与傻瓜（Keep it simple and stupid - KISS）
  不要让系统变得复杂，界面简洁，功能实用，操作方便，要让它足够的简单，足够的傻瓜。
3.高内聚与低耦合（High Cohesion and Low Coupling - HCLC）
  模块内部需要做到内聚度高，模块之间需要做到耦合度低。
4.惯例优于配置（Convention over Configuration - COC）
  尽量让惯例来减少配置，这样才能提高开发效率，尽量做到“零配置”。很多开发框架都是这样做的。
5.命令查询分离（Command Query Separation - CQS）
  在定义接口时，要做到哪些是命令，哪些是查询，要将它们分离，而不要揉到一起。
6.关注点分离（Separation of Concerns - SOC）
  将一个复杂的问题分离为多个简单的问题，然后逐个解决这些简单的问题，那么这个复杂的问题就解决了。难就难在如何进行分离。
7.契约式设计（Design by Contract - DBC）
  模块或系统之间的交互，都是基于契约（接口或抽象）的，而不要依赖于具体实现。该原则建议我们要面向契约编程。
8.你不需要它（You aren’t gonna need it - YAGNI）
  不要一开始就把系统设计得非常复杂，不要陷入“过度设计”的深渊。应该让系统足够的简单，而却又不失扩展性，这是其中的难点。 

> 设计模式
-- 软件开发设计模式：通用的面向对象设计模式（如工厂模式）；基于Java的设计模式（如J2EE设计模式）
·创建类型：创建类型的模式都是用于创建类的实例。但是和通过new来创建实例不同，这些模式提供了更加灵活的方式，是程序能够根据特定的情况创建特定的类。 
·结构类型：结构类型的模式帮助开发人员将简单对象组合在一起以后的更加复杂的结构。 
·行为类型：行为类型的模式帮助开发人员控制类之间的通讯。 

-- 创建类型的模式:所有创建类型的模式都和如何有效地创建类的实例相关。（5种）
· 工厂模式（Factory Pattern）：根据工厂模式实现的类可以根据提供的数据生成一组类中某一个类的实例，而这一组类有一个公共的抽象父类。 
· 抽象工厂模式（Abstract Factory Pattern）：抽象工厂模式也可以根据提供的数据生成一组类中某一个类的实例，而这一组类有一个公共的抽象父类。只不过它定义的是一个接口。 
· 构造者模式（Builder Pattern）：构造者模式将一个复杂对象的构造过程和它的表现层分离开来，这样类就可以根据不同情况展现出不同的表现方式。 
· 原型模式（Prototype Pattern）：原型模式通过对类的实例进行拷贝来创建新的实例。 
· 单例模式（Singleton Pattern）：根据单一模式实现的类只允许有一个是类，并且提供了一个全局指针来引用该实例。 

-- 结构类型的模式:结构类型的模式将类和对象组合起来，以构成更加复杂的结构。它又被划分为类模式和对象模式。类模式和对象模式之间的区别在于类模式通过继承关系来提供有效的接口；而对象模式通过对象合成或将对象包含在其它对象中的方式构成更加复杂的结构。（7种）
· 适配器模式（Adapter Pattern）：适配器模式可以将一个类的接口和另一个类的接口匹配起来。 
· 桥梁模式（Bridge Pattern）：桥梁模式对客户端程序提供一个固定的接口，但是允许开发人员变化实际的实现类。这样开发人员就可以将接口是具体的实现类分离开来。 
· 组合模式（Composite Pattern）：复合模式可以将多个对象进行复合，其中的每个对象可以是简单对象，也可以是复合对象。 
· 代理模式（Proxy Pattern）：代理模式利用一个简单的对象替代一个复杂的对象，当复杂对象在需要的时候才会被加载到系统中，这样可以节约系统资源，提高系统的响应速度。在网络环境中这种模式很有用处。 
· 装饰者模式（Decorator Pattern）：通过修饰模式，开发人员可以在运行时将特定的功能绑定在对象上。 
· 享元模式（Flyweight Pattern）：轻量模式通过将对象中的一部分数据保存在对象外，在调用对象中的方法时再将这些数据传回对象。这样做可以减少大量比较简单的对象占用的空间。 
· 门面模式（Facade Pattern）：正面模式将复杂的类层次结构组织起来，通过一个简单的接口来获得层次结构中的数据。 

-- 行为类型的模式:行为类型的模式主要是那些处理对象之间通讯的模式，该类型的包括以下模式： （11种）
· 观察者模式（Observer Pattern）：观测者模式可以在发生变化时将变化通知多个类。 
· 调停者模式（Mediator Pattern）：中介模式可以通过一个中间类来控制若干个类之间的通讯，并且这些类相互之间不需要了解对方的信息。 
· 备忘录模式（Memento Pattern）：回忆模式可以在不破坏对象封装性的前提下保存和恢复对象的内部状态。 
· 责任链模式（Chain of Responsibility）：职责链模式将请求传递给一组对象，只有特定的对象才会处理该请求。这样就进一步削弱类之间的联系。 
· 命令模式（Command Pattern）：命令模式将请求传递给特定的对象，这样客户端即使在不知道服务器端如何处理请求的情况下也可以发送请求。 
· 模板方法模式（Template Method Pattern）：模板模式提供了对算法的抽象定义。 
· 策略模式（Strategy Pattern）: 策略模式定义了一组算法，将每个算法都封装起来，并且使它们之间可以互换。策略模式使这些算法在客户端调用它们的时候能够互不影响地变化。 
· 访问者模式（Visitor Pattern）：访问者模式通过一个访问类来访问其他类中的数据。 
· 状态模式（State Pattern）：状态模式将一个类实例的变量保存在独立的内存空间中。 
· 迭代子模式（Iterator Pattern）：迭代模式在不知道数据的内部表现形式的前提下，通过标准的接口来遍历数据集合中的数据。