The Reader Monad is a Monad

#The Reader Monad is a Monad

This article about dependency injection
is concerned about the reader monad compromising separation of interface and implementation. In fact, this simply reveals the need to use Scala’s most powerful capability: higher-kinded types.

This is a general pattern: there are many other “effects” that we might want to keep track of in different implementations of an interface:

We can use all these implementations and more with the same client code, because all these things are monads:

What if
use different effect stacks? No problem, we can use
to handle both:

The end result is that we make testing very easy: our unit tests can follow the exact same code paths as live code, but without having to worry about any effects.

Our effects – dependencies via Reader, but also things like remoting, audit logging, database access or possible failures – are minimal overhead in day-to-day code (just the difference between
). But they’re not entirely invisible: we can look at the type of a function and see exactly what kind of effects it might have or depend on. If we’re using the Reader monad, that means we can see exactly what dependencies any call has, just by mousing over it in our IDE – which in turn means we can easily see when something’s not quite right (“why does logging in need the
?”). The end result is code that’s very concise, but without any “magic” or reflection: everything’s plain old code, which is the easiest kind to maintain.


稿源:No Fun Allowed (源链) | 关于 | 阅读提示

本站遵循[CC BY-NC-SA 4.0]。如您有版权、意见投诉等问题,请通过eMail联系我们处理。
酷辣虫 » 综合编程 » The Reader Monad is a Monad

喜欢 (0)or分享给?

专业 x 专注 x 聚合 x 分享 CC BY-NC-SA 4.0

使用声明 | 英豪名录