快捷搜索:

Java设计模式分析之适配器(Adapter)

本日一大年夜早,你的leader就促忙忙跑过来找到你:“快,快,紧急义务!近来ChinaJoy顿时就要开始了,老板要求供给一种直不雅的要领,可以查看到我们新上线的游戏中每个服的在耳目数。”

你看了看日期,不是吧!这哪里是顿时要开始了,分明是已经开始了!这怎么可能来得及呢?

“不要紧的。”你的leader劝慰你道:“功能着实很简单的,接口都已经供给好了,你只必要调用一下就行了。”

好吧,你勉为其难地吸收了,对付这种突如其来的新需求,你早已习气。

你的leader向你详细描述了一下需求,你们的游戏今朝有三个服,一服已经开放一段光阴了,二服和三服都是新开的服。设计的接口异常轻便,你只必要调用Utility.getOnlinePlayerCount(int),传入每个服对应的数值就可以获取到响应服在线玩家的数量了,如一服传入1,二服传入2,三服则传入3。假如你传入了一个不存在的服,则会返回-1。然后你只要将获得的数据拼装成XML就好,详细的显示功能由你的leader来完成。

好吧,听起来功能并不是很繁杂,假如现在就开始动工似乎还来得及,于是你顿时敲起了代码。

首先定义一个用于统计在耳目数的接口PlayerCount,代码如下:

public interface PlayerCount {

String getServerName();

int getPlayerCount();

}

接着定义三个统计类实现了PlayerCount接口,分手对应了三个不合的服,如下所示:

public class ServerOne implements PlayerCount {

@Override

public String getServerName() {return "一服";

}

@Overridepublic int getPlayerCount() {

return Utility.getOnlinePlayerCount(1);}

}

public class ServerTwo implements PlayerCount {

@Overridepublic String getServerName() {

return "二服";}

@Override

public int getPlayerCount() {return Utility.getOnlinePlayerCount(2);

}

}public class ServerThree implements PlayerCount {

@Override

public String getServerName() {return "三服";

}

@Overridepublic int getPlayerCount() {

return Utility.getOnlinePlayerCount(3);}

}

然后定义一个XMLBuilder类,用于将各服的数据封装成XML款式,代码如下:

public class XMLBuilder {

public static String buildXML(PlayerCount player) {

StringBuilder builder = new StringBuilder();builder.append("");

builder.append("").append(player.getServerName()).append("");builder.append("

).append(player.getPlayerCount()).append("");

builder.append("");return builder.toString();

}

}

这样的话,所有代码就竣工了,假如你想查看一服在线玩家数只必要调用:

XMLBuilder.buildXML(new ServerOne());

查看二服在线玩家数只必要调用:

XMLBuilder.buildXML(new ServerTwo());

查看三服在线玩家数只必要调用:

XMLBuilder.buildXML(new ServerThree());

咦?你发明查看一服在线玩家数的时刻,返回值永世是-1,查看二服和三服都很正常。

你只好把你的leader叫了过来:“我感到我写的代码没有问题,然则查询一服在线玩家数老是返回-1,为什么会这样呢?”

“哎呀!”你的leader骤然想起,“这是我的问题,前面没跟你解释清楚。因为我们的一服已经开放一段光阴了,查询在线玩家数量的功能早就有了,应用的是ServerFirst这个类。当时写Utility.getOnlinePlayerCount()这个措檀越如果为了针对新开的二服和三服,就没把一服的查询功能再重复做一遍。”

听到你的leader这么说,你立时松了一口气:“那你改动一下Utility.getOnlinePlayerCount()就好了,应该没我什么事了吧?”

“晤。。。原先应该是这样的。。。可是,Utility和ServerFirst这两个类都已经被打到Jar包里了,没法改动啊。。。”你的leader有些尴尬。

“什么?这不是坑爹吗,难道要我把接口给改了?”你已经泣如雨下了。

“这倒不用,这种环境下可以应用适配器模式,这个模式便是为了办理接口之间不兼容的问题而呈现的。”

着实适配器模式的应用异常简单,核心思惟便是只要能让两个互不兼容的接口能正常对接就行了。上面的代码中,XMLBuilder中应用PlayerCount这个接口来拼装XML,而ServerFirst并没有实现PlayerCount这个接口,这个时刻就必要一个适配器类来为XMLBuilder和ServerFirst之间搭起一座桥梁,毫无疑问,ServerOne就将充当适配器类的角色。改动ServerOne的代码,如下所示:

public class ServerOne implements PlayerCount {

private ServerFirst mServerFirst;

public ServerOne() {

mServerFirst = new ServerFirst();}

@Override

public String getServerName() {return "一服";

}

@Overridepublic int getPlayerCount() {

return mServerFirst.getOnlinePlayerCount();}

}

这样经由过程ServerOne的适配,XMLBuilder和ServerFirst之间就成功完成对接了!应用的时刻我们以致无需知道有ServerFirst这个类,只必要正常创建ServerOne的实例就行了。

必要值得留意的一点是,适配器模式不并是那种会让架构变得更合理的模式,更多的时刻它只是充当救火队员的角色,赞助办来因为前期架构设计分歧理导致的接口不匹配的问题。更好的做法是在设计的时刻就只管即便把今后可能呈现的环境多斟酌一些,在这个问题上不要向你的leader进修。

适配器:将一个类的接口转换成客户盼望的别的一个接口。适配器模式使得蓝本因为接口不兼容而不能一路事情的那些类可以一路事情。

您可能还会对下面的文章感兴趣: