23种设计模式总览
创建型模式
结构型模式
- 外观模式(Facade)
- 适配器模式(Adapter)
- 代理模式(Proxy)
- 组合模式(Composite)
- 享元模式(Flyweight)
- 装饰模式(Decorator)
- 桥接模式(Bridge)
行为型模式
- 中介者模式(Mediator)
- 观察者模式(Observer)
- 命令模式(Command)
- 迭代器模式(Iterator)
- 模板方法模式(Template Method)
- 策略模式(Strategy)
- 状态模式(State)
- 备忘录模式(Memento)
- 解释器模式(Interpreter)
- 职责链模式(Chain of Responsibility)
- 访问者模式(Visitor)
定义
运用共享技术有效的支持大量细粒度的对象
使用场景
- 系统中存在大量的相似对象
- 细粒度的对象都具备较接近的外部状态,而内部状态与环境无关,也就是说对象没有特定身份
- 需要缓冲池的场景
当系统中多处需要同一组信息时,可以把这些信息封装到一个对象中,然后对该对象进行缓存,这样,一个对象就可以提供给多处需要使用的地方,避免大量同一对象的多次创建,消耗大量内存空间。
享元模式其实就是工厂模式的一个改进机制,享元模式同样要求创建一个或一组对象,并且就是通过工厂方法生成对象的,只不过享元模式中为工厂方法增加了缓存这一功能。
主要总结为以下应用场景:
- 常常应用于系统底层的开发,以便解决系统的性能问题。
- 系统有大量相似对象,需要缓冲池的场景。
在生活中的享元模式也很常见,比如各中介机构的房源共享,再比如全国社保联网。
优缺点
- 优点:
大幅度降低内存中对象的数量,提升性能减少内存 - 缺点:
为了使对象可以共享,需要将一些状态外部化,使得程序逻辑复杂化,而且读取外部状态使得运行时间稍微变长
涉及的角色
- 抽象享元角色(Flyweight):享元对象抽象基类或者接口,同时定义出对象的外部状态和内部状态的接口或实现。
- 具体享元角色(ConcreteFlyweight):实现抽象角色定义的业务。该角色的内部状态处理应该与环境有关,不能出现有一个操作改变内部状态,同时修改了外部状态。
- 享元工厂(FlyweightFactory):负责管理享元对象池和创建享元对象。
具体实现
现在要求模拟一个查询火车票伪代码,可以通过出发站,目的站查到相关票的信息。火车的信息包含:出发站、目的站、价格、座位类别。
public interface ITicket {
void showInfo(String bunk);
}
public class TrainTicket implements ITicket {
private String from;
private String to;
private int price;
public TrainTicket(String from, String to) {
this.from = from;
this.to = to;
this.price = new Random().nextInt(600);
}
@Override
public void showInfo(String bunk) {
System.out.println(String.format("%s->%s:%s价格:%s元", this.from, this.to, bunk, this.price));
}
}
最后创建TicketFactory类:
public class TicketFactory {
public static ITicket queryTicket(String from, String to) {
return new TrainTicket(from, to);
}
}
编写客户端代码:
public class Test {
public static void main(String[] args) {
ITicket ticket = TicketFactory.queryTicket("杭州", "北京");
ticket.showInfo("动车");
}
}
分析上面的代码,我们发现客户端进行查询时,系统通过TicketFactory直接创建一个火车票对象,但是这样做的话,当某个瞬时如果有大量的用户请求同一张票的信息时,系统就会创建出大量该火车票对象,系统内存压力骤增。而其实更好的做法应该是缓存该票对象,然后复用提供给其他查询请求,这样一个对象就满足以支撑数以千计的查询请求,对内存完全无压力,使用享元模式可以很好的解决这个问题。我们继续优化代码,只需在TicketFactory类中进行更改,增加缓存机制:
public class TicketFactory {
private static Map<String, ITicket> ticketPool = new ConcurrentHashMap<>();
public static ITicket queryTicket(String from, String to) {
String key = from + "->" + to;
if (ticketPool.containsKey(key)) {
System.out.println("使用缓存:" + key);
return ticketPool.get(key);
}
System.out.println("首次查询,创建对象:" + key);
ITicket ticket = new TrainTicket(from, to);
ticketPool.put(key, ticket);
return ticket;
}
}
修改客户端代码:
public class Test {
public static void main(String[] args) {
ITicket ticket = TicketFactory.queryTicket("杭州", "北京");
ticket.showInfo("动车");
ticket = TicketFactory.queryTicket("杭州", "北京");
ticket.showInfo("动车");
ticket = TicketFactory.queryTicket("杭州", "北京");
ticket.showInfo("动车");
}
}
运行结果如下:
首次查询,创建对象:杭州->北京
杭州->北京:动车价格:581元
使用缓存:杭州->北京
杭州->北京:动车价格:581元
使用缓存:杭州->北京
杭州->北京:动车价格:581元
可以看到,除了第一次查询创建对象后,后续查询相同车次票信息都是使用缓存对象,无需创建新对象了。
再比如,我们经常使用的数据库连接池,因为我们使用Connection对象时主要性能消耗在建立连接和关闭连接上,为了提高Connection在调用时的性能,我们将Connection对象在调用前创建缓存起来,用的时候从缓存中取值,用完再放回去,达到资源重复利用的目的。
String中的享元模式
Java中将String类定义为final(不可变的),JVM中字符串一般保存在字符串常量池中,java会确保一个字符串在常量池中只有一个拷贝,这个字符串常量池在JDK6.0以前是位于常量池中,位于永久代,而在JDK7.0中,JVM将其从永久代拿出来放置于堆中。
我们做一个测试:
public class StringTest {
public static void main(String[] args) {
String s1 = "hello";
String s2 = "hello";
String s3 = "he" + "llo";
String s4 = "hel" + new String("lo");
String s5 = new String("hello");
String s6 = s5.intern();
String s7 = "h";
String s8 = "ello";
String s9 = s7 + s8;
System.out.println(s1 == s2);//true
System.out.println(s1 == s3);//true
System.out.println(s1 == s4);//false
System.out.println(s1 == s5);//false
System.out.println(s1 == s6);//true
System.out.println(s4 == s5);//false
System.out.println(s1 == s9);//false
}
}
String类被final修饰,以字面量的形式创建String变量时,JVM会在编译期间就把该字面量"hello"放到字符串常量池中,由Java程序启动的时候就已经加载到内存中了。这个字符串常量池的特点就是有且只有一份相同的字面量,如果有其它相同的字面量,JVM则返回这个字面量的引用,如果没有相同的字面量,则在字符串常量池创建这个字面量并返回它的引用。
由于s2指向的字面量"hello"在常量池中已经存在了(s1先于s2),于是JVM就返回这个字面量绑定的引用,所以s1==s2。
s3中字面量的拼接其实就是"hello",JVM在编译期间就已经对它进行优化,所以s1和s3也是相等的。
s4中的new String("lo")生成了两个对象,lo,new String("lo"),lo存在字符串常量池,new String("lo")存在堆中,String s4 = "hel" + new String("lo")实质上是两个对象的相加,编译器不会进行优化,相加的结果存在堆中,而s1存在字符串常量池中,当然不相等。s1==s9的原理一样。
s4==s5两个相加的结果都在堆中,不用说,肯定不相等。
s1==s6,s5.intern()方法能是一个位于堆中的字符串在运行期间动态的加入到字符串常量池中(字符串常量池的内容是程序启动的时候就已经加载好了),如果字符串常量池中有该对象对应的字面量,则返回该字面量在字符串常量池中的引用,否则,创建复制一份该字面量到字符串常量池并返回它的引用。因此s1==s6输出true。