欢迎使用OOP模式匹配：访客模式
访客模式已死。 访客模式万岁。 （以Kotlin为例）
函数式编程在IT领域获得了巨大的发展。 事情来来往往，但FP并不是其中之一。 比OOP更具表现力
几年前，我在博洛尼亚举行的LambaConf会议上开始研究它，我获得的见识越多，我就越喜欢FP。 在六月，我去了这个工作坊，老师深入研究了代数数据类型和模式匹配 。 我最终也了解了Monad是什么，但这是另一个故事。 我曾经将模式匹配视为一种解构列表的有趣方式。 现在，我知道这是FP软件设计的基础，并且是解决将域对象数据和行为分离的有效方法。
让我们来看一个例子！
按国家/地区本地化的ERP
假设我们要编写一个ERP软件，以竞争两个不同国家的市场。 意大利和德国。 我们将在许多域对象上编写许多CRUD操作。 这里没有挑战。
但是，如何在相同的功能流内在不同的数据结构上针对特定国家/地区的业务规则建模呢？
例如，这两个国家/地区的数据库中都有文章，并且您肯定要在它们上进行搜索。 但是搜索规则和获取的数据可能完全不同。
由于数据结构不同，我们不能仅仅拥有域实体“ Article”：我们至少需要一个“ ItalianArticle”和“ GermanArticle”。 考虑到数据存储的结构也可能不同。
FP方式
让我们看一下Scala的实现：写一个sum类型的Article 。 然后我们将其专门化为ItalianArticle和GermanArticle的产品类型。 另外，我们希望当我们搜索某些内容时，有时什么也找不到。 因此，我们还将考虑ArticleNotFound 。
sealed trait Article
case class ItaArticle ( id: Int , itaData1: String , itaData2: Int ) extends Article
case class DeuArticle ( id: Int , deuData1: Int , deuData2: Int ) extends Article
case class ArticleNotFound ( ) extends Article每次我们从某个地方收到文章时，我们都会在其上进行图案匹配。 在比赛中，我们可以访问其专门数据
def doSomething (article: Article ) : Unit = {
article match {
case ita: ItaArticle => print(ita.itaData1)
case deu: DeuArticle => print(deu.deuData2)
case nf: ArticleNotFound => print( "None" )
}
}不是开关吗？
乍一看，它看起来像是经典的程序“开关”，然后是向下转换。 有一个重要的区别：编译器知道我们是否匹配每种类型的Article。 例如，如果我们忘记在ArticleNotFound上进行匹配
def doSomething (article: Article ) : Unit = {
article match {
case ita: ItaArticle => print(ita.itaData1)
case deu: DeuArticle => print(deu.deuData2)
}
}那么默认情况下， sbt编译器将发出警告。
编译器知道有问题时，我们可以使它引发错误而不是警告。
新要求：西班牙
此时，完全出乎意料的事情发生了！ 业务对我们提出了新要求：我们还需要在西班牙进行分销。
其实我们已经准备好了，所以让我们添加SpaArticle 我们的Article和类型。
sealed trait Article
case class ItaArticle ( id: Int , itaData1: String , itaData2: Int ) extends Article
case class DeuArticle ( id: Int , deuData1: Int , deuData2: Int ) extends Article
case class SpaArticle ( id: Int , spaData1: Float , spaData2: String ) extends Article
case class ArticleNotFound ( ) extends Article现在，我们需要添加西班牙语业务逻辑。
如果正常切换，搜索在每个实施了国家特定业务规则的地方将很痛苦。
相反，使用模式匹配，编译器会告诉我们必须进行干预。
OOP有可能吗？
是的，当然可以使用“ 访客”模式 ！
如果您不了解访问者模式 ，请在此处查看
如果您不知道四个帮派的话，请在这里看看。
访客模式作为反模式已经很久了。 当您添加新的项目类型时，您还将向访问者界面添加新的方法。 在这种情况下，编译器将中断每个具体的访问者，直到您在每个访问者中实现新方法为止。 这是成为反模式的原因之一。
实际上，对于我们的担忧，这个“问题”看起来与我们正在寻找的完全一样！
Kotlin示例
在此遵循我们的总和类型的Kotlin实现：
interface Article {
fun applyTo (consumer: ArticleConsumer )
}
class ItaArticle ( val itaData1: String, val itaData2: Int ) : Article {
override fun applyTo (consumer: ArticleConsumer ) {
consumer.use( this )
}
}
class DeuArticle ( val deuData1: String) : Article {
override fun applyTo (consumer: ArticleConsumer ) {
consumer.use( this )
}
}您会注意到，我更喜欢考虑“应用于数据使用者的数据”，而不是使用“ accept”和“ Visitor”命名。 （我正在寻找更好的命名方式，因此，如果您有任何建议，请发表评论！谢谢 ）
在这里，我们可以实施特定国家/地区的业务规则
interface ArticleConsumer {
fun use (article: ItaArticle )
fun use (article: DeuArticle )
fun use (article: ArticleNotFound )
}
fun useAnArticle (article: Article ) : String {
var x = ""
article.applyTo( object : ArticleConsumer {
override fun use (article: ItaArticle ) {
x = article.itaData1
}
override fun use (article: DeuArticle ) {
x = article.deuData1
}
override fun use (article: ArticleNotFound ) {
x = "not found"
}
})
return x
} 此示例的语义与FP模式匹配完全相同。 当我们要添加新的国家，那么编译器是要打破一切，直到我们不执行新的fun use(article: SpaArticle)在每一个ArticleConsumer 。
结论
访客模式的最初目的是对异构对象的集合进行迭代操作，该异构对象不共享相同的接口和数据类型。
在本文中，我建议将其用作路由点。 当您最终枚举域实体并需要设置本地化的域上下文时，此功能很有用。
在方法中枚举域实体被认为是一个问题。 在这种用例中，它是模式的关键特征。
我还证明了这种用法在语义上等同于FP模式匹配 。
请在评论中留下您的意见和反馈。
感谢您的阅读！
From: https://hackernoon.com/welcome-to-the-oop-pattern-matching-visitor-pattern-1q7n031xc