标签：享元 WebSite use 对象 网站 源码 设计模式 public
举个最简单的例子，网络联机下棋的时候，一台服务器连接了多个客户端（玩家），如果我们每个棋子都要创建对象，那一盘棋可能就有上百个对象产生，玩家多点的话，因为内存空间有限，一台服务器就难以支持了，所以这里要使用享元模式，将棋子对象减少到几个实例。下面给出享元模式的定义。
二、享元模式的结构
享元模式（ Flyweight），运用共享技术有效的支持大量细粒度的对象。UML结果图如下：
1、Flyweight 是抽象享元角色。它是产品的抽象类，同时定义出对象的外部状态和内部状态的接口和实现；
2、ConcreteFlyweight 是具体享元角色，是具体的产品类，实现抽象角色定义的业务；
3、UnsharedConcreteFlyweight 是不可共享的享元角色，一般不会出现在享元工厂中；
4、FlyweightFactory 是享元工厂，它用于构造一个池容器，同时提供从池中获得对象的方法。
三、内部状态和外部状态
1、上面享元模式的定义为我们提出了两个要求：细粒度和共享对象。我们知道分配太多的对象列到应用程序中将有损程序的性能，同时还容易造成内存溢出，要避免这种情况，用到的就是享元模式，这里就需要提到内部状态和外部状态了。
因为要求细粒度对象，所以不可避免地会使对象数量多且性质相近，此时我们就将这些对象的信息分为两个部分：内部状态和外部状态。
2、内部状态指对象共享出来的信息，存储在享元对象内部并且不会随环境的改变而改变；
3、外部状态指对象得以依赖的一个标记，是随环境改变而改变的、不可共享的状态。
我们举一个最简单的例子，棋牌类游戏大家都有玩过吧，比如说说围棋和跳棋，它们都有大量的棋子对象，围棋和五子棋只有黑白两色，跳棋颜色略多一点，但也是不太变化的，所以棋子颜色就是棋子的内部状态；而各个棋子之间的差别就是位置的不同，我们落子嘛，落子颜色是定的，但位置是变化的，所以方位坐标就是棋子的外部状态。
那么为什么这里要用享元模式呢？可以想象一下，上面提到的棋类游戏的例子，比如围棋，理论上有361个空位可以放棋子，常规情况下每盘棋都有可能有两三百个棋子对象产生，因为内存空间有限，一台服务器很难支持更多的玩家玩围棋游戏，如果用享元模式来处理棋子，那么棋子对象就可以减少到只有两个实例，这样就很好的解决了对象的开销问题。
四、享元模式的优缺点
1、优点
大大减少了对象的创建，降低了程序内存的占用，提高效率
2、缺点
提高了系统的复杂度，需要分离出内部状态和外部状态，而外部状态具有固化特性，不应该随着内部状态的改变而改变。
五、享元模式的使用场景
1、何时应用
（1）系统中有大量对象时
（2）这些对象消耗大量内存时
（3）这些对象的状态大部分可以外部化时
（4） 需要缓冲池的场景
2、实现方式
用唯一标识码判断，如果在内存中有，则返回这个唯一标识码所标识的对象，用hashmap存储。
3、应用实例
（1）string常量池
（2）数据库连接池
六、代码实例
应用实例的话，其实上面的模板就已经是一个很好的例子了，类似于String常量池，没有的对象创建后存在池中，若池中存在该对象则直接从池中取出。
为了更好的理解享元模式，这里再举一个实例，比如接了我一个小型的外包项目，是做一个产品展示网站，后来他的朋友们也希望做这样的网站，但要求都有些不同，我们当然不能直接复制粘贴再来一份，有任希望是新闻发布形式的，有人希望是博客形式的等等，而且因为经费原因不能每个网站租用一个空间。
其实这里他们需要的网站结构相似度很高，而且都不是高访问量网站，如果分成多个虚拟空间来处理，相当于一个相同网站的实例对象很多，这是造成服务器的大量资源浪费。如果整合到一个网站中，共享其相关的代码和数据，那么对于硬盘、内存、CPU、数据库空间等服务器资源都可以达成共享，减少服务器资源；而对于代码，由于是一份实例，维护和扩展都更加容易。
那么此时就可以用到享元模式了。UML图如下：
1、网站抽象类
package designMode.Flyweight.web2;
public abstract class WebSite {
public abstract void use();
}
2、网站具体类
package designMode.Flyweight.web2;
public class ConcreteWebSite extends WebSite {
private String name = “”;
public ConcreteWebSite(String name) {
this.name = name;
}
@Override
public void use() {
System.out.println(“网站分类：” + name);
}
}
3、网站工厂类
package designMode.Flyweight.web2;
import java.util.HashMap;
public class WebSiteFactory {
private HashMap<String, ConcreteWebSite> pool = new HashMap<>();
//获得网站分类
public WebSite getWebSiteCategory(String key) {
if(!pool.containsKey(key)) {
pool.put(key, new ConcreteWebSite(key));
}
return (WebSite)pool.get(key);
}
//获得网站分类总数
public int getWebSiteCount() {
return pool.size();
}
}
4、client客户端
这里测试用例给了两种网站，原先我们需要做三个产品展示和三个博客的网站，也即需要六个网站类的实例，但其实它们本质上都是一样的代码，可以利用用户ID号的不同，来区分不同的用户，具体数据和模板可以不同，但代码核心和数据库却是共享的。
package designMode.Flyweight.web2;
public class Client {
public static void main(String[] args) {
WebSiteFactory factory = new WebSiteFactory();
WebSite fx = factory.getWebSiteCategory(“产品展示”);
fx.use();
WebSite fy = factory.getWebSiteCategory(“产品展示”);
fy.use();
WebSite fz = factory.getWebSiteCategory(“产品展示”);
fz.use();
WebSite fa = factory.getWebSiteCategory(“博客”);
fa.use();
WebSite fb = factory.getWebSiteCategory(“博客”);
fb.use();
WebSite fc = factory.getWebSiteCategory(“博客”);
fc.use();
System.out.println(“网站分类总数为：” + factory.getWebSiteCount());
}
}
5、运行结果
可以看出，虽然我们做了6个网站，但网站分类只有2个。这样基本算是实现了享元模式的共享对象的目的，但想想上面提到的内部状态和外部状态，这里实际上没有体现对象间的不同，只体现了它们的共享部分。
6、用户类
所以我们再加一个用户类，作为网站类的外部状态，并在use()方法中传递用户对象，UML如下：
下面添加一个User类。
package designMode.Flyweight.web2;
public class User {
private String name;
public User(String name){
this.name = name;
}
public String getName(){
return name;
}
}
然后再对use()方法进行修改，添加参数，以抽象类为例：
package designMode.Flyweight.web2;
public abstract class WebSite {
public abstract void use();
public abstract void use(User user);
}
而客户端中只需对每一个网站添加一个用户即可，如：
fx.use(new User(“素小暖”));
运行结果如下：
这样就可以协调内部与外部状态，哪怕接手了上千个网站的需求，只要要求相同或类似，实际开发代码也就是分类的哪几种。
七、Integer的享元模式解析
1、测试类
标签：享元,WebSite,use,对象,网站,源码,设计模式,public 来源： https://blog.csdn.net/m0_65639193/article/details/122075628
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。