Merge pull request #247 from Nyvryl/Nyvryl-patch-1

Revise chapter 5.5 on function values in Go

ch5/ch5-05.md

@@ -119,7 +119,7 @@ $ ./outline2 http://gopl.io
 
 **练习 5.7：** 完善startElement和endElement函数，使其成为通用的HTML输出器。要求：输出注释结点，文本结点以及每个元素的属性（< a href='...'>）。使用简略格式输出没有孩子结点的元素（即用`<img/>`代替`<img></img>`）。编写测试，验证程序输出的格式正确。（详见11章）
 
-**练习 5.8：** 修改pre和post函数，使其返回布尔类型的返回值。返回false时，中止forEachNoded的遍历。使用修改后的代码编写ElementByID函数，根据用户输入的id查找第一个拥有该id元素的HTML元素，查找成功后，停止遍历。
+**练习 5.8：** 修改pre和post函数，使其返回布尔类型的返回值。返回false时，中止forEachNode的遍历。使用修改后的代码编写ElementByID函数，根据用户输入的id查找第一个拥有该id元素的HTML元素，查找成功后，停止遍历。
 
 ```Go
 func ElementByID(doc *html.Node, id string) *html.Node
@@ -130,3 +130,4 @@ func ElementByID(doc *html.Node, id string) *html.Node
 ```Go
 func expand(s string, f func(string) string) string
 ```
+

ch5/ch5-06.md

@@ -101,7 +101,7 @@ visitAll := func(items []string) {
 }
 ```
 
-在toposort程序的输出如下所示，它的输出顺序是大多人想看到的固定顺序输出，但是这需要我们多花点心思才能做到。哈希表prepreqs的value是遍历顺序固定的切片，而不再试遍历顺序随机的map，所以我们对prereqs的key值进行排序，保证每次运行toposort程序，都以相同的遍历顺序遍历prereqs。
+在toposort程序的输出如下所示，它的输出顺序是大多人想看到的固定顺序输出，但是这需要我们多花点心思才能做到。哈希表prepreqs的value是遍历顺序固定的切片，而不再是遍历顺序随机的map，所以我们对prereqs的key值进行排序，保证每次运行toposort程序，都以相同的遍历顺序遍历prereqs。
 
 ```
 1: intro to programming
@@ -302,3 +302,4 @@ for i := 0; i < len(dirs); i++ {
 ```
 
 如果你使用go语句（第八章）或者defer语句（5.8节）会经常遇到此类问题。这不是go或defer本身导致的，而是因为它们都会等待循环结束后，再执行函数值。
+

ch7/ch7-03.md

@@ -79,7 +79,7 @@ any = new(bytes.Buffer)
 
 对于创建的一个interface{}值持有一个boolean，float，string，map，pointer，或者任意其它的类型；我们当然不能直接对它持有的值做操作，因为interface{}没有任何方法。我们会在7.10章中学到一种用类型断言来获取interface{}中值的方法。
 
-因为接口与实现只依赖于判断两个类型的方法，所以没有必要定义一个具体类型和它实现的接口之间的关系。也就是说，有意地在文档里说明或者程序上断言这种关系偶尔是有用的，但程序上不强制这么做。下面的定义在编译期断言一个`*bytes.Buffer`的值实现了io.Writer接口类型:
+因为接口与实现只依赖于判断两个类型的方法，所以没有必要定义一个具体类型和它实现的接口之间的关系。也就是说，有意地在文档里说明或者程序上断言这种关系偶尔是有用的，但程序上不强制这么做。这种写法还可用于让编译器在编译期确保某个类型确实满足接口要求，从而提前发现实现遗漏或接口变更导致的不匹配问题。下面的定义在编译期断言一个`*bytes.Buffer`的值实现了io.Writer接口类型:
 
 ```go
 // *bytes.Buffer must satisfy io.Writer
@@ -150,3 +150,4 @@ type Streamer interface {
 ```
 
 每一个具体类型的组基于它们相同的行为可以表示成一个接口类型。不像基于类的语言，他们一个类实现的接口集合需要进行显式的定义，在Go语言中我们可以在需要的时候定义一个新的抽象或者特定特点的组，而不需要修改具体类型的定义。当具体的类型来自不同的作者时这种方式会特别有用。当然也确实没有必要在具体的类型中指出这些共性。
+

ch7/ch7-05.md

@@ -151,7 +151,7 @@ if out != nil {
 
 动态分配机制依然决定(\*bytes.Buffer).Write的方法会被调用，但是这次的接收者的值是nil。对于一些如\*os.File的类型，nil是一个有效的接收者（§6.2.1），但是\*bytes.Buffer类型不在这些种类中。这个方法会被调用，但是当它尝试去获取缓冲区时会发生panic。
 
-问题在于尽管一个nil的\*bytes.Buffer指针有实现这个接口的方法，它也不满足这个接口具体的行为上的要求。特别是这个调用违反了(\*bytes.Buffer).Write方法的接收者非空的隐含先觉条件，所以将nil指针赋给这个接口是错误的。解决方案就是将main函数中的变量buf的类型改为io.Writer，因此可以避免一开始就将一个不完整的值赋值给这个接口：
+问题在于尽管一个nil的\*bytes.Buffer指针有实现这个接口的方法，它也不满足这个接口具体的行为上的要求。特别是这个调用违反了(\*bytes.Buffer).Write方法的接收者非空的隐含先决条件，所以将nil指针赋给这个接口是错误的。解决方案就是将main函数中的变量buf的类型改为io.Writer，因此可以避免一开始就将一个不完整的值赋值给这个接口：
 
 ```go
 var buf io.Writer
@@ -162,3 +162,4 @@ f(buf) // OK
 ```
 
 现在我们已经把接口值的技巧都讲完了，让我们来看更多的一些在Go标准库中的重要接口类型。在下面的三章中，我们会看到接口类型是怎样用在排序，web服务，错误处理中的。
+

ch7/ch7.md

@@ -1,7 +1,7 @@
 # 第7章　接口
 
-接口类型是对其它类型行为的抽象和概括；因为接口类型不会和特定的实现细节绑定在一起，通过这种抽象的方式我们可以让我们的函数更加灵活和更具有适应能力。
+接口类型表达的是对其他类型行为的一种泛化或抽象。通过泛化，接口使我们能够编写更灵活、更适应变化的函数，因为它们不依赖于某个特定实现的细节。
 
-很多面向对象的语言都有相似的接口概念，但Go语言中接口类型的独特之处在于它是满足隐式实现的。也就是说，我们没有必要对于给定的具体类型定义所有满足的接口类型；简单地拥有一些必需的方法就足够了。这种设计可以让你创建一个新的接口类型满足已经存在的具体类型却不会去改变这些类型的定义；当我们使用的类型来自于不受我们控制的包时这种设计尤其有用。
+许多面向对象的语言都有“接口”这一概念，但 Go 的接口之所以独特，是因为它们是隐式满足的。换句话说，一个具体类型不需要显式声明它实现了哪些接口；只要它拥有接口所需的方法，就自动被认为满足了该接口。这种设计让你可以为已有的具体类型创建新的接口，而不需要修改这些类型本身——这在处理你无法控制的外部包中定义的类型时特别有用
 
 在本章，我们会开始看到接口类型和值的一些基本技巧。顺着这种方式我们将学习几个来自标准库的重要接口。很多Go程序中都尽可能多的去使用标准库中的接口。最后，我们会在（§7.10）看到类型断言的知识，在（§7.13）看到类型开关的使用并且学到他们是怎样让不同的类型的概括成为可能。