原文地址
实现一个adapter（适配器）对于一个Android开发者来说应该是最频繁的任务了，对于一个app来说，列表是最基本的功能。一般实现一个列表的流程都是相同的：一个view和一个绑定数据的适配器。但是盲目的一直写出来的可能是很糟糕的代码，更可怕的是重复写这样糟糕的代码。
是时候想想怎么更优雅的实现适配器了
RecyclerView基础
对于RecyclerView（也适用于ListView）的基本操作一般都是:
创建一个view并且有一个ViewHolder来持有view的信息，
将ViewHolder和adapter中的data绑定在一起，可能是一个model类的列表。
实现十分的简洁，也不会出什么问题
RecyclerView存在不同的Types
当你的view中有多个不同的item时事情就变得复杂了，甚至是一个列表中每一个item的数据对象都是不同的（这篇文章使用的是Kotlin 但是也适用于Java，并没有语法特性上的使用）
interface Animal
class Mouse: Animal
class Duck: Animal
class Dog: Animal
class Car
比如说可能有各种各样的动物但是突然出现了一个车和其他的种类是毫不相关的，在那些用例中你可能需要展示不同的view类型，这意味着需要去创建不同的 ViewHolder 而且各自初始化不同的layout，一般首先会去继承系统的方法，
override fun getItemViewType(position: Int) : Int
默认的实现通常都是返回0，这个实现需要将type转换成int型的值。
下一步：创建一个ViewHolder，然后你需要去实现一个方法
override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): RecyclerView.ViewHolder
这个方法里面有一个Int型的参数就是前面返回的，实现起来就是一个switch语句，然后就能根据每个type创建不同的ViewHolder
override fun onBindViewHolder(holder: ViewHolder, position: Int): Any
注意这个方法并没有type参数，如果需要的话可以通过 getItemViewType 来获取。在这个方法中我们将view和数据绑定在一起。
糟糕的实现
那么现在问题是什么呢？直接就可以实现了不是么
回头看这个方法 getItemViewType()，在绑定的过程中我们需要知道每个position的type，一般会怎么写呢，可能是这样
if (things.get(position) is Duck) {
return TYPE_DUCK
} else if (things.get(position) is Mouse) {
return TYPE_MOUSE
}
可以看到这段代码多么的糟糕么？如果你的 ViewHolder 没有共享一个公共的基类那么结果可能会更糟，按照这种形式，在绑定的时候写出来的应该也是这样的
override fun onBindViewHolder(holder: RecyclerView.ViewHolder, position: Int) {
val thing = things.get(position)
if (thing is Animal) {
(holder as AnimalViewHolder).bind(thing as Animal)
} else if (thing is Car) {
(holder as CarViewHolder).bind(thing as Car)
}
...
}
这个代码里面充斥着instance of判断以及cast强转，一般被称之为反设计模式
Effective C++ by Scott Meyers的作者曾经说过一段话
Anytime you find yourself writing code of the form “if the object is of type T1, then do something, but if it’s of type T2, then do something else,” slap yourself.
回看上面这个适配器的实现，有大量的糟糕的实现
- 充斥着类型检查和强转
- 这根本就不是面向对象的代码，面向对象的思想已经诞生了50年，我们更应该利用它的长处
- 此外，这个适配器实现的方式违反了Open-Closed以及SOLID原则，原则表明：对扩展开放，对修改关闭。但是当我们需要添加另一种类型，另一种Model，比如就叫
Rabbit和RabbitViewHolder，我们不得不去改变大量适配器的代码，一种新的对象不应该导致已经存在的方法的修改。
所以，让我们来尝试解决这个问题。
让我们解决它
一个可选的方案就是添加一个中间层来做这个转换，比如将 Class type添加到map(key-value键值对)中，然后通过一个方法来获取type。代码看起来像这样
override fun getItemViewType(position: Int) : Int= types.get(things.javaClass)
这样就可以了么？当然是不行的，这实际上只是将 instance of 隐藏在后面来实现了。
最终的目标应该是添加一个新的view type 但是不接触这个适配器。所以，不要创建type映射在适配器中。Google建议使用layout id这种方式，通过这个技巧你不需要人工创造 type 映射而是只需要使用你inflate的layout id。
我们可以将这个技巧迁移到绑定model在view上的操作，将type放到model中的做法十分的吸引人，看起来像这样
fun getType() : Int = R.layout.item_duck
这种方式实现适配器中的type是十分常规的：
override fun getItemViewType(pos: Int) = things[pos].getType()
开闭原则适用，而且当我们添加model的时候不会改变适配器，但是实际上我们将各层混合在了一起，破坏了完整的架构，这是我们无法接受的。
ViewModel
解决这个问题的一种方法就是，分离出ViewModel而不是直接使用我们的Model，我们最后的问题就是，这些Model是不相交的，他们不共享一个公共的基类，比如前面例子的car并不是一个animal。只有在presentation 层需要去展示这些model，所以我们可以实现一个公共的基类
abstract class ViewModel {
abstract fun type(): Int
}
class DuckViewModel(val duck: Duck): ViewModel() {
override fun type() = R.layout.duck
}
class CarViewModel(val car: Car): ViewModel() {
override fun type() = R.layout.car
}
这样就能简单的包装这些models，再有新的ViewModel的实现类也不需要修改前面的方法，除此之外你也可以通过使用Android的Data Binding Library来添加一些额外的逻辑。我们可以使用一个ViewModel的列表传递给adapter，直接使用type方法便能拿到绑定了Model的View。
这是一种解决问题的方法，但是不只是存在这一种。
Visitor访问者模式
回到我们使用的Model，如果你有大量的model的类，可能你并不想去创建额外同样多的ViewModel，回想一开始在model里面加入的 type 方法，可能造成了一些耦合，这也是存在一些不好的设计，最好避免在这个地方直接的产生交互，然后能把真正的type转移到别的地方去。我们先添加一个包含type方法的接口，
interface Visitable {
fun type(typeFactory: TypeFactory) : Int
}
现在你可能会问这样有什么意义，这些Factory依然需要给每个type一个分支，这不是和最开始的适配器所做的事情一样了么？
实际上并不是的，这个方法基于的是访问者模式，著名的GOF模式之一
这个Model所需要做的，只是顺着实现这个接口中的方法
interface Animal : Visitable
interface Car : Visitable
class Mouse: Animal {
override fun type(typeFactory: TypeFactory) = typeFactory.type(this)
}
这个Factory中有不少需要重载的方法
interface TypeFactory {
fun type(duck: Duck): Int
fun type(mouse: Mouse): Int
fun type(dog: Dog): Int
fun type(car: Car): Int
}
这种方法完全是类型安全的，并且没有instance of类型检查，也不需要强转
这个Factory的职责也十分的清晰了，提供我们所需要绑定的view type
class TypeFactoryForList : TypeFactory {
override fun type(duck: Duck) = R.layout.duck
override fun type(mouse: Mouse) = R.layout.mouse
override fun type(dog: Dog) = R.layout.dog
override fun type(car: Car) = R.layout.car
同样的方式也可以用来创建 ViewHolder ，所以当我们添加一个新的view类型，可以直接加到这个地方，这种方式是十分健壮的，在我们添加一个新的type的时候不需要修改已经存在的方法，满足开闭原则。
现在你可能会问：为什么不直接的使用工厂方式而是间接的使用model？实际上只有通过这种方式才能避开需要类型检查以及强转这样的操作，这正是设计模式的精妙之处。
通过这种方式可以十分简单的实现一个适配器而且在修改代码时简洁明了，不必做额外的更改。
结论
- 尽量保证交互层的代码简洁易懂
- 频繁使用类型检查是一个不好的设计
- 强转及其容易产生错误，尽量避免这种操作
- 学会正确的使用面向对象的思想，思考接口和继承的意义
- 尝试使用ViewModel
- 活用设计模式，比如访问者Visitor模式
当然可能会有更简洁有趣的实现适配器的方式，不过上面的这些实现已经脱离了那些糟糕的实现方式。
最后
译者补充一点，有人根据作者的思想写了一个例子，看例子有助于理解这个思想，顺便安利一下kotlin，语法十分的强大，和java语言无缝衔接，而且Android Studio给予了足够的支持，对于提高开发效率还是很有裨益的。
