Scalaz(22)- 泛函编程思维: Coerce Monadic Thinking
马上进入新的一年2016了,来点轻松点的内容吧。前面写过一篇关于用Reader实现依赖注入管理的博文(Scalaz(16)- Monad:依赖注入-Dependency Injection By Reader Monad)。刚好年底这几天抽空重审了一遍,这时才真正认识到让一个老资格OOP程序猿去编写一段FP程序时会发生什么事情:他会用FP语法和数据类型按照OOP的思维编写程序。其结果就是一段尴尬的代码,让人看得不知怎么去形容,更不用提FP程序的精简高雅了。我在前面博文的示范程序正是落入了这个OOP思维陷阱。
我们先把源代码搬过来看看:
package Exercises
import scalaz._
import Scalaz._
object reader3 {
trait OnOffDevice {
def on: String
def off: String
}
trait SensorDevice {
def isCoffeePresent: Boolean
}
trait PowerConfig {
def getPowerVolts(country: String): Int
def isUSStandard(volt: Int): Boolean
} trait OnOffComponent {
def onOffDevice: OnOffDevice
}
trait SensorComponent {
def sensorDevice: SensorDevice
}
trait Device extends OnOffComponent with SensorComponent
trait DeviceComponent {
def onOffDevice: OnOffDevice
def sensorDevice: SensorDevice
}
trait PowerComponent {
def powerConfig: PowerConfig
}
trait Appliance extends DeviceComponent with PowerComponent
object Appliance {
val appliance = Reader[Appliance,Appliance](identity)
val onOffDevice = appliance map {_.onOffDevice}
val sensorDevice = appliance map {_.sensorDevice}
val powerConfig = appliance map {_.powerConfig}
}
object OnOffDevice {
import Appliance.onOffDevice
def on: Reader[Appliance,String] = onOffDevice map { _.on }
def off: Reader[Appliance,String] = onOffDevice map { _.off }
}
object SensorDevice {
import Appliance.sensorDevice
def isCoffeePresent: Reader[Appliance,Boolean] = sensorDevice map { _.isCoffeePresent }
}
object PowerConfig {
import Appliance.powerConfig
def getPowerVolts(country: String) = powerConfig map {_.getPowerVolts(country)}
def isUSStandard(volts: Int) = powerConfig map {_.isUSStandard(volts)}
}
object OnOffService {
def on = for {
ison <- OnOffDevice.on
} yield ison
def off = for {
isoff <- OnOffDevice.off
} yield isoff
}
object SensorService {
def isCoffeePresent = for {
hasCoffee <- SensorDevice.isCoffeePresent
} yield hasCoffee
}
object PowerService {
def isUSStandard(country: String) = for {
is110v <- PowerConfig.getPowerVolts(country)
isUSS <- PowerConfig.isUSStandard(is110v)
} yield isUSS
}
class OnOffDeviceImpl extends OnOffDevice {
def on = "SomeDevice.On"
def off = "SomeDevice.Off"
}
class SensorDeviceImpl extends SensorDevice {
def isCoffeePresent = true
}
class PowerConfigImpl extends PowerConfig {
def getPowerVolts(country: String) = country match {
case "USA" =>
case "UK" =>
case "HK" =>
case "CHN" =>
case _ =>
}
def isUSStandard(volts: Int) = volts ===
}
object MockOnOffDevice extends OnOffDeviceImpl
object MockSensorDevice extends SensorDeviceImpl
object MockPowerConfig extends PowerConfigImpl
trait OnOffFunctions extends OnOffComponent {
def onOffDevice = MockOnOffDevice
}
trait SensorFunctions extends SensorComponent {
def sensorDevice = MockSensorDevice
}
trait DeviceFunctions extends DeviceComponent {
def onOffDevice = MockOnOffDevice
def sensorDevice = MockSensorDevice
}
trait PowerFunctions extends PowerComponent {
def powerConfig = MockPowerConfig
}
object MockAppliance extends Appliance with DeviceFunctions with PowerFunctions
def trigger =
if ((PowerService.isUSStandard("CHN")(MockAppliance))
&& (SensorService.isCoffeePresent(MockAppliance)))
OnOffService.on(MockAppliance)
else
OnOffService.off(MockAppliance) //> trigger: => scalaz.Id.Id[String]
trigger //> res0: scalaz.Id.Id[String] = SomeDevice.On
}
这段代码前面用trait进行了功能需求描述,接着用Reader定义依赖,再接着通过Reader组合实现了依赖的层级式管理,直到形成最终的Reader组合:
object MockAppliance extends Appliance with DeviceFunctions with PowerFunctions
这些都没什么问题,也体现了函数式编程风格。问题就出在这个trigger函数定义里,我们来看看:
def trigger =
if ((PowerService.isUSStandard("CHN")(MockAppliance))
&& (SensorService.isCoffeePresent(MockAppliance)))
OnOffService.on(MockAppliance)
else
OnOffService.off(MockAppliance) //> trigger: => scalaz.Id.Id[String]
首先感觉代码很乱;每句都有个MockAppliance很笨拙(clumsy),感觉不到任何优雅的风格,也看不出与常用的OOP编程有什么分别。
回忆下当时是怎么想的呢?trigger的要求是:如果电源是US标准并且壶里能检测到有咖啡,那么就可以启动加热器,否则关停。
已经完成了电源标准和咖啡壶内容检测即加热器开关的组件(combinators)。都是细化了的独立功能函数,这点符合了函数式编程的基本要求。
当时的思路是这样的:
1、获取当前电源制式,判断是否US标准
2、获取咖啡壶检测数据,判断是否盛载咖啡
3、if 1 and 2 then OnoffService.on else OnOffService.off
但是为了获取1和2的Boolean结果就必须注入依赖:MockAppliance,所以在trigger函数定义里进行了依赖注入。现在看来这就是典型的OOP思想方式。
首先我们再次回想一下函数式编程的一些最基本要求:
1、纯代码(pure code):实现函数组合-这点在前面的功能函数组件编程中已经做到
2、无副作用(no-side-effect):尽量把副作用推到程序最外层,拖延到最后-trigger使用了依赖MockAppliance,产生了副作用
3、我经常提醒自己Monadic Programming就是F[A]:A是我们要运算的值,我们需要在一个壳子内(context)对A进行运算。
看看这个版本的trigger:因为直接获取了isUSStandard和isCoffeePresent的Boolean运算值所以需要立即注入依赖。首先的后果是trigger现在是有副作用的了。再者trigger和MockAppliance紧紧绑到了一起(tight coupling)- 如果我们再有个Reader组合,比如什么DeployAppliance的,那我们必须再搞另一个版本的trigger了。即使我们通过输入参数传入这个Reader组合依赖也会破坏了函数的可组合性(composibility),影响函数组件的重复利用。看来还是按照上面的要求把这个trigger重新编写:
object MockAppliance extends Appliance with DeviceFunctions with PowerFunctions
def trigger(cntry: String) = for {
isUS <- PowerService.isUSStandard(cntry)
hasCoffee <- SensorService.isCoffeePresent
onoff <- if (isUS && hasCoffee) OnOffService.on else OnOffService.off
} yield onoff //> trigger: (cntry: String)scalaz.Kleisli[scalaz.Id.Id,Exercises.Exercises.rea
//| derDI.Appliance,String]
trigger("CHN")(MockAppliance) //> res0: scalaz.Id.Id[String] = SomeDevice.On
trigger("HK")(MockAppliance) //> res1: scalaz.Id.Id[String] = SomeDevice.Off
现在这个版本的trigger是一段纯代码,并且是在for-comprehension内运算的,与依赖实现了松散耦合。假如这时再有另一个版本的依赖组合DeployAppliance,我们只需要改变trigger的注入依赖:
trigger("CHN")(DeployAppliance) //> res0: scalaz.Id.Id[String] = CoffeeMachine.On
trigger("HK")(DeployAppliance) //> res1: scalaz.Id.Id[String] = CoffeeMachine.Off
怎么样?这样看起来是不是简明高雅许多了?
噢,祝大家新年快乐!
Scalaz(22)- 泛函编程思维: Coerce Monadic Thinking的更多相关文章
- 泛函编程(27)-泛函编程模式-Monad Transformer
经过了一段时间的学习,我们了解了一系列泛函数据类型.我们知道,在所有编程语言中,数据类型是支持软件编程的基础.同样,泛函数据类型Foldable,Monoid,Functor,Applicative, ...
- 泛函编程(24)-泛函数据类型-Monad, monadic programming
在上一节我们介绍了Monad.我们知道Monad是一个高度概括的抽象模型.好像创造Monad的目的是为了抽取各种数据类型的共性组件函数汇集成一套组件库从而避免重复编码.这些能对什么是Monad提供一个 ...
- 泛函编程(38)-泛函Stream IO:IO Process in action
在前面的几节讨论里我们终于得出了一个概括又通用的IO Process类型Process[F[_],O].这个类型同时可以代表数据源(Source)和数据终端(Sink).在这节讨论里我们将针对Proc ...
- 泛函编程(34)-泛函变量:处理状态转变-ST Monad
泛函编程的核心模式就是函数组合(compositionality).实现函数组合的必要条件之一就是参与组合的各方程序都必须是纯代码的(pure code).所谓纯代码就是程序中的所有表达式都必须是Re ...
- 泛函编程(32)-泛函IO:IO Monad
由于泛函编程非常重视函数组合(function composition),任何带有副作用(side effect)的函数都无法实现函数组合,所以必须把包含外界影响(effectful)副作用不纯代码( ...
- 泛函编程(29)-泛函实用结构:Trampoline-不再怕StackOverflow
泛函编程方式其中一个特点就是普遍地使用递归算法,而且有些地方还无法避免使用递归算法.比如说flatMap就是一种推进式的递归算法,没了它就无法使用for-comprehension,那么泛函编程也就无 ...
- 泛函编程(25)-泛函数据类型-Monad-Applicative
上两期我们讨论了Monad.我们说Monad是个最有概括性(抽象性)的泛函数据类型,它可以覆盖绝大多数数据类型.任何数据类型只要能实现flatMap+unit这组Monad最基本组件函数就可以变成Mo ...
- 怎样学习Scala泛函编程
确切来说应该是我打算怎么去学习Scala泛函编程.在网上找不到系统化完整的Scala泛函编程学习资料,只好把能找到的一些书籍.博客.演讲稿.论坛问答.技术说明等组织一下,希望能达到学习目的.关于Sca ...
- scala泛函编程是怎样被选中的
现在计算机技术发展现象是:无论硬件技术如何发展都满足不了软件需求:无论处理器变得能跑多快,都无法满足软件对计算能力的需要.按照摩尔定律(Moore's Law)处理器(CPU)每平方面积上包含的半导体 ...
随机推荐
- MySQL(二) 数据库数据类型详解
序言 今天去健身了,感觉把身体练好还是不错的,闲话不多说,把这个数据库所遇到的数据类型今天统统在这里讲清楚了,以后在看到什么数据类型,咱度应该认识,对我来说,最不熟悉的应该就是时间类型这块了.但是通过 ...
- JavaScript与有限状态机
有限状态机(Finite-state machine)是一个非常有用的模型,可以模拟世界上大部分事物. 简单说,它有三个特征: * 状态总数(state)是有限的. * 任一时刻,只处在一种状态之中. ...
- Web Workers 的基本信息
问题:JavaScript 并行性 要将有趣的应用(例如从侧重服务器端的实施)移植到客户端 JavaScript,存在很多制约瓶颈.其中包括浏览器兼容性.静态类型.可访问性和性能.幸运的是,随着浏览器 ...
- Parametric Curves and Surfaces
Parametric Curves and Surfaces eryar@163.com Abstract. This paper is concerned with parametric curve ...
- 编译原理LL1文法分析表算法实现
import hjzgg.first.First; import hjzgg.follow.Follow; import hjzgg.tablenode.TableNode; import hjzgg ...
- Ext.Net全部Icon图标名称展示
- Yii的学习(1)--安装配置
之前在sina博客写过Yii的文章,来到博客园之后,没再写过关于Yii的文章,正好端午假期没啥事,就结合以前的博客,Yii的官方文档,再加上最近的关于Yii的收获总结一下,写个系列~~ Yii是一个基 ...
- 如何用UE(UltraEdit)删除重复行?--转
原文地址:https://www.zhengjie.com/question/bb148773 使用UE(UltraEdit)的高级排序功能就可以删除掉所有的重复行. 操作步骤 1.文件—排序(R)— ...
- JavaScript面向对象程序设计:数组
或许你会奇怪,面向对象的程序设计为什么从数组开始讲起?这是因为……其间的种种关系吧……嘿嘿,这里先卖个关子,先来看看我们熟悉的数组在JavaScript里面是什么样子的. 1. 创建数组 在J ...
- CSS SANS – 神奇!使用 CSS3 创建的字体
在我们的认识中,CSS 所能做的就是改变网页的排版布局,调整字间距等.然而,这里我们要介绍的则是使用 CSS3 制作字体.CSS SANS 可以通过 CSS 技术创建的A-Z字体,一起来围观下. 在线 ...