最近我阅读了以下的 SO 问题：
是否存在在 Scala 中使用访问者模式的用例？如果我在 Java 中会使用访问者模式，那么我在 Scala 中应该每次都使用模式匹配吗？
这是问题的链接：Scala 中的访问者模式，被接受的答案开始说：
是的，你可能应该首先使用模式匹配而不是访问者模式。参见这里http://www.artima.com/scalazine/articles/pattern_matching.html
我的问题（受上述问题启发）是哪些 GOF 设计模式在 Scala 中有完全不同的实现？如果我在 Scala 中编程，应该注意什么，不要遵循基于 Java 的设计模式（Gang of Four）的编程模型？
创建型模式
结构型模式
行为型模式
Scala可以通过泛型类型更优雅地实现此功能，而Java则无法做到，但总体思路相同。在Scala中，该模式最简单的实现方式如下：
trait Status
trait Done extends Status
trait Need extends Status
case class Built(a: Int, b: String) {}
class Builder[A <: Status, B <: Status] private () {
private var built = Built(0,"")
def setA(a0: Int) = { built = built.copy(a = a0); this.asInstanceOf[Builder[Done,B]] }
def setB(b0: String) = { built = built.copy(b = b0); this.asInstanceOf[Builder[A,Done]] }
def result(implicit ev: Builder[A,B] <:< Builder[Done,Done]) = built
}
object Builder {
def apply() = new Builder[Need, Need]
}
如果您在REPL中尝试此操作，请确保Builder类和对象在同一块中定义，即使用:paste。通过使用<:<检查类型、泛型类型参数和case类的复制方法，可以形成非常强大的组合。
工厂方法的主要用途是使您的类型保持清晰；否则，您可能会使用构造函数。由于Scala强大的类型系统，您不需要帮助来保持类型清晰，因此您可以使用构造函数或类伴生对象中的apply方法来创建事物。特别是在伴生对象的情况下，保持接口一致的难度与保持工厂对象中的接口一致的难度相同。因此，大多数工厂对象的动机已经消失。
同样，许多抽象工厂方法的情况可以通过使类伴生对象继承一个适当的trait来替换。
match而不是笨拙的instanceof测试。object来实现单例——使用和享受吧！trait在这里提供了更强大的功能——例如，你可以创建一个只实现接口的部分的特质，留下其他部分由你来定义。例如，java.awt.event.MouseMotionListener要求你填写两个方法：def mouseDragged(me: java.awt.event.MouseEvent)
def mouseMoved(me: java.awt.event.MouseEvent)
trait:trait MouseMoveListener extends java.awt.event.MouseMotionListener {
def mouseDragged(me: java.awt.event.MouseEvent) {}
}
mouseMoved。因此：使用类似的模式，但使用Scala更加强大。trait MouseMotioner extends java.awt.event.MouseMotionListener {
def mouseMotion(me: java.awt.event.MouseEvent, drag: Boolean): Unit
def mouseMoved(me: java.awt.event.MouseEvent) { mouseMotion(me, false) }
def mouseDragged(me: java.awt.event.MouseEvent) { mouseMotion(me, true) }
}
lazy val，只有在需要时才创建变量（并且此后重复使用），以及by-name parameters，仅在函数实际使用该值时才执行创建函数参数所需的工作。尽管如此，在某些情况下，Java模式保持不变。
在Scala中与Java相同。
在那些可以按顺序列出负责方的情况下，你可以
xs.find(_.handleMessage(m))
handleMessage方法，如果消息已处理，则返回true。如果您想在消息传递过程中对其进行更改，请使用fold。
由于很容易将责任方放入某种缓冲区中，因此Java解决方案中使用的复杂框架在Scala中很少有用处。
这种模式几乎完全被函数取代。例如，可以使用以下方式代替所有内容：
public interface ChangeListener extends EventListener {
void stateChanged(ChangeEvent e)
}
...
void addChangeListener(ChangeListener listener) { ... }
你只需要
def onChange(f: ChangeEvent => Unit)
Scala提供了解析器组合器，比简单的解释器设计模式要强大得多。
Scala在其标准库中内置了Iterator。几乎可以轻松地使自己的类扩展Iterator或Iterable；后者通常更好，因为它使重用变得简单。这绝对是一个好主意，但如此直截了当，我几乎不会称之为一种设计模式。
这在Scala中可以很好地工作，但通常适用于可变数据，即使中介者也可能因使用不当而遇到竞态条件等问题。相反，尽可能将所有相关数据存储在一个不可变集合、case class或其他类型中，并在需要协调更改的更新时同时更改所有内容。这样做不能帮助您与javax.swing进行接口交互，但在其他情况下广泛适用：
case class Entry(s: String, d: Double, notes: Option[String]) {}
def parse(s0: String, old: Entry) = {
try { old.copy(s = s0, d = s0.toDouble) }
catch { case e: Exception => old }
}
当您需要处理多个不同关系（每个关系一个中介者）或具有可变数据时，请使用中介者模式。
lazy val 几乎是备忘录模式的许多最简单应用的理想选择，例如：
class OneRandom {
lazy val value = scala.util.Random.nextInt
}
val r = new OneRandom
r.value // Evaluated here
r.value // Same value returned again
你可以创建一个专门用于惰性求值的小类：
class Lazily[A](a: => A) {
lazy val value = a
}
val r = Lazily(scala.util.Random.nextInt)
// not actually called until/unless we ask for r.value
这是一个相当脆弱的模式。在可能的情况下，最好使用不可变状态（参见中介者模式），或者使用演员模式，其中一个演员向所有其他演员发送有关状态更改的消息，但每个演员都可以处理过时的状态。
这在Scala中同样有用，并且实际上是创建没有方法的特征枚举的首选方式：
sealed trait DayOfWeek
final trait Sunday extends DayOfWeek
...
final trait Saturday extends DayOfWeek
通常你希望工作日做些事情来证明这些样板代码的数量是有必要的。
这几乎完全被使用方法来接受实现策略的函数所取代，并提供可供选择的函数。
def printElapsedTime(t: Long, rounding: Double => Long = math.round) {
println(rounding(t*0.001))
}
printElapsedTime(1700, math.floor) // Change strategy
特质在这里提供了更多的可能性，最好将它们视为另一种模式。您可以根据您的抽象级别从尽可能多的信息中填充代码。我不想真的称它为同样的东西。
在 结构类型 和 隐式转换 之间，Scala 拥有比Java典型的访问者模式更多的能力。使用原始模式没有意义；你只会分心于正确的方法。许多例子实际上只是希望在被访问的对象上定义一个函数，而Scala可以轻松地为您完成这个操作（即将任意方法转换为函数）。
() => T。实际上，Scala对函数的语法糖也被用在了case类中：case class T(x: Int)
class T(val x: Int) { /* bunch of methods */ }
object T {
def apply(x: Int) = new T(x)
/* other stuff */
}
T(n) 实例化 T 而不是使用 new T(n)。你甚至可以像这样编写它：object T extends Int => T {
def apply(x: Int) = new T(x)
/* other stuff */
}
这将把T转换为一个正式的函数，而不改变任何代码。
这是考虑创建模式时需要记住的重要点。所以让我们来看看它们：
这个模式不太可能发生太大变化。一个类可以被视为一组密切相关的函数，因此通过类很容易实现一组密切相关的函数，这就是这个模式为构造函数所做的事情。
建造者模式可以通过柯里化函数或部分函数应用程序来替换。
def makeCar: Size => Engine => Luxuries => Car = ???
def makeLargeCars = makeCar(Size.Large) _
def makeCar: (Size, Engine, Luxuries) => Car = ???
def makeLargeCars = makeCar(Size.Large, _: Engine, _: Luxuries)
如果放弃子类化，该方法将变得过时。
不会改变--实际上，这是在函数式数据结构中创建数据的常见方式。请参阅案例类的copy方法，或返回集合的所有非可变方法。
当您的数据是不可变的时，单例并不特别有用，但Scala object以安全的方式实现了这种模式。
这主要与数据结构有关，函数式编程的重要点是数据结构通常是不可变的。你最好去看看持久化数据结构、单子和相关概念，而不是试图将这些模式转化为函数式等价物。
并不是说这里的某些模式不相关。我只是说，作为一般规则，你应该先研究上面的东西，而不是试图将结构模式转化为函数式等价物。
这种模式与类（名义类型）有关，因此只要您拥有它，它仍然很重要，当您没有它时，它就不相关了。
与OO架构有关，因此与上述相同。
看看镜头和拉链。
装饰器只是函数组合。如果您正在装饰整个类，则可能不适用。但是，如果您将功能提供为函数，则在保持其类型的同时组合函数是装饰器。
与桥接的评论相同。
如果您认为构造函数是函数，则将享元视为函数记忆化。此外，享元与如何构建持久数据结构密切相关，并且从不变性中获益很多。
与适配器的评论相同。
这到处都是。其中一些完全无用，而其他一些在函数设置中仍然像以往一样相关。
像装饰器一样，这是函数组合。
这是一个函数。如果您的数据是不可变的，则撤消部分是不必要的。否则，只需保留一对函数及其反向即可。另请参阅Lenses。
这是一个单子。
它可以通过向集合传递一个函数来使其过时。这实际上就是Traversable使用foreach所做的。另外，请参见Iteratee。
仍然相关。
对于不可变对象没有用处。此外，它的重点是保持封装性，在FP中并不是主要关注点。
请注意，这个模式不是序列化，而序列化仍然是相关的。
相关，但请参见Functional Reactive Programming。
这是一个单子。
策略是一个函数。
这是一个面向对象的设计模式，因此对于面向对象的设计是相关的。
访问者只是接收一个函数的方法。实际上，这就是Traversable的foreach所做的事情。
在Scala中，它也可以用提取器替换。