为什么不应该在scala程序中使用future单元作为返回类型

… or Future[Any] as well

…或Future [Any]也是如此

Scala is a strongly typed language but its builtin Unit and Any can match everything.

Scala是一种强类型语言,但是其内置的UnitAny可以匹配所有内容。

Normally you shouldn’t use Unit or Any as return type for a method unless it is a side-effecting method that you don’t want to test. For eg. a method that just logs something or report some metrics.

通常,除非方法是不需要测试的副作用方法,否则不应将UnitAny作为方法的返回类型。 例如。 一种仅记录某些内容或报告某些指标的方法。

A good method signature should express what it accepts and what it will return.

好的方法签名应表示接受的内容以及返回的内容。

And we should be even more careful when creating methods that has Future[Something] as its return type. It says it will return a reference to an async operation that will resolve at some point in the future with Something.

在创建以Future [Something]作为其返回类型的方法时,我们应该更加小心。 它说它将返回对异步操作的引用,该引用将在将来某个时候使用Something解决。

But as of now in Scala, without looking at the code and just by looking at the method signature, you can’t really tell

但是到目前为止,在Scala中,如果不查看代码,仅查看方法签名,就无法真正看出

1. which part of the method will run in current thread, 2. which parts are scheduled as future operation or 3. it is just a sync operation simply lifted using Future.successful(something).

1.该方法的哪一部分将在当前线程中运行; 2.哪些部分被安排为将来的操作;或3.它只是使用Future.successful(something)进行了简单的同步操作。

But the least thing we can do is enforce what the method is guaranteed to return in future by using strong sub-types like Future[Something] and avoid types like Future[Unit] or Future[Any]

但是,我们至少可以做的是通过使用诸如Future [Something]之类的强子类型并避免使用诸如Future [Unit]Future [Any]之类的类型来强制执行该方法保证将来返回的内容。

Let me show you by example

让我以身作则

Image for post

What’s the problem here?

这是什么问题

From design perspective, I’m defining a method that accepts control of a power plant and it will return anything in future!

从设计的角度来看,我正在定义一种接受发电厂控制权的方法,将来它将返回任何结果

But the business requirement is when I call this method, I expect volume to be increased. But that is not explicit in the return type!

但是业务要求是当我调用此方法时,我希望数量会增加 。 但这在返回类型中不是明确的!

That’s not right. What can go wrong? Nothing today but this code will evolve in future.

那是不对的。 有什么问题吗? 今天什么都没有,但是此代码会在将来发展。

This is the next version of the code.

这是代码的下一个版本。

Image for post

In this case, another programmer came into the project a bit late and he just blindly added the water supply code at the end when in fact it should be before increasing volume control!

在这种情况下,另一个程序员进入项目有点晚了,他只是盲目地在最后增加了供水代码,而实际上是在增加音量控制之前!

And nobody caught that and the power plant runs without cooling and goes Kaboom! Apocalypse!

而且没有人发现这一点,发电厂在没有冷却的情况下运转,然后就消失了 启示录!

But the IDE could’ve helped if only you didn’t use Future[Unit]. While defining the method, you should have explicitly said what you wanted to return! I mean something like Future[VolumeStatus]

但是,如果您不使用Future [Unit],那么IDE可能会有所帮助 在定义方法时,您应该明确地说出要返回的内容 ! 我的意思是类似Future [VolumeStatus]

Let’s first see what is the actual return type. I removed the Future[Unit] and my IDE shows Future[Future[Water]]

首先让我们看看实际的返回类型是什么。 我删除了Future [Unit],并且我的IDE显示了Future [Future [Water]]

Image for post

See the problem here? When you had Future[Unit] or Future[Any] you lose the type safety which is supposed to help you in a static language like Scala! The Unit or Any simply swallowed that error.

在这里看到问题了吗? 当您拥有Future [Unit]Future [Any]时,您会失去类型安全性,而该安全性本应该以像Scala这样的静态语言为您提供帮助! UnitAny仅吞没了该错误。

This is just one possible problem with using these types.

这只是使用这些类型的可能问题之一。

So how to solve this problem? Scala don’t have a VolumeStatus !!

那么如何解决这个问题呢? Scala没有VolumeStatus!

Well just define it yourself

好吧,你自己定义

Image for post

Now the strict type will force the implementer of the method to turn on water supply before increasing volume control. Defining strong types give you that guarantee.

现在,严格类型将迫使该方法的实现者在增加音量控制之前打开供水。 定义强类型将为您提供保证。

现在,让我们使用Future [Unit]探索另一种类型的问题 (Now let’s explore a different type of problem with using Future[Unit])

I will introduce the problem in the code but I will leave you to find out what it is.

我将在代码中介绍问题,但让您找出问题所在。

Note that the requirement is we want increaseVolumeControl() to happen strictly only after Water supply has completely turned on!

请注意,要求是我们仅在供水完全打开后才严格执行creaseVolumeControl ()

What will happen if in the following code, I use Future[Unit] as return type in WaterSupply#turnOn() method like in the following screenshot?

如果在以下代码中,我将Future [Unit]用作WaterSupply#turnOn()方法中的返回类型,如以下屏幕截图所示,将会发生什么?

Image for post

Can you identify what is the issue here?

您能在这里找出问题所在吗?

If you did, please answer in the comments and I will reply you if you got it right or not :)

如果您这样做了,请在评论中回答,如果您做对了,我会给您答复:)

Thank you for reading this :)

谢谢您阅读此篇 :)

翻译自: https://medium.com/swlh/why-shouldnt-you-use-future-unit-as-a-return-type-in-a-scala-program-a4c58f95b343

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值