侃侃复建(refactor)一

侃侃重构(refactor)一
话说距离上次发文章已经是时隔将近一个半月了，期间忙着项目所以对于文章或者说知识的总结就给忽略了！

这次我们来说说重构，说之前要感谢带领我入门的那些大哥(我曾经的同事，我喊他锋哥，还有经理 包大哥)，那个时候虽然大家都在讨论但是我作为一个菜鸟级的人物，听得不太懂不过现在做android 这一块我发现代码真是乱，所以就想到了这个东西，于是乎就做了一把refactor!

个人理解重构的概念
重构：就是在不改变现有软件的质量以及运行的情况下，对代码的整理以及对逻辑的从新梳理，已达到逻辑清晰，代码可读性好，整洁这样一个效果！
以上是我个人的理解，有误之处请大家指出来啊！无喷！

那么好了接下来说例子，因为我做的android 项目现在负责的就是xml解析数据 以及返回给 activity 数据 先来了解一下结构类图如下：

这是 原来没有重构之前的类图，需要说明的是service 和handler的子类有很多个！

下面说一下service 和 handler 里面的方法。。。

在每个service 和 handler 里面都包含有这样一个方法getXXXtBean()：Object 返回的都是 具体的类型。。。(我这到这样做不好)

下面我们重点说一下 service 里面的方法。。

代码如下：

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 来修饰的。。呵呵！！！

看重构之后的类图：



接下来看重构之后的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;
	}

、。。。这样是不是感觉。。代码清晰很多了呢！！！  这里我要感谢一下现在的同事，我最初重构的效果并非如此，要感谢他的建议！！！呵呵。。。