代码可重用性:如何重构检查以使其更具可读性和可重用性，分离责任

本文关键字：可读性 分离 责任 何重构 检查 代码 重构 | 更新日期: 2023-09-27 18:00:14

考虑以下检查。在我的解决方案中，我可以找到10次相同的错误检查。

if (request == null)
 throw GetFaultException("Request object is null");

现在考虑下一个：

if (model == null)
 throw GetFaultException("Request model not well formed");

唯一改变的是错误消息和被检查变量的名称。

重构的一部分已经完成，因为GetFaultException已经隐藏了复杂性并分离了责任。

我看到了许多可能的进一步重构。比如使用Monads、AOP、events（？）。

我认为真正真正最好的解决方案是让代码像MVC模型一样思考。

因此如果（条件）请求==null<kbd]，则（意味着）>未指定强制参数，则（代表着）需要特定消息的异常

我在这种方法中看到的好处是，过程化编程使代码变得不可使用和不可察觉。相反，如果我提出一个NullMandatoryParameterEvent，那么就非常清楚了为什么我要检查一个变量是否为null，以及如果它为null该怎么办。

问题是：你将如何重构这种Check（根据我定义的目标）？你们有共同的目标吗？

代码可重用性:如何重构检查以使其更具可读性和可重用性，分离责任

如果验证的属性为null，我认为您的程序将无法继续。因此，我会坚持使用异常——这正是ArgumentNullException的发明初衷。您可以声明为null的参数，并通过该参数清楚地传达调用者应该修复的内容，以使代码运行。事件不是异常的替代方案，因为调用方可能会也可能不会处理它们。

在我的项目中，我还试图通过将验证逻辑放在一个位置来优化代码布局。在较小的项目中，通过创建一些辅助方法，如AssertIsNotNull，将参数和名称作为输入，以便它可以构造和抛出ArgumentNullException。

在我的上一个项目中，我创建了一个特定的ValidationService，并使用AOP将逻辑放置到位。我还使用了位于系统中的属性。组件模型。DataAnnotations命名空间，以声明除了输入参数不为null之外还应验证的规则。MVC使用相同的属性在客户端（通过JavaScript）和服务器上验证模型。

您可能考虑的另一种方法是使用代码契约。尽管您仍然需要在每个方法中定义先决条件，但您可以使用静态代码分析来查找违反合同的地方。您还可以配置检查完成的时间。例如，您可以在测试时运行所有检查，并出于性能原因跳过生产环境的某些测试。有关概述，请参阅此链接。

相关文章：