使用隐式转换代替适配器模式答案

【问题标题】：Using implicit conversion instead Adapter pattern使用隐式转换代替适配器模式
【发布时间】：2013-07-21 08:05:58
【问题描述】：

我有一个用 MVC 风格编写的项目。视图如下所示：

trait BaseView {
  def asComponent(): Component // each view can be displayed on screen
}


class ConcreteView extends Panel with BaseView  {

  def asComponent(): Component = this //ConcreteView is itself Component because it extends Panel 
}

是否可以更改此代码以使用从ConcreteView 到Component 的隐式转换？所以我可以将ConcreteView 用作Component（由于隐式转换）而不调用ConcreteView#asComponent 方法？

【问题讨论】：

你为什么需要这样的方法？ val c: Component = someConcreteView 应该已经可以工作了。
为了更好地理解什么时候应该和什么时候不应该对适配器模式使用隐式转换，我建议你阅读我的博客文章 - maxondev.com/adapter-design-pattern-scala-implicits

标签： scala implicit-conversion

【解决方案1】：

是的，这是可能的。只需定义一个从 BaseView 到调用 asComponent 方法的 Component 的隐式转换。

object BaseView {
  implicit def viewIsComponent(x:BaseView) : Component = x.asComponent
}

但这并不意味着这是一个好主意。 scala 中的隐式转换是一个非常强大的功能。如果一个BaseView（并通过继承每个XXXView）是一个组件，这意味着当你想调用val myView:SomeView的方法时，你将获得组件的所有方法。这完全使命名空间变得混乱，并且也可能很危险，因为您不确定是调用 View 的方法还是它隐式映射到的 Component 的方法。

在 scala 库中，已经从隐式转换转向更显式和稍微冗长的方式。以JavaConversions 为例：它们提供从 scala 集合到 java 集合的隐式转换并返回。这听起来是个好主意，但在实践中却造成了很多麻烦：

转换发生在您不期望的情况下
scala 集合的命名空间中充斥着大量来自 java 等效项的附加方法
当新方法添加到隐式转换的目标与转换源中的方法发生冲突时，很难找到问题

目前推荐的处理 java/scala 集合互操作的方法是使用更显式的JavaConverters，它将单个方法 asScala 添加到 java 集合，将 asJava 添加到 scala 集合。

所以保持方法不变。也许将名称更改为 .component，因为您并没有真正将视图 convert 转换为组件，而只允许某人访问每个视图必须具有的组件。

【讨论】：