话说距离上次发文章已经是时隔将近一个半月了,期间忙着项目所以对于文章或者说知识的总结就给忽略了!
这次我们来说说重构,说之前要感谢带领我入门的那些大哥(我曾经的同事,我喊他锋哥,还有经理 包大哥),那个时候虽然大家都在讨论但是我作为一个菜鸟级的人物,听得不太懂不过现在做android 这一块我发现代码真是乱,所以就想到了这个东西,于是乎就做了一把refactor!
个人理解重构的概念
重构:就是在不改变现有软件的质量以及运行的情况下,对代码的整理以及对逻辑的从新梳理,已达到逻辑清晰,代码可读性好,整洁这样一个效果!
以上是我个人的理解,有误之处请大家指出来啊!无喷!
那么好了接下来说例子,因为我做的android 项目现在负责的就是xml解析数据 以及返回给 activity 数据 先来了解一下结构类图如下:
[img]http://dl.iteye.com/upload/attachment/539361/f1295c46-803c-3057-b464-7061ee15d020.jpg[/img]
这是 原来没有重构之前的类图,需要说明的是service 和handler的子类有很多个!
下面说一下service 和 handler 里面的方法。。。
在每个service 和 handler 里面都包含有这样一个方法getXXXtBean():Object 返回的都是 具体的类型。。。(我这到这样做不好)
下面我们重点说一下 service 里面的方法。。
[img]http://dl.iteye.com/upload/attachment/539363/bdd06ea5-2c3f-324b-9a61-f389dd61c8ff.jpg[/img]
代码如下:
注意比较上面两段代码,他们是否存在共同之处呢?
/*********以上是重构之前的代码和结构*********************************************/
现在总结一下:我们从上面的图 和 代码中应该能察觉到这写个handler 子类 以及 service 类中存在相同的代码! 而且他们在service处理 拿到对象的逻辑是相同的。。。
所以我在做完这一期项目之后就考虑了一下进行重构一把(不过千万别忘了单元测试。。。如果重构之后没有做测试,那么我觉得你的工作只能说做了40%)!
那好接下来说说我重构的思路。。。。
因为service中存在项目的方法 和逻辑我想了一下就是准备使用模板方法 模式来进行重构!
他们出来对象的逻辑是相同的。因此我就有了这样个 BaseService
代码:
没有baseservice之前我们的处理方式就如同上面的那种。。。(getCheckOutBean() getCheckUserPlayingBean()) 但是他们的程序逻辑是一样的。
都是先拿到url 然后 交给httpclient类产生inputstream 之后就是判断是否为空,接着就是
产生handler 让后让handler解析,最后就是拿到 handler 处理之后的对象!
现在我们看看baseservice 的tempalte 方法。。final 的防止子类修改 整个处理逻辑!
是的吧,是和原来一样的逻辑!没错,你是对的,就是这样的。。。然后让所有的service子类都去继承 这个baseservice 。。。。
注意你看到了。。在baseservice中包含了。。MyDefaultHandler对象。。。。这里之所以这么做,是因为。。每一个 handler 之类在解析完之后都会产生具体的 对象。。
如果是 PlayingListBeanHandler 就产生。。。PlayingListBean对象。。。如果是
CheckOutBeanHandler 就产生。。CheckOutBean ..。。看原来的类图中。。可以看到这些方法。。的。。。
所以我就想这些对象都是 Object的子类。。为何不能定义一个通用的方法。。返回Object 然后具体的类型都交给 调用类来转换。。。
this.object = handler.getBean(); //就是这一句了。。呵呵。。
来看看。。MyDefaultHandler 。。
只有这样一个方法。。。。abstract 来修饰的。。呵呵!!!
看重构之后的类图:
[img]http://dl.iteye.com/upload/attachment/539380/565332f7-a66e-3c6d-b770-7350820388b7.jpg[/img]
接下来看重构之后的service代码:
好了。。看看是不是比之前的代码 清晰了。。。要是再有需求来了。。我就写一个service 继承。。basservice 。。。然后程序逻辑不需要改变。。。也没必要知道 是怎么写的。。
直接实现方法。。就可以了。。呵呵。。。应该说达到了。。代码的复用!
对了。。我们来看一下钩子函数的 。。调用代码
当你需要调用。。如下代码的时候。。
你只需要让 baseservice 重写这个。。callback方法即可。。
、。。。这样是不是感觉。。代码清晰很多了呢!!! 这里我要感谢一下现在的同事,我最初重构的效果并非如此,要感谢他的建议!!!呵呵。。。
这次我们来说说重构,说之前要感谢带领我入门的那些大哥(我曾经的同事,我喊他锋哥,还有经理 包大哥),那个时候虽然大家都在讨论但是我作为一个菜鸟级的人物,听得不太懂不过现在做android 这一块我发现代码真是乱,所以就想到了这个东西,于是乎就做了一把refactor!
个人理解重构的概念
重构:就是在不改变现有软件的质量以及运行的情况下,对代码的整理以及对逻辑的从新梳理,已达到逻辑清晰,代码可读性好,整洁这样一个效果!
以上是我个人的理解,有误之处请大家指出来啊!无喷!
那么好了接下来说例子,因为我做的android 项目现在负责的就是xml解析数据 以及返回给 activity 数据 先来了解一下结构类图如下:
[img]http://dl.iteye.com/upload/attachment/539361/f1295c46-803c-3057-b464-7061ee15d020.jpg[/img]
这是 原来没有重构之前的类图,需要说明的是service 和handler的子类有很多个!
下面说一下service 和 handler 里面的方法。。。
在每个service 和 handler 里面都包含有这样一个方法getXXXtBean():Object 返回的都是 具体的类型。。。(我这到这样做不好)
下面我们重点说一下 service 里面的方法。。
[img]http://dl.iteye.com/upload/attachment/539363/bdd06ea5-2c3f-324b-9a61-f389dd61c8ff.jpg[/img]
代码如下:
public static CheckOutBean getCheckOutBean(Context context,String playlistId,String pID) throws ParserConfigurationException, SAXException, IOException{
String urlPath = URLRequest.CHECKOUT.getUrl()+"playlistid="+ playlistId + "&pid="+ pID; //这个地方每个sevice 的url 不同
InputStream inputStream = HttpClient.getInputByHttpConn(urlPath,context);
if(null != inputStream){
SAXParserFactory factory = SAXParserFactory.newInstance();
SAXParser parser = factory.newSAXParser();
ParserCheckOutXMLHandler handler = new ParserCheckOutXMLHandler();//这个地方调用的 handler 不同
parser.parse(inputStream, handler);
return handler.getCheckOutBean(); //返回的对象不同
}
return null;
}
public static CheckUserPlayingBean getCheckUserPlayingBean(Context context,String playlistId) throws ParserConfigurationException, SAXException, IOException{
String url = URLRequest.CHECKUSERPLAYING.getUrl()+ playlistId;
InputStream inputStream = HttpClient.getInputByHttpConn(url,context);
if(null != inputStream){
SAXParserFactory factory = SAXParserFactory.newInstance();
SAXParser saxParser = factory.newSAXParser();
ParserCheckUserPlayingXMLHandler handler = new ParserCheckUserPlayingXMLHandler();
saxParser.parse(inputStream, handler);
return handler.getCheckUserPlayingBean();
}
return null;
}
注意比较上面两段代码,他们是否存在共同之处呢?
/*********以上是重构之前的代码和结构*********************************************/
现在总结一下:我们从上面的图 和 代码中应该能察觉到这写个handler 子类 以及 service 类中存在相同的代码! 而且他们在service处理 拿到对象的逻辑是相同的。。。
所以我在做完这一期项目之后就考虑了一下进行重构一把(不过千万别忘了单元测试。。。如果重构之后没有做测试,那么我觉得你的工作只能说做了40%)!
那好接下来说说我重构的思路。。。。
因为service中存在项目的方法 和逻辑我想了一下就是准备使用模板方法 模式来进行重构!
他们出来对象的逻辑是相同的。因此我就有了这样个 BaseService
代码:
public abstract class BaseService {
int retryTimes = 5;
protected Context context;
protected String url;
protected InputStream inputStream;
protected SAXParserFactory factory;
protected SAXParser parser;
protected MyDefaultHandler handler;
protected Object object;
protected final void template(){
getInputStream();
if( null != inputStream ){
factory = SAXParserFactory.newInstance();
try {
parser = factory.newSAXParser();
handler = getHandler();
parser.parse(inputStream, handler);
} catch (ParserConfigurationException e) {
e.printStackTrace();
} catch (SAXException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}
this.object = handler.getBean();
}
}
private void getInputStream(){
//这个方法 是因为某些 service 处理的逻辑需要反复的 去判断网络是否正常
//所以我使用了一个callBack方法。。让子类决定是否调用这里面的逻辑
if(callBack()){
while(retryTimes>=1){
inputStream = HttpClient.getInputByHttpConn(loadUrl(), context);
if(null != inputStream){
break;
}
try {
Thread.sleep(100);
} catch (InterruptedException e) {
e.printStackTrace();
}
retryTimes --;
}
}
inputStream = HttpClient.getInputByHttpConn(loadUrl(), context);
}
protected abstract String loadUrl();
protected abstract MyDefaultHandler getHandler();
protected boolean callBack(){
return false;
}
}
没有baseservice之前我们的处理方式就如同上面的那种。。。(getCheckOutBean() getCheckUserPlayingBean()) 但是他们的程序逻辑是一样的。
都是先拿到url 然后 交给httpclient类产生inputstream 之后就是判断是否为空,接着就是
产生handler 让后让handler解析,最后就是拿到 handler 处理之后的对象!
现在我们看看baseservice 的tempalte 方法。。final 的防止子类修改 整个处理逻辑!
是的吧,是和原来一样的逻辑!没错,你是对的,就是这样的。。。然后让所有的service子类都去继承 这个baseservice 。。。。
注意你看到了。。在baseservice中包含了。。MyDefaultHandler对象。。。。这里之所以这么做,是因为。。每一个 handler 之类在解析完之后都会产生具体的 对象。。
如果是 PlayingListBeanHandler 就产生。。。PlayingListBean对象。。。如果是
CheckOutBeanHandler 就产生。。CheckOutBean ..。。看原来的类图中。。可以看到这些方法。。的。。。
所以我就想这些对象都是 Object的子类。。为何不能定义一个通用的方法。。返回Object 然后具体的类型都交给 调用类来转换。。。
this.object = handler.getBean(); //就是这一句了。。呵呵。。
来看看。。MyDefaultHandler 。。
public abstract class MyDefaultHandler extends DefaultHandler {
public abstract Object getBean();
}
只有这样一个方法。。。。abstract 来修饰的。。呵呵!!!
看重构之后的类图:
[img]http://dl.iteye.com/upload/attachment/539380/565332f7-a66e-3c6d-b770-7350820388b7.jpg[/img]
接下来看重构之后的service代码:
private String playlistId;
private String pID;
public ParserCheckOutService(){}
public ParserCheckOutService(
Context context,String playlistId,String pID){
this.context = context;
this.playlistId = playlistId;
this.pID = pID;
this.template();//这个地方要注意了。。。。记得调用啊。。
}
@Override
protected String loadUrl() {
return URLRequest.CHECKOUT.getUrl()+"playlistid="+ playlistId + "&pid="+ pID;
}
@Override
protected MyDefaultHandler getHandler() {
return new ParserCheckOutXMLHandler();
}
public CheckOutBean getCheckOutBean() {
return (CheckOutBean)object;
}
好了。。看看是不是比之前的代码 清晰了。。。要是再有需求来了。。我就写一个service 继承。。basservice 。。。然后程序逻辑不需要改变。。。也没必要知道 是怎么写的。。
直接实现方法。。就可以了。。呵呵。。。应该说达到了。。代码的复用!
对了。。我们来看一下钩子函数的 。。调用代码
当你需要调用。。如下代码的时候。。
if(callBack()){
while(retryTimes>=1){
inputStream = HttpClient.getInputByHttpConn(loadUrl(), context);
if(null != inputStream){
break;
}
try {
Thread.sleep(100);
} catch (InterruptedException e) {
e.printStackTrace();
}
retryTimes --;
}
}
你只需要让 baseservice 重写这个。。callback方法即可。。
@Override
protected boolean callBack() {
return true;
}
、。。。这样是不是感觉。。代码清晰很多了呢!!! 这里我要感谢一下现在的同事,我最初重构的效果并非如此,要感谢他的建议!!!呵呵。。。