Don't Parse, Use Parsing Objects

The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:

传统的将面向对象的后端与外部系统集成的方式是通过数据传输对象,这些对象在发送前被序列化为JSON,在返回时进行反序列化。这种方式一直很受欢迎,但其实是错误的。序列化部分应该由我之前解释过的打印机来代替。下面是我对反序列化的看法,应该由—猜猜看—对象来完成。

假设有一个后端入口点,该入口点应该注册一个新书到图书馆,以JSON格式到达:

此外,还有一个类Library的对象,它期望将一个类型为Book的对象传递给它的方法register()

还有一点,类型为 Book 的对象有一个简单的方法 isbn()

现在,这是HTTP入口点(我使用的是Takes和Cactoos),它接受一个POST multipart/form-data 请求,并在图书馆注册图书。

这个有什么问题呢?有几个问题。

首先,它不可重用。如果我们需要在不同的地方使用类似的东西,我们将不得不再次编写这个HTTP处理和JSON解析。

其次,错误处理和验证也不可重用。如果我们将它添加到上述方法中,我们将不得不到处复制它。当然,DTO可能会封装它,但这不是DTO通常的用途。

第三,上述代码是相当过程化的,并且具有很多时间耦合。

更好的设计是将此解析隐藏在一个名为JsonBook的新类中:

然后,RESTful入口将如下所示:

这样不是更优雅吗?

以下是我项目中的一些示例:RqUser来自zerocracy/farm,以及RqUser来自yegor256/jare

从上面的示例中可以看出,有时我们无法使用implements,因为Java中的某些基本类型不是接口,而是final类,例如String就是一个”完美”的例子。这就是为什么我不得不这样做的原因:

但除此之外,这些例子完美地展示了上面提到的“解析对象”的原则。

Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-28 at 14:49

sixnines availability badge   GitHub stars