设计模式与常见架构设计策略学习

设计模式常被分为：

1)创建型：创建对象时，不再由我们直接实例化对象，而是根据特定场景，由程序来创建对象的方式，从而保证更大的性能，更好的架构优势。主要包括：

①　简单工厂模式（不是23中设计模式之一）：将多个类对象交个工厂类来生成的设计模式称为简单工厂模式。

使用简单工程模式的优势是：让对象的调用者与对象的创建过程分离，当对象调用者需要对象时，直接向工厂请求即可，从而避免了对象的调用者与对象的实现类一硬编码方式耦合，提高了系统的可维护性，可扩展性。

②　工厂方法：为不同的实力类提供不同的工厂方法。

③　抽象工厂模式：工厂类不制造具体的被调用对象，而是制造不同工厂对象。

④　单例模式：如果一个类始终只能创建一个实例，则这个类称为单例类，这种模式称为单例模式。

对于Spring框架而言，在配置bean实例时指定scope=“singleton”来配置单例模式，且当配置

Class Singleton{
Private static Singleton instance;
Private Singleton (){};
Public static Singleton getInstance(){
if(instance==null){
Instance=new Singleton();
}
retrurn instance;
}

}

使用单例模式的优势：

减少创建java实例所带来的系统开销。

便于系统跟踪单个Java实例的生命周期、实例状态等。

⑤　生成器模式

⑥　原型模式

2)结构型：用于帮助将多个对象组织成更大的结构。主要包括：

①　适配器模式

②　桥接模式：桥接模式是一种结构式模式。将公共部分提取出来。

③　组合器模式

④　装饰器模式

⑤　门面模式：门面模式也被称为正面模式、外观模式，这种模式用于将一组复杂的类包装到一个简单的外部接口中。

⑥　享元模式

⑦　代理模式：当客户端代码需要调用某个对象时，客户端实际上不关心是否准确得到该对象，它只要一个能够提供该功能的对象即可，此时我们就可以返回该对象的代理（Proxy）;

只要客户端代码不能或不想直接访问被调用对象，比如需创建一个系统开销很大的对象，或者被调用的对象在远程主机上，或则目标对象的功能还不足以满足要求，此时可以使用代理对象。

当目标对象的功能不足以满足客户端要求时，系统可以为该对象创建一个代理对象，而代理对象可以增强目标对象的功能。

3)行为型：用于帮助系统间各对象的通信，以及如何控制复杂系统中的流程。主要包括：

①　命令模式:命令模式属于对象的行为模式。命令模式又称为行动(Action)模式或交易(Transaction)模式。

　　命令模式把一个请求或者操作封装到一个对象中。命令模式允许系统使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。

命令模式是对命令的封装。命令模式把发出命令的责任和执行命令的责任分割开，委派给不同的对象。

　　每一个命令都是一个操作：请求的一方发出请求要求执行一个操作；接收的一方收到请求，并执行操作。命令模式允许请求的一方和接收的一方独立开 来，使得请求的一方不必知道接收请求的一方的接口，更不必知道请求是怎么被接收，以及操作是否被执行、何时被执行，以及是怎么被执行的。

一般使用某个接口的匿名内部类的形式表示命令。

②　解释器模式

③　迭代器模式

④　中介者模式

⑤　备忘录模式

⑥　观察者模式：观察者模式定义了对象间的一对多依赖关系，让一个或多个观察者对象观察一个主题对象，当主题对象的状态发生变化时，系统能通知所有的依赖于此对象的观察者对象，从而使得观察者对象自动更新。

观察者模式通常包含以下4个角色：

 被观察者的抽象基类：他通常会持有多个观察者对象的引用。Java提供了java.util.observable基类代表被观察者的抽象基类。

 观察者接口：该接口是所有被观察者对象应该实现的接口，通常它只含一个update（）方法。Java同样提供了java.util.Observer接口代表观察者接口。

被观察者实现类：该类继承Observable基类。

观察者实现类：实现Observer接口，实现update（）抽象方法。

⑦　状态模式

⑧　策略模式：策略模式用于封装系列的算法，这些算法通常被封装在一个被称为Context的类中，客户端程序可以自由选择其中的一种算法，或让Context为客户端选择一个最佳的算法，可以支持算法的自由切换。不使用switch case的方法，定义策略接口，使用不通的算法实现该接口。在定义使用策略的方法中，定义一个切换策略的方法。

⑨　模板模式

⑩　访问者模式

常见架构设计策略：

贫血模型:是最常用最简单的架构。所谓贫血指Domain Object只是单纯的数据类，不包含业务逻辑方法，即每个Domain Object类中只包含相关属性，并为每个属性提供getter、setter方法。贫血模式中Domain Object只是数据载体，仅仅是ORm框架持久化所需的持久化实体类。但是贫血模式背离了Java的面向对象的设计思想，只有属性没有动作。

领域对象模型：可重用度高，与Domain object密切相关的业务方法应放在Domain Object对象中实现。更好的实现面向对象的封装性。这就是rich Domain object。程序交叉依赖多。