python zio_组成猫，电抗器，ZIO，…效果

本文主要是介绍python zio_组成猫，电抗器，ZIO，…效果，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

python zio

这是系列文章中的第三篇，介绍了用于反转控制以提供合成的类型系统。

先前的文章涵盖：

一流的程序类型系统
一流的模块

本文将探讨将理论付诸实践。它将使用这些概念来构建一个由各种效果库组成的应用程序。

注意，使用的效果特意保持简单，以专注于效果的组成。这主要是因为本文不是要比较库。本文是由它们组成的。我们展示了如何使用耦合控制倒置技术在一个简单的应用程序中将它们无缝地组合在一起。而且，讨论库的顺序仅是字母顺序。

为了简单起见，其效果是从数据库中检索一条消息。

猫

让我们从Cats Effect开始。

 def cats(request: ServerRequest)(implicit repository: MessageRepository): IO[ServerResponse] = for { message <- catsGetMessage(request.getId) response = new ServerResponse(s "${message.getContent} via Cats" ) } yield response def catsGetMessage(id: Int)(implicit repository: MessageRepository): IO[Message] = IO.apply(repository findById id orElseThrow)

catsGetMessage函数将存储库中的检索消息效果包装在IO中。然后可以将其用于服务请求以提供响应（根据cats函数）。

对于单个存储库依赖项，使用隐式可能是过大的。但是，它显示了依赖项注入如何能够从服务逻辑中消除依赖项混乱。当依赖项数量增加时，这尤其有用。

React堆

React堆具有以下维修逻辑。

 def reactor(request: ServerRequest)(implicit repository: MessageRepository): Mono[ServerResponse] = reactorGetMessage(request.getId).map(message => new ServerResponse(s "${message.getContent} via Reactor" )) def reactorGetMessage(id: Int)(implicit repository: MessageRepository): Mono[Message] = Mono.fromCallable(() => repository.findById(id).orElseThrow())

再次，有一个ReactorGetMessage函数将检索到的消息效果包装到Mono中。然后用于服务请求。

ZIO

对于ZIO ，逻辑略有不同，因为ZIO提供了它自己的依赖项注入。

 def zio(request: ServerRequest, repository: MessageRepository): ZIO[Any, Throwable, ServerResponse] = { // Service logic val response = for { message <- zioGetMessage(request.getId) response = new ServerResponse(s "${message.getContent} via ZIO" ) } yield response // Provide dependencies response.provide( new InjectMessageRepository { override val messageRepository = repository }) } def zioGetMessage(id: Int): ZIO[InjectMessageRepository, Throwable, Message] = ZIO.accessM(env => ZIO.effect(env.messageRepository.findById(id).orElseThrow())) trait InjectMessageRepository { val messageRepository: MessageRepository }

zioGetMessage再次将检索数据库消息效果包装在ZIO中。但是，它提取注入的特征以检索存储库。

封装到模块中

上面的功能（猫，React堆，齐奥）被配置为以下模块中的一流程序。

该模块的输出为响应，输入为Cats，Reactor，ZIO和Imperative。

由于对一流过程的评估是懒惰的，因此它们也可以包装包含效果的命令性代码。命令功能如下。

 def imperative(request: ServerRequest, repository: MessageRepository): ServerResponse = { val message = repository.findById(request.getId).orElseThrow() new ServerResponse(s "${message.getContent} via Imperative" ) }

使用模块

以下配置使用该模块为REST请求提供服务。它被配置为同步模块。

这表明将模块配置为服务请求是多么容易。

进一步有趣的是，异步模块具有与同步模块相同的输入/输出接口。现在，这很可能是上述模块的重用（只是名称不正确）。但是，事实并非如此。异步模块采用相同的逻辑，只是异步的（演示项目中可用的代码）。

对于模块而言，重要的是输入和输出的合同接口。我们可以很高兴地在配置中交换Synchronous / Asynchronous模块，该应用程序仍将继续工作。这允许封装复杂性。

一个更真实的例子是，我们可以以更快的编写速度和更容易的调试同步效果开始。然后，随着应用程序规模的增长，我们可能决定交换异步模块以更好地处理规模。将“同步”模块交换为“异步”模块的重构量为：

插入新的异步模块
重新连接流到异步模块
删除同步模块

由于耦合控制的反转消除了功能耦合，因此除了提供新模块的实现外，没有其他代码可更改。

使用能够包含模块的模块，这提供了一种封装应用程序复杂性的方法，以便于理解。这也使导入模块变得简单。将它们放入并连接起来。当第三方模块库可用于准备使用的功能时，此功能尤其有用。

构图效果

这演示了本系列以前文章的First-Class Procedures和First-Class Modules。

嘿，但是本文承诺了合成效果！

好吧，我可以告诉您发送是一种效果，在上述效果之后构成此效果就是这种合成。但是，这需要我多说。

因此，服务器配置中的最后一个模块如下。

该模块由每个库组成一个效果。每种效果的代码如下。

 def seed: String = "Hi" def cats( @Parameter param: String): IO[String] = IO.pure(s "$param, via Cats" ) def reactor( @Parameter param: String): Mono[String] = Mono.just(s "$param, via Reactor" ) def zio( @Parameter param: String): ZIO[Any, Nothing, String] = ZIO.succeed(s "$param, via ZIO" ) def imperative( @Parameter param: String): String = s "$param, via Imperative" def response( @Parameter message: String): ServerResponse = new ServerResponse(message)

每个效果只接受前一个的输入，并附加其库名称。结果响应是一个包含所有效果库名称的字符串。

没有适配器

精明的读者可能会认为，在OfficeFloor的支持下，库之间可能有一些很棒的适配器。嗯，我们可以提取它们并加以利用吗？

令人遗憾的是，对于这个问题，很高兴在库之间没有适配器。实际发生的情况是，每个“一流程序”都会不安全地执行其效果并检索结果输出。然后使用输出OfficeFloor调用下一个First-Class Procedure。这样，我们就不需要彼此适应这些库。我们可以隔离地运行每个效果，并通过它们的输入/输出接口它们。

这使得新效果库的集成非常简单。只需编写一次适配器，即可将库的效果封装在First-Class Procedure中。这样，效果库便可以与所有其他效果库集成。由于一流程序实际上是专门的一流模块，因此这证明了耦合控制倒置的组合功能。