重构一些遗留代码的问题
本文关键字:代码 问题 重构 | 更新日期: 2023-09-27 18:03:31
所以我试图重构这个具有许多不同职责的SomeClass
。上面所示的方法似乎是开始精简这个类的好地方,所以我考虑将它放在一个特定于IO的类中(并且在需要时很容易允许mock)。
class SomeClass{
...
public void m() {
...
emptyDirectory(something);
...
}
private void emptyDirectory(File dir) {
File[] dirContent = dir.listFiles();
if (dirContent != null)
for (File f : dirContent) {
if (f.isDirectory())
emptyDirectory(f);
try {
if (!f.delete()) {
IOError problem = new IOError(symbolTable.getRefinement().getFileName(),
f.toString(), f.isDirectory());
problemManager.add(problem);
}
} catch (SecurityException e) {
IOError problem = new IOError(symbolTable.getRefinement().getFileName(),
f.toString(), f.isDirectory());
problemManager.add(problem);
}
}
}
}
}
问题是我们的系统有一个错误记录机制,就像编译器的一样(它会报告错误,但一切都应该继续工作)。当你尝试编译一个程序时,它不会在第一次遇到错误时停止编译过程。
我想让我的IO类不知道这个错误报告的事情,所以我的想法是从IO方法抛出异常,然后让m()
捕获它并做其余的错误处理。问题是IOException
和SecurityException
都不会告诉我文件的名称是什么。
我知道我可以创建自己的异常,但是如果我开始为这么简单的事情创建自己的异常,我将不得不为我的其余代码创建数百个异常,也!
我想让重构尽可能的简单。
你如何处理重构?
显然,首先要做的是设计和实现错误处理,允许非致命错误记录。
我建议创建一个包含遇到的错误列表的类(就像编译器一样)。当I/O遇到问题时,它传递给错误类,错误类将其弹出到错误列表中,并返回进行进一步处理。
通过这种方式,您将不必在任何给定的点上从抛出错误中恢复——每个可以生成错误的地方都负责处理它或将其交给错误记录器存储并稍后处理。
有了这个错误记录器,重构应该是轻而易举的。我会检查以下几点。
-
单一职责
-
不要从方法返回null;返回空对象/集合
-
保持方法简单和小
-
不要在方法签名中传递超过2-3个参数
-
只对调用者抛出异常;如果对它有意义的话。
重构并不意味着只从大方法创建小方法,我们需要检查这些事情。还有更多取决于我们的设计结构。