Scala中的设计模式

Scala算是一门博采众家之长的语言，兼具OO与FP的特性，若使用恰当，可以更好地将OO与FP的各自优势发挥到极致；然而问题也随之而来，倘若过分地夸大OO特性，Scala就变成了一门精简版的Java，写出的是没有Scala Style的拙劣代码；倘若过分追求FP的不变性等特性，因为Scala在类型系统以及Monad实现的繁琐性，又可能导致代码变得复杂，不易阅读，反而得不偿失。

看来，赋予程序员选择的自由，有时候未必是好事！

在OO世界里，设计模式曾经风靡全世界，你不懂设计模式，都不好意思说自己是程序员。现在呢？说你懂设计模式，倒显得你逼格低了，心里鄙视：“这年头谁还用设计模式，早过时了！”程序员心中的鄙视链开始加成，直接失血二十格。

其实什么事情都得辩证来看！设计模式对OO设计的推进作用不容忽视，更不容轻视。我只是反对那种为了“模式”而“模式”的僵化思想，如果没有明白设计模式的本质思想，了解根本的设计原理，设计模式无非就是花拳绣腿罢了。当然，在FP世界里，设计模式开始变味开始走形，但诸多模式的本质，例如封装、抽象，仍然贯穿其中，不过是表达形式迥然而已罢了。

在混合了OO与FP的Scala语言中，我们来观察设计模式的实现，会非常有趣。Pavel Fatin有篇博客 Design Patterns in Scala 将Java设计模式与Scala进行了对比，值得一读。我这里想借用他的案例，而从另一个角度去俯瞰设计模式。

在Pavel Fatin比较的设计模式中，部分模式在Scala中不过是一种语法糖（Syntax Sugar），包括：

• Factory Method
• Lazy Initialization
• Singleton
• Adapter
• Value Object

文中给出的Factory Method模式，准确地说其实是静态工厂模式，它并不在GOF 23种模式之列，但作为对复杂创建逻辑的一种封装，常常被开发人员使用。站在OCP（开放封闭原则）的角度讲，该模式或许对扩展不是开放的，但对于修改而言，却是封闭的。如果创建逻辑发生了变化，可以保证仅修改该静态工厂方法一处。同时，该模式还可以极大地简化对象创建的API。