享元模式的主要目的是实现对象的共享,即共享池,当系统中对象多的时候可以减少内存的开销
FlyWeightFactory负责创建和管理享元单元,当一个客户端请求时,工厂需要检查当前对象池中是否有符合条件的对象,如果有,就返回已 经存在的对象,如果没有,则创建一个新对象,FlyWeight是超类。一提到共享池,我们很容易联想到Java里面的JDBC连接池,想想每个连接的特 点,我们不难总结出:适用于作共享的一些个对象,他们有一些共有的属性,就拿数据库连接池来说,url、driverClassName、 username、password及dbname,这些属性对于每个连接来说都是一样的,所以就适合用享元模式来处理,建一个工厂类,将上述类似属性作 为内部数据,其它的作为外部数据,在方法调用时,当做参数传进来,这样就节省了空间,减少了实例的数量。
看个例子:
看下数据库连接池的代码:
这个例子很好,说明了享元模式 其实就是共享对象,当我们需要一个新的对象的时候,先看下共享池里面有没有,没有就创建,有就不用了,
在android中:Context.getSystemService就使用了享元模式的原理,其实这个具体方法的实现还使用到了 装饰器模式
1.每个应用组件都可以使用系统提供的众多服务管理对象,如WallpaperManager、AccessibilityManager、CaptioningManager、AccountManager等等。
因此为了在一个组件内共享这些对象,在应用组件的Context的实现ContextImpl中,
在ContextImpl类第一次加载引用时为每个管理对象都创建了一个ServiceFetcher对象(采用静态代码块),
并根据服务名字把新创建的ServiceFetcher对象放到MAP集合中,
每个ServiceFetcher对象在登记到MAP集合中时都分配了一个索引。 2.应用组件在调用Context.getSystemService来获得系统服务管理对象时,
首先根据服务名字从MAP集合中获得对应的ServiceFetcher对象,
然后调用ServiceFetcher对象的getService函数获得ServiceFetcher对象创建的服务管理对象。 3.在ServiceFetcher对象的getService函数中首先从Context维护的Cache数组列表中,
根据ServiceFetcher对象的索引查找是否已经包含有ServiceFetcher对象创建的服务管理对象,
如果在Cache中存在服务管理对象,则直接返回Cache中保存的服务管理对象,
否则调用ServiceFetcher的createService函数创建一个服务管理对象,并根据其索引放置到Cache中,以便下次使用。