原文标题：Converting Plaid to Kotlin: Lessons learned (Part 2)
原文链接：http://antonioleiva.com/plaid-kotlin-2/
原文作者：Antonio Leiva（http://antonioleiva.com/about/）
原文发布：2015-11-17
我们在第一部分中所见的各种显著地改进，要归功于在Activity中使用了Kotlin语言。但是，由于主要是重载方法做些事情，仍然免不了一些公式化代码，所以这种类型的类还不能很好的展示其效果。
我持续用Kotlin语言改写该APP（大家可以在repo看到所有改变），并遇到一些有趣的事情。今天，我着重谈论DataManager类的转换。透露一下，该类的大小已从422行减少到177行。我认为这很容易理解。
When
纵观该类时，首先看到最多的就是在loadSource类中有大量的if/else语句。在第一个实例中，可以用switch语句提升可读性，但是总还是有点不易理解。在Kotlin语言中，可以用when expression(表达式)，它非常类似Java语言中的switch语句，但是功能更强。条件可以依据需要编写，且可以很好的替代if/else语句。这里使用其最简单版本，也已经可以使这个方法更容易阅读：
when (source.key) {
SourceManager.SOURCE_DESIGNER_NEWS_POPULAR -> loadDesignerNewsTopStories(page)
SourceManager.SOURCE_DESIGNER_NEWS_RECENT -> loadDesignerNewsRecent(page)
SourceManager.SOURCE_DRIBBBLE_POPULAR -> loadDribbblePopular(page)
SourceManager.SOURCE_DRIBBBLE_FOLLOWING -> loadDribbbleFollowing(page)
SourceManager.SOURCE_DRIBBBLE_USER_LIKES -> loadDribbbleUserLikes(page)
SourceManager.SOURCE_DRIBBBLE_USER_SHOTS -> loadDribbbleUserShots(page)
SourceManager.SOURCE_DRIBBBLE_RECENT -> loadDribbbleRecent(page)
SourceManager.SOURCE_DRIBBBLE_DEBUTS -> loadDribbbleDebuts(page)
SourceManager.SOURCE_DRIBBBLE_ANIMATED -> loadDribbbleAnimated(page)
SourceManager.SOURCE_PRODUCT_HUNT -> loadProductHunt(page)
else -> when (source) {
is Source.DribbbleSearchSource -> loadDribbbleSearch(source, page)
is Source.DesignerNewsSearchSource -> loadDesignerNewsSearch(source, page)
}
}
然而，这不是case，是when表达式，所以可以返回一个值，这非常有用。
映射处理
虽然，这个例子并没有减少多少代码（行），但是可以有趣的看到，在Kotlin中怎样处理映射表。在Java语言中，getNextPageIndex如下：
private int getNextPageIndex(String dataSource) {
int nextPage = 1; // default to one – i.e. for newly added sources
if (pageIndexes.containsKey(dataSource)) {
nextPage = pageIndexes.get(dataSource) + 1;
}
pageIndexes.put(dataSource, nextPage);
return nextPage;
}
那在Kotlin语言中是怎样的？
private fun getNextPageIndex(dataSource: String): Int {
val nextPage = 1 + pageIndexes.getOrElse(dataSource) { 0 }
pageIndexes += dataSource to nextPage
return nextPage
}
这里有些有趣的事，首先是getOrElse函数，如果在映射表中，没有找到元素，则允许返回默认值:
val nextPage = 1 + pageIndexes.getOrElse(dataSource) { 0 }
多亏这一点，我们可以节省一些条件检查代码。而另一件事更有趣的事是，如何在映射表中添加新的项。Kotlin语言的映射表实现了“+”操作符，这样添加新项就可以如此：map = map + Pair，还可以 map += Pair。即：
pageIndexes += Pair(dataSource, nextPage)
但是，我之前可能说过，可以用to(中缀函数)返回Pair。这样前一行就如同：
pageIndexes += dataSource to nextPage
将callback（回调函数）转换到Lambda表达式
这如同变魔术一样。在装载类中有许多重复的代码。它们大多数有复制来的相同结构，而其它则是调用API。首先，创建Retrofit回调函数。如果请求成功，无论需要什么都可以从结果获取必要的信息。最后，调用“数据装载”侦听器。在任何情况（无论成功或失败）下，loadingCount都更新了。
仅举一例：
private void loadDesignerNewsTopStories(final int page) {
getDesignerNewsApi().getTopStories(page, new Callback<StoriesResponse>() {
@Override
public void success(StoriesResponse storiesResponse, Response response) {
if (storiesResponse != null
&& sourceIsEnabled(SourceManager.SOURCE_DESIGNER_NEWS_POPULAR)) {
setPage(storiesResponse.stories, page);
setDataSource(storiesResponse.stories,
SourceManager.SOURCE_DESIGNER_NEWS_POPULAR);
onDataLoaded(storiesResponse.stories);
}
loadingCount.decrementAndGet();
}
@Override
public void failure(RetrofitError error) {
loadingCount.decrementAndGet();
}
});
}
如果不分析，这段代码理解起来相当困难。我们可以创建一个回调函数，它创建retrofit回调函数，实现前面回调函数的结构。所不同的是从结果中获取必要的信息:
private inline fun <T> callback(page: Int, sourceKey: String,
crossinline extract: (T) -> List<PlaidItem>)
= retrofitCallback<T> { result, response ->
if (sourceIsEnabled(sourceKey)) {
val items = extract(result)
setPage(items, page)
setDataSource(items, sourceKey)
onDataLoaded(items)
}
}
这十分相似：检查是否启用源，如果启用，就调用setPage，setDataSource和onDataLoaded从结果中获取相关项。retrofitCallback的实现可使前面的函数更简单，而它可以省略了：
private inline fun <T> retrofitCallback(crossinline code: (T, Response) -> Unit): Callback<T>
= object : Callback<T> {
override fun success(t: T?, response: Response) {
t?.let { code(it, response) }
loadingCount.decrementAndGet()
} override fun failure(error: RetrofitError) {
loadingCount.decrementAndGet()
}
}
inline修饰符是优化函数的方法，该函数的参数包含其它函数。当函数包含lambda表达式时，其转换等同于对象包含了函数的实现代码。然而，如果用inline，lambda表达式将在被调用时由它的代码来替换。如果lambda表达式返回一个值，就要用crossinline。更多资料请阅读Kotlin参考资料。
两个函数是泛型，所以可以接受任何要求的类型。这样，前面的请求就可以如下：
private fun loadDesignerNewsTopStories(page: Int) {
designerNewsApi.getTopStories(page,
callback(page, SourceManager.SOURCE_DESIGNER_NEWS_POPULAR) { it.stories })
}
该函数调用getTopStories，创建接收page和源key的回调函数，函数从结果中获取stories。类似的结构为调用的其它部分运行，但是无论需要什么结果都可以做。例如，另一个响应需要修改包含的user:
private fun loadDribbbleUserShots(page: Int) = dribbbleLogged {
val user = dribbblePrefs.user
dribbbleApi.getUserShots(page, DribbbleService.PER_PAGE_DEFAULT,
callback(page, SourceManager.SOURCE_DRIBBBLE_USER_SHOTS) {
// this api call doesn't populate the shot user field but we need it
it.apply { forEach { it.user = user } }
})
}
如你所见，前者还要求记录到dribbble中。dribbbleLogged函数负责检查，如果不是就做其它事。
private inline fun dribbbleLogged(code: () -> Unit) {
if (dribbblePrefs.isLoggedIn) {
code()
} else {
loadingCount.decrementAndGet()
}
}
总结
这部分展示了lambda表达式能力和作为“第一类公民（first class citizen）”函数的使用。代码的减少是巨大的（减少238%），但还不是最重要的改进。现在代码更易阅读，错误更少。记得阅读我在Github的Plaid分支中最后的提交。
前一篇：http://www.cnblogs.com/figozhg/p/5041855.html