我有一个类,它有一个调用很多私有方法的大方法。我想我想将这些私有方法提取到自己的类中,因为它们包含业务逻辑,我认为它们应该是公共的,因此它们可以进行单元测试。
以下是代码示例:
public void handleRow(Object arg0) {
if (continueRunning){
hashData=(HashMap<String, Object>)arg0;
Long stdReportId = null;
Date effDate=null;
if (stdReportIds!=null){
stdReportId = stdReportIds[index];
}
if (effDates!=null){
effDate = effDates[index];
}
initAndPutPriceBrackets(hashData, stdReportId, effDate);
putBrand(hashData,stdReportId,formHandlerFor==0?true:useLiveForFirst);
putMultiLangDescriptions(hashData,stdReportId);
index++;
if (stdReportIds!=null && stdReportIds[0].equals(stdReportIds[1])){
continueRunning=false;
}
if (formHandlerFor==REPORTS){
putBeginDate(hashData,effDate,custId);
}
//handle logic that is related to pricemaps.
lstOfData.add(hashData);
}
}
我应该采用什么样的设计模式来解决这个问题?
答案 0 :(得分:2)
答案 1 :(得分:1)
我只是将相关方法和状态(字段)捆绑到具有公共方法的类中,并将它们作为服务注入到宿主类中。
像Doug发布的状态模式描述了这样的划分。
分割行为时,请务必避免循环依赖。当匆忙完成时,这很容易发生。
通常将类行为拆分为多个类以供重用和自定义。如果唯一的目的是提高可测试性,那么将方法暴露为受保护或公开是一种更容易的选择。
答案 2 :(得分:0)
您可以通过使方法“受保护”并将测试类放在与原始源代码相同的包中来解决您对单元测试的担忧。
答案 3 :(得分:0)
你描述仅仅是为了适应你的单元测试工具的戏剧性重构是一个非常非常糟糕的主意。
不要让工具中的缺陷来驱动您的设计。