如何最好地管理需要复杂验证逻辑的对象图的构造？我想保留依赖注入,无可否认的构造函数的可测性原因.
可测性对我来说非常重要,你建议如何维护代码的这个属性？
背景
我有一个简单的java对象,它管理一些业务数据的结构：
class Pojo
{
protected final String p;
public Pojo(String p) {
this.p = p;
}
}
我想确保p是有效的格式,因为没有这种保证,这个业务对象真的没有意义;如果p是废话,它不应该被创建.然而,验证p是不平凡的.
抓住
真的需要复杂的验证逻辑,逻辑应该是完全可以测试的,所以我有一个单独的类中的逻辑：
final class BusinessLogic() implements Validator<String>
{
public String validate(String p) throws InvalidFoo,InvalidBar {
...
}
}
可能重复的问题
> Where Should Validation Logic Be Implemented? – 接受的答案对我来说是不可穿透的.我读到“在类的本地环境中运行”作为重言式,验证规则如何运行在除了“本地环境”之外的其他任何内容中？点2我没有想到,所以我不能评论.
> Where To Provide Logic Rules for Validation? – 两个答案都表明我的客户/数据提供者的责任原则上是我所喜欢的.但是,在我的情况下,客户端可能不是数据的发起者,无法验证.
> Where To Keep Validation Logic? – 建议的验证可以由模型所有,但是我发现这种方法不太适合测试.具体来说,对于每个单元测试,即使我正在测试模型的其他部分,我也需要关心所有的验证逻辑 – 我无法通过遵循建议的方法完全隔离我想要测试的内容.
我的想法到目前为止
虽然以下构造函数公开地声明了Pojo的依赖关系,并保留了它的简单可测性,但它是完全不安全的.这里没有什么可以防止客户端提供验证器,声称每个输入都是可以接受的！
public Pojo(Validator businessLogic,String p) throws InvalidFoo,InvalidBar {
this.p = businessLogic.validate(p);
}
所以,我限制构造函数的可视性,我提供一个工厂方法,确保验证然后构造：
@VisibleForTesting
Pojo(String p) {
this.p = p;
}
public static Pojo createPojo(String p) throws InvalidFoo,InvalidBar {
Validator businessLogic = new BusinessLogic();
businessLogic.validate(p);
return new Pojo(p);
}
现在我可以将createPojo重构为一个工厂类,这将恢复Pojo的“单一责任”,并简化了工厂逻辑的测试,更不用说在每个新Pojo上不再浪费创建新的(无状态)BusinessLogic的性能优势.
我的直觉是我应该停下来,要求外界的意见.我在正确的轨道上吗？
解决方法
让我知道是否有意义/回答你的问题.
简介：我认为您的系统可以是一个简单的库,一个多层次的应用程序或一个复杂的分布式系统,实际上并没有太多的区别,当涉及到验证：
>客户端：远程客户端(例如HTTP客户端)或只是另一个类调用您的库.
>服务：一个远程服务(例如REST服务)或者你暴露的API.
在哪里验证？
您通常要验证输入参数：
>在客户端,在将参数传递给服务之前,确保早期对象将有效下来.如果是远程服务,或者在生成参数和创建对象之间存在复杂的流程,则这是特别需要的.
>在服务端：
>在类级别,在您的构造函数中,以确保您创建有效的对象;
>在子系统级别,即管理这些对象的层(例如,DAL持久化您的Pojos);
>在您的服务的边界,例如您的库或您的控制器的facade或外部API(如MVC中,例如REST端点,Spring控制器等).
如何验证？
假设以上,因为您可能必须在多个地方重用您的验证逻辑,所以在utility class中提取它可能是个好主意.这样：
>你不要复制它(DRY！);
您确定系统的每一层都将以相同的方式进行验证;
>你可以轻松地单独测试这个逻辑(因为它是无状态的).
更具体地说,您至少会在构造函数中调用此逻辑,以强制对象的有效性(考虑将有效的依赖关系作为Pojo方法中的算法的先决条件)：
实用类：
public final class Pojovalidator() {
private Pojovalidator() {
// Pure utility class,do NOT instantiate.
}
public static String validateFoo(final String foo) {
// Validate the provided foo here.
// Validation logic can throw:
// - checked exceptions if you can/want to recover from an invalid foo,// - unchecked exceptions if you consider these as runtime exceptions and can't really recover (less clutering of your API).
return foo;
}
public static Bar validateBar(final Bar bar) {
// Same as above...
// Can itself call other validators.
return bar;
}
}
Pojo类：
请注意静态import语句以提高可读性.
import static Pojovalidator.validateFoo;
import static Pojovalidator.validateBar;
class Pojo {
private final String foo;
private final Bar bar;
public Pojo(final String foo,final Bar bar) {
validateFoo(foo);
validateBar(bar);
this.foo = foo;
this.bar = bar;
}
}
如何测试我的Pojo？
>您应该添加创建单元测试,以确保在构建时调用验证逻辑(以避免回归,因为人们可以通过删除X,Y,Z原因的此验证逻辑“稍后”简化“构造函数).
>如果它们很简单,可以内联创建依赖项,因为它使您的测试更易于阅读,因为您使用的所有内容都是本地的(较少的滚动,较小的心理尺度等)
>但是,如果您的Pojo依赖关系的设置复杂/冗长,以至于测试不再可读,则可以在@Before / setUp方法中考虑该设置,以便单元测试测试Pojo的逻辑真的专注于验证你的Pojo行为.
无论如何,我同意Jeff Storey：
>用有效参数编写测试,
>没有验证的构造函数只是为了您的测试.当您混合生产和测试代码时,它确实是一种代码气味,并且肯定会被某些人无意中使用,包括您的服务的稳定性.
最后,将您的测试视为代码示例,示例或可执行规范：您不想通过以下方式给出令人困惑的示例：
>注入无效参数;
>注入验证器,这将使您的API混乱/读取“奇怪”.
如果Pojo需要非常复杂的依赖关系呢？
[如果是这种情况,请告诉我们]
生产代码：
您可以尝试在工厂中隐藏这种复杂性.
测试代码：
或者：
>如上所述,以不同的方法考虑这一点;要么
>使用你的工厂;要么
>使用模拟参数,并配置它们,以便它们验证您的测试通过的要求.
编辑：关于安全性方面的输入验证的几个链接,这也可以是有用的：
> OWASP’s Input Validation Cheat Sheet
> OWASP’s wikipage about Data Validation