准备内容
原型设计模式 PropotypeModle
原型模式也属于创造型设计模式，用原型实例指定创建对象的种类，并且通过拷贝这些原型来创建新的实例。与单例相反，每次都会产生一个新的对象
- Struts2中的Action 原型
- Servlet 单例
在原型的设计模式中，首先我们要指定一个原型（原始对象），通过这个对象可以创建出跟他类型一样的其他对象
通过赋值当前对象的属性和行为创建出跟当前对象一模一样的对象
克隆
克隆就是依据已经有的数据，创造一份新的完全一样的数据拷贝。
-
浅克隆
被复制对象的所有变量都含有与原来的对象相同的值，而所有的对其他对象的引用仍然指向原来的对象。换言之，浅复制仅仅复制所考虑的对象，而不复制它所引用的对象。
-
深克隆
被复制对象的所有变量都含有与原来的对象相同的值，除去那些引用其他对象的变量。那些引用其他对象的变量将指向被复制过的新对象，而不再是原有的那些被引用的对象。换言之，深复制把要复制的对象所引用的对象都复制了一遍。
策略模式StrategyModle
定义一系列算法类，将每一个算法封装起来，并让它们可以相互替换。策略模式让算法独立于使用它的客户而变化。它也被成为政策模式，是一种行为型模式。
在Spring源码中的Resource接口就是策略模式接口，下面提供了很多种策略
-
BeanFactory:是IOC容器实际代表者，就是通过工厂+反射+xml容器实现解耦。操作常见对象
-
ApplicationContext：继承了BeanFactory扩展了父类，增加了父类的功能，比如AOP、JDBC
知识点补充
UML关系
UML定义：统一建模语言用来设计软件蓝图的可视化建模语言
基本构造块:
-
事物（Things）：构建模型图的一些基本图示符号，他们表示一些面向对象的基本概念
-
关系（relationships）：表示基本图示符号之间的关系
-
图（diagrams）：特定的视角对系统所做的抽象描述
-
泛化(generalization)
一个类（称为子类、子接口）继承另外的一个类（称为父类、父接口）的功能，并可以增加它自己的新功能的能力，继承是类与类或者接口与接口之间最常见的关系；
在Java中此类关系通过关键字extends明确标识，在设计时一般没有争议性。
- 实现(realization)
一个class类实现interface接口（可以是多个）的功能；实现是类与接口之间最常见的关系；
在Java中此类关系通过关键字implements明确标识，在设计时一般没有争议性；
- 依赖(dependency)
类与类之间的连接. 表示一个类依赖于另一个类的定义. 依赖关系总是单向的 。可以简单的理解，就是一个类A使用到了另一个类B，而这种使用关系是具有偶然性的、、临时性的、非常弱的，但是B类的变化会影响到A；比如某人要过河，需要借用一条船，此时人与船之间的关系就是依赖；表现在代码层面，为类B作为参数被类A在某个method方法中使用.
在java 中. 依赖关系体现为: 局部变量, 方法中的参数, 和对静态方法的调用.
- 关联
表示类与类之间的联接, 它使一个类知道另一个类的属性和方法.
他体现的是两个类、或者类与接口之间语义级别的一种强依赖关系，比如我和我的朋友；这种关系比依赖更强、不存在依赖关系的偶然性、关系也不是临时性的，一般是长期性的，而且双方的关系一般是平等的、关联可以是单向、双向的；表现在代码层面，为被关联类B以类属性的形式出现在关联类A中，也可能是关联类A引用了一个类型为被关联类B的全局变量；
* 双向关联
>双方都知道对方的存在，都可以调用对方的公共属性、方法。
* 自身关联
>自己关联自己，这种情况比较少出现但是也有用到。
- 聚合(aggregation)关系
关联关系的一种特例, 是强的关联关系. 聚合是整体和个体之间的关系,即has-a的关系，此时整体与部分之间是可分离的，他们可以具有各自的生命周期，部分可以属于多个整体对象，也可以为多个整体对象共享；比如计算机与CPU、公司与员工的关系等；表现在代码层面，和关联关系是一致的，只能从语义级别来区分；
聚合关系也是使用实例变量实现的. 从java 语法上是分不出关联和聚合的.
关联关系中两个类是处于相同的层次, 而聚合关系中两不类是处于不平等的层次, 一个表示整体, 一个表示部分.
- 组合(合成)关系(composition)
也是关联关系的一种特例，他体现的是一种contains-a的关系，这种关系比聚合更强，也称为强聚合；他同样体现整体与部分间的关系，但此时整体与部分是不可分的，整体的生命周期结束也就意味着部分的生命周期结束；比如你和你的大脑；合成关系不能共享. 。表现在代码层面，和关联关系是一致的，只能从语义级别来区分。
组合跟聚合几乎相同，唯一的区别就是“部分”不能脱离“整体”单独存在，就是说， “部分”的生命期不能比“整体”还要长。
业务层和持久层解藕
为什么在MVC的三层开发架构中会非常推崇接口编程，
那么根据已有的解释，接口编程的好处是：
可以帮助层与层之间的解耦，让每个部分独立出来，互不影响，更加的利于团队开发合作和提高复用性与扩展性。
- 框架简图
框架简图.jpeg
- UserService是通过接口UserDao来间接操作UserDaoImpl访问Domain对象User中的数据。
- 在访问User时就必定要在UserService中有这样的语句：UserDao userDao = new UserDaoImpl(); 那么，问题来了， UserDaoImpl实现类在这里出现并将导致在后期拓展时（比如UserDao的具体实现改换为Hibernate或者其它技术）就无法真正的做到解耦，因为你必须在你的源代码中指定具体的实现类。
实现解耦
让UserService仅仅只需要通过数据访问接口UserDao就做到需要的操作。那么，应该如何来做呢？
- 提供一个工厂类，让他去对具体的实现类进行实例化，并返回UserDao的实现类的实例的引用。
- 通过配置文件（XML/Properties）来配置，让工厂类去读取（或者专用的操作类去读取）
避免了 UserDao userDao = new UserDaoImpl();
配置文件 （config.property）
user=com.project.dao.impl.UserDaoImpl
提供一个工厂类（BeanFactory）
public class BeanFactory {
private static IUserDao dao;
private static BeanFactory fa = new BeanFactory();
//单例工厂
private BeanFactory(){
//生产实现类：
//(1)读取文件
Properties pro = new Properties();
InputStream in = BeanFactory.class.getClassLoader().getSystemResourceAsStream("config.properties");
try {
//(2)加载配置文件，读取全路径
pro.load(in);
String path = pro.getProperty("user");
//(3)通过反射的机制创建类的实例
dao = (IUserDao) Class.forName(path).newInstance();
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
public static BeanFactory getBeanFactory(){
return fa;
}
public static IUserDao getUser(){
return dao;
}
}
网友评论