转载

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" => 110         case "UK" => 220         case "HK" => 220         case "CHN" => 110         case _  => 0     }     def isUSStandard(volts: Int) = volts === 110 } 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

怎么样？这样看起来是不是简明高雅许多了？

噢，祝大家新年快乐！

正文到此结束