侃侃复建(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();//这个地方要注意了。。。。记得调用啊。。}@Overrideprotected String loadUrl() {return URLRequest.CHECKOUT.getUrl()+"playlistid="+ playlistId + "&pid="+ pID;}@Overrideprotected 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方法即可。。

@Overrideprotected boolean callBack() {return true;}

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

查看更多 下一篇