设计模式再探——原型模式

一、背景介绍

最近在做业务实现的时候，为了通过提升机器来降低开发人员的难度和要求，于是在架构设计上严格按照面向对象去做的。
进而在内存中同一个类处理业务的对象就会很多，为了解决对象复制过程中降低耦合的要求，研究了原型模式。

二、思路&方案

• 1.原型模式简介
• 2.原型模式的类图
• 3.原型模式代码
• 4.原型模式深度剖析
• 5.原型模式与spring

三、过程

1.原型模式简介

原型模式(ProtoTYpe)，用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。

2.原型模式的类图

3.原型模式代码

4.原型模式深度剖析

原型模式中的具体原型类concretePrototype1和concretePrototype2有横向纵向两层含义：

• 4.1.横向，可以是同一个业务的浅复制和深复制
• 4.2.纵向，可以是不同业务的浅复制或深复制

5.原型模式与spring

• 5.1.我们都知道如果一个类交给spring进行创建对象，并且创建出来的对象生命周期也交给spring来管理的话，必须强制为单例类；真正使用的时候则通过分时复用进行调用，当我们需要对象并发处理业务的时候我们考虑的事情就会很多。
• 5.2.如果我们的类交给spring进行创建对象的时候，只需要将单例注解的参数修改为原型，每次从springbean中获取的对象将会是新的对象；而此时获取的新对象生命周期需要我们自己去管理。
• 5.3.在我们的业务中，例如对于主题讨论中的回复，张三想要按照点赞排序，李四想要按照回复排序；当他们发出请求后，我们就可以通过浅复制方式，使用同一份回复内容，通过不同的对象来分别处理不同的排序结果。

四、总结

• 1.对于原型模式的边界进行梳理过后，在实际需要的场景中运用就会更加明确
• 2.原型模式通过统一的clone接口，使得需要复制的业务类强制按照接口规范进行实现从而保证了客户端调用的统一性
• 3.原型模式在客户端做了父类强转子类的操作，使得生成的对象必须具备子类对应的显示调用的行为(这里也让我想到了接口隔离中的子类强转为父类，使得对象只能显示调用父类的行为)

五、升华

通过对于原型模式的梳理和再探的过程，进一步强化了面向对象中面对抽象编程和面对接口编程这件事；而通过原型模式深浅复制的不同场景的运用使得迪米特法则的落地也更加的彻底。