… or Future[Any] as well
…或Future [Any]也是如此
Scala is a strongly typed language but its builtin Unit and Any can match everything.
Scala是一种强类型语言,但是其内置的Unit和Any可以匹配所有内容。
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.
通常,除非方法是不需要测试的副作用方法,否则不应将Unit或Any作为方法的返回类型。 例如。 一种仅记录某些内容或报告某些指标的方法。
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](https://i-blog.csdnimg.cn/blog_migrate/86cde390e6e78f81ca409f77d888edf3.png)
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](https://i-blog.csdnimg.cn/blog_migrate/f91b325d265412b5a3d65059bd3cd558.png)
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](https://i-blog.csdnimg.cn/blog_migrate/23b3cab65c80350fade6328f922d7a27.png)
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这样的静态语言为您提供帮助! Unit或Any仅吞没了该错误。
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](https://i-blog.csdnimg.cn/blog_migrate/3e3d687aaa65b6f4cc8e4566127d379d.png)
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](https://i-blog.csdnimg.cn/blog_migrate/f6a89c5c668727f375bc6504b82daa8d.png)
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 :)
谢谢您阅读此篇 :)