mirror of
https://github.com/gopl-zh/gopl-zh.github.com.git
synced 2025-12-17 19:24:19 +08:00
回到简体
This commit is contained in:
chai2010
@@ -1,10 +1,10 @@
|
||||
## 7.1. 接口約定
|
||||
## 7.1. 接口约定
|
||||
|
||||
目前爲止，我們看到的類型都是具體的類型。一個具體的類型可以準確的描述它所代表的值併且展示出對類型本身的一些操作方式就像數字類型的算術操作，切片類型的索引、附加和取范圍操作。具體的類型還可以通過它的方法提供額外的行爲操作。總的來説，當你拿到一個具體的類型時你就知道它的本身是什麽和你可以用它來做什麽。
|
||||
目前为止，我们看到的类型都是具体的类型。一个具体的类型可以准确的描述它所代表的值并且展示出对类型本身的一些操作方式就像数字类型的算术操作，切片类型的索引、附加和取范围操作。具体的类型还可以通过它的方法提供额外的行为操作。总的来说，当你拿到一个具体的类型时你就知道它的本身是什么和你可以用它来做什么。
|
||||
|
||||
在Go語言中還存在着另外一種類型：接口類型。接口類型是一種抽象的類型。它不會暴露出它所代表的對象的內部值的結構和這個對象支持的基礎操作的集合；它們隻會展示出它們自己的方法。也就是説當你有看到一個接口類型的值時，你不知道它是什麽，唯一知道的就是可以通過它的方法來做什麽。
|
||||
在Go语言中还存在着另外一种类型：接口类型。接口类型是一种抽象的类型。它不会暴露出它所代表的对象的内部值的结构和这个对象支持的基础操作的集合；它们只会展示出它们自己的方法。也就是说当你有看到一个接口类型的值时，你不知道它是什么，唯一知道的就是可以通过它的方法来做什么。
|
||||
|
||||
在本書中，我們一直使用兩個相似的函數來進行字符串的格式化：fmt.Printf它會把結果寫到標準輸出和fmt.Sprintf它會把結果以字符串的形式返迴。得益於使用接口，我們不必可悲的因爲返迴結果在使用方式上的一些淺顯不同就必需把格式化這個最睏難的過程複製一份。實際上，這兩個函數都使用了另一個函數fmt.Fprintf來進行封裝。fmt.Fprintf這個函數對它的計算結果會被怎麽使用是完全不知道的。
|
||||
在本书中，我们一直使用两个相似的函数来进行字符串的格式化：fmt.Printf它会把结果写到标准输出和fmt.Sprintf它会把结果以字符串的形式返回。得益于使用接口，我们不必可悲的因为返回结果在使用方式上的一些浅显不同就必需把格式化这个最困难的过程复制一份。实际上，这两个函数都使用了另一个函数fmt.Fprintf来进行封装。fmt.Fprintf这个函数对它的计算结果会被怎么使用是完全不知道的。
|
||||
|
||||
``` go
|
||||
package fmt
|
||||
@@ -20,10 +20,10 @@ func Sprintf(format string, args ...interface{}) string {
|
||||
}
|
||||
```
|
||||
|
||||
Fprintf的前綴F表示文件(File)也表明格式化輸出結果應該被寫入第一個參數提供的文件中。在Printf函數中的第一個參數os.Stdout是*os.File類型；在Sprintf函數中的第一個參數&buf是一個指向可以寫入字節的內存緩衝區，然而它
|
||||
併不是一個文件類型盡管它在某種意義上和文件類型相似。
|
||||
Fprintf的前缀F表示文件(File)也表明格式化输出结果应该被写入第一个参数提供的文件中。在Printf函数中的第一个参数os.Stdout是*os.File类型；在Sprintf函数中的第一个参数&buf是一个指向可以写入字节的内存缓冲区，然而它
|
||||
并不是一个文件类型尽管它在某种意义上和文件类型相似。
|
||||
|
||||
卽使Fprintf函數中的第一個參數也不是一個文件類型。它是io.Writer類型這是一個接口類型定義如下：
|
||||
即使Fprintf函数中的第一个参数也不是一个文件类型。它是io.Writer类型这是一个接口类型定义如下：
|
||||
|
||||
``` go
|
||||
package io
|
||||
@@ -41,11 +41,11 @@ type Writer interface {
|
||||
}
|
||||
```
|
||||
|
||||
io.Writer類型定義了函數Fprintf和這個函數調用者之間的約定。一方面這個約定需要調用者提供具體類型的值就像\*os.File和\*bytes.Buffer，這些類型都有一個特定籤名和行爲的Write的函數。另一方面這個約定保證了Fprintf接受任何滿足io.Writer接口的值都可以工作。Fprintf函數可能沒有假定寫入的是一個文件或是一段內存，而是寫入一個可以調用Write函數的值。
|
||||
io.Writer类型定义了函数Fprintf和这个函数调用者之间的约定。一方面这个约定需要调用者提供具体类型的值就像\*os.File和\*bytes.Buffer，这些类型都有一个特定签名和行为的Write的函数。另一方面这个约定保证了Fprintf接受任何满足io.Writer接口的值都可以工作。Fprintf函数可能没有假定写入的是一个文件或是一段内存，而是写入一个可以调用Write函数的值。
|
||||
|
||||
因爲fmt.Fprintf函數沒有對具體操作的值做任何假設而是僅僅通過io.Writer接口的約定來保證行爲，所以第一個參數可以安全地傳入一個任何具體類型的值隻需要滿足io.Writer接口。一個類型可以自由的使用另一個滿足相同接口的類型來進行替換被稱作可替換性(LSP里氏替換)。這是一個面向對象的特徵。
|
||||
因为fmt.Fprintf函数没有对具体操作的值做任何假设而是仅仅通过io.Writer接口的约定来保证行为，所以第一个参数可以安全地传入一个任何具体类型的值只需要满足io.Writer接口。一个类型可以自由的使用另一个满足相同接口的类型来进行替换被称作可替换性(LSP里氏替换)。这是一个面向对象的特征。
|
||||
|
||||
讓我們通過一個新的類型來進行校驗，下面\*ByteCounter類型里的Write方法，僅僅在丟失寫向它的字節前統計它們的長度。(在這個+=賦值語句中，讓len(p)的類型和\*c的類型匹配的轉換是必須的。)
|
||||
让我们通过一个新的类型来进行校验，下面\*ByteCounter类型里的Write方法，仅仅在丢失写向它的字节前统计它们的长度。(在这个+=赋值语句中，让len(p)的类型和\*c的类型匹配的转换是必须的。)
|
||||
|
||||
<u><i>gopl.io/ch7/bytecounter</i></u>
|
||||
```go
|
||||
@@ -57,7 +57,7 @@ func (c *ByteCounter) Write(p []byte) (int, error) {
|
||||
}
|
||||
```
|
||||
|
||||
因爲*ByteCounter滿足io.Writer的約定，我們可以把它傳入Fprintf函數中；Fprintf函數執行字符串格式化的過程不會去關註ByteCounter正確的纍加結果的長度。
|
||||
因为*ByteCounter满足io.Writer的约定，我们可以把它传入Fprintf函数中；Fprintf函数执行字符串格式化的过程不会去关注ByteCounter正确的累加结果的长度。
|
||||
|
||||
```go
|
||||
var c ByteCounter
|
||||
@@ -69,7 +69,7 @@ fmt.Fprintf(&c, "hello, %s", name)
|
||||
fmt.Println(c) // "12", = len("hello, Dolly")
|
||||
```
|
||||
|
||||
除了io.Writer這個接口類型，還有另一個對fmt包很重要的接口類型。Fprintf和Fprintln函數向類型提供了一種控製它們值輸出的途徑。在2.5節中，我們爲Celsius類型提供了一個String方法以便於可以打印成這樣"100°C" ，在6.5節中我們給*IntSet添加一個String方法，這樣集合可以用傳統的符號來進行表示就像"{1 2 3}"。給一個類型定義String方法，可以讓它滿足最廣泛使用之一的接口類型fmt.Stringer：
|
||||
除了io.Writer这个接口类型，还有另一个对fmt包很重要的接口类型。Fprintf和Fprintln函数向类型提供了一种控制它们值输出的途径。在2.5节中，我们为Celsius类型提供了一个String方法以便于可以打印成这样"100°C" ，在6.5节中我们给*IntSet添加一个String方法，这样集合可以用传统的符号来进行表示就像"{1 2 3}"。给一个类型定义String方法，可以让它满足最广泛使用之一的接口类型fmt.Stringer：
|
||||
|
||||
```go
|
||||
package fmt
|
||||
@@ -82,14 +82,14 @@ type Stringer interface {
|
||||
}
|
||||
```
|
||||
|
||||
我們會在7.10節解釋fmt包怎麽發現哪些值是滿足這個接口類型的。
|
||||
我们会在7.10节解释fmt包怎么发现哪些值是满足这个接口类型的。
|
||||
|
||||
**練習 7.1：** 使用來自ByteCounter的思路，實現一個針對對單詞和行數的計數器。你會發現bufio.ScanWords非常的有用。
|
||||
**练习 7.1：** 使用来自ByteCounter的思路，实现一个针对对单词和行数的计数器。你会发现bufio.ScanWords非常的有用。
|
||||
|
||||
**練習 7.2：** 寫一個帶有如下函數籤名的函數CountingWriter，傳入一個io.Writer接口類型，返迴一個新的Writer類型把原來的Writer封裝在里面和一個表示寫入新的Writer字節數的int64類型指針
|
||||
**练习 7.2：** 写一个带有如下函数签名的函数CountingWriter，传入一个io.Writer接口类型，返回一个新的Writer类型把原来的Writer封装在里面和一个表示写入新的Writer字节数的int64类型指针
|
||||
|
||||
```go
|
||||
func CountingWriter(w io.Writer) (io.Writer, *int64)
|
||||
```
|
||||
|
||||
**練習 7.3：** 爲在gopl.io/ch4/treesort (§4.4)的*tree類型實現一個String方法去展示tree類型的值序列。
|
||||
**练习 7.3：** 为在gopl.io/ch4/treesort (§4.4)的*tree类型实现一个String方法去展示tree类型的值序列。
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
## 7.2. 接口類型
|
||||
## 7.2. 接口类型
|
||||
|
||||
接口類型具體描述了一繫列方法的集合，一個實現了這些方法的具體類型是這個接口類型的實例。
|
||||
接口类型具体描述了一系列方法的集合，一个实现了这些方法的具体类型是这个接口类型的实例。
|
||||
|
||||
io.Writer類型是用的最廣泛的接口之一，因爲它提供了所有的類型寫入bytes的抽象，包括文件類型，內存緩衝區，網絡鏈接，HTTP客戶端，壓縮工具，哈希等等。io包中定義了很多其它有用的接口類型。Reader可以代表任意可以讀取bytes的類型，Closer可以是任意可以關閉的值，例如一個文件或是網絡鏈接。（到現在你可能註意到了很多Go語言中單方法接口的命名習慣）
|
||||
io.Writer类型是用的最广泛的接口之一，因为它提供了所有的类型写入bytes的抽象，包括文件类型，内存缓冲区，网络链接，HTTP客户端，压缩工具，哈希等等。io包中定义了很多其它有用的接口类型。Reader可以代表任意可以读取bytes的类型，Closer可以是任意可以关闭的值，例如一个文件或是网络链接。（到现在你可能注意到了很多Go语言中单方法接口的命名习惯）
|
||||
|
||||
```go
|
||||
package io
|
||||
@@ -14,7 +14,7 @@ type Closer interface {
|
||||
}
|
||||
```
|
||||
|
||||
在往下看，我們發現有些新的接口類型通過組合已經有的接口來定義。下面是兩個例子：
|
||||
在往下看，我们发现有些新的接口类型通过组合已经有的接口来定义。下面是两个例子：
|
||||
|
||||
```go
|
||||
type ReadWriter interface {
|
||||
@@ -27,7 +27,7 @@ type ReadWriteCloser interface {
|
||||
Closer
|
||||
}
|
||||
```
|
||||
上面用到的語法和結構內嵌相似，我們可以用這種方式以一個簡寫命名另一個接口，而不用聲明它所有的方法。這種方式本稱爲接口內嵌。盡管略失簡潔，我們可以像下面這樣，不使用內嵌來聲明io.Writer接口。
|
||||
上面用到的语法和结构内嵌相似，我们可以用这种方式以一个简写命名另一个接口，而不用声明它所有的方法。这种方式本称为接口内嵌。尽管略失简洁，我们可以像下面这样，不使用内嵌来声明io.Writer接口。
|
||||
|
||||
```go
|
||||
type ReadWriter interface {
|
||||
@@ -36,7 +36,7 @@ type ReadWriter interface {
|
||||
}
|
||||
```
|
||||
|
||||
或者甚至使用種混合的風格：
|
||||
或者甚至使用种混合的风格：
|
||||
|
||||
```go
|
||||
type ReadWriter interface {
|
||||
@@ -45,11 +45,11 @@ type ReadWriter interface {
|
||||
}
|
||||
```
|
||||
|
||||
上面3種定義方式都是一樣的效果。方法的順序變化也沒有影響，唯一重要的就是這個集合里面的方法。
|
||||
上面3种定义方式都是一样的效果。方法的顺序变化也没有影响，唯一重要的就是这个集合里面的方法。
|
||||
|
||||
**練習 7.4：** strings.NewReader函數通過讀取一個string參數返迴一個滿足io.Reader接口類型的值（和其它值）。實現一個簡單版本的NewReader，併用它來構造一個接收字符串輸入的HTML解析器（§5.2）
|
||||
**练习 7.4：** strings.NewReader函数通过读取一个string参数返回一个满足io.Reader接口类型的值（和其它值）。实现一个简单版本的NewReader，并用它来构造一个接收字符串输入的HTML解析器（§5.2）
|
||||
|
||||
**練習 7.5：** io包里面的LimitReader函數接收一個io.Reader接口類型的r和字節數n，併且返迴另一個從r中讀取字節但是當讀完n個字節後就表示讀到文件結束的Reader。實現這個LimitReader函數：
|
||||
**练习 7.5：** io包里面的LimitReader函数接收一个io.Reader接口类型的r和字节数n，并且返回另一个从r中读取字节但是当读完n个字节后就表示读到文件结束的Reader。实现这个LimitReader函数：
|
||||
|
||||
```go
|
||||
func LimitReader(r io.Reader, n int64) io.Reader
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
## 7.3. 實現接口的條件
|
||||
## 7.3. 实现接口的条件
|
||||
|
||||
一個類型如果擁有一個接口需要的所有方法，那麽這個類型就實現了這個接口。例如，\*os.File類型實現了io.Reader，Writer，Closer，和ReadWriter接口。\*bytes.Buffer實現了Reader，Writer，和ReadWriter這些接口，但是它沒有實現Closer接口因爲它不具有Close方法。Go的程序員經常會簡要的把一個具體的類型描述成一個特定的接口類型。舉個例子，\*bytes.Buffer是io.Writer；\*os.Files是io.ReadWriter。
|
||||
一个类型如果拥有一个接口需要的所有方法，那么这个类型就实现了这个接口。例如，\*os.File类型实现了io.Reader，Writer，Closer，和ReadWriter接口。\*bytes.Buffer实现了Reader，Writer，和ReadWriter这些接口，但是它没有实现Closer接口因为它不具有Close方法。Go的程序员经常会简要的把一个具体的类型描述成一个特定的接口类型。举个例子，\*bytes.Buffer是io.Writer；\*os.Files是io.ReadWriter。
|
||||
|
||||
接口指定的規則非常簡單：表達一個類型屬於某個接口隻要這個類型實現這個接口。所以：
|
||||
接口指定的规则非常简单：表达一个类型属于某个接口只要这个类型实现这个接口。所以：
|
||||
|
||||
```go
|
||||
var w io.Writer
|
||||
@@ -15,18 +15,18 @@ rwc = os.Stdout // OK: *os.File has Read, Write, Close methods
|
||||
rwc = new(bytes.Buffer) // compile error: *bytes.Buffer lacks Close method
|
||||
```
|
||||
|
||||
這個規則甚至適用於等式右邊本身也是一個接口類型
|
||||
这个规则甚至适用于等式右边本身也是一个接口类型
|
||||
|
||||
```go
|
||||
w = rwc // OK: io.ReadWriteCloser has Write method
|
||||
rwc = w // compile error: io.Writer lacks Close method
|
||||
```
|
||||
|
||||
因爲ReadWriter和ReadWriteCloser包含所有Writer的方法，所以任何實現了ReadWriter和ReadWriteCloser的類型必定也實現了Writer接口
|
||||
因为ReadWriter和ReadWriteCloser包含所有Writer的方法，所以任何实现了ReadWriter和ReadWriteCloser的类型必定也实现了Writer接口
|
||||
|
||||
在進一步學習前，必須先解釋表示一個類型持有一個方法當中的細節。迴想在6.2章中，對於每一個命名過的具體類型T；它一些方法的接收者是類型T本身然而另一些則是一個*T的指針。還記得在T類型的參數上調用一個*T的方法是合法的，隻要這個參數是一個變量；編譯器隱式的獲取了它的地址。但這僅僅是一個語法糖：T類型的值不擁有所有*T指針的方法，那這樣它就可能隻實現更少的接口。
|
||||
在进一步学习前，必须先解释表示一个类型持有一个方法当中的细节。回想在6.2章中，对于每一个命名过的具体类型T；它一些方法的接收者是类型T本身然而另一些则是一个*T的指针。还记得在T类型的参数上调用一个*T的方法是合法的，只要这个参数是一个变量；编译器隐式的获取了它的地址。但这仅仅是一个语法糖：T类型的值不拥有所有*T指针的方法，那这样它就可能只实现更少的接口。
|
||||
|
||||
舉個例子可能會更清晰一點。在第6.5章中，IntSet類型的String方法的接收者是一個指針類型，所以我們不能在一個不能尋址的IntSet值上調用這個方法：
|
||||
举个例子可能会更清晰一点。在第6.5章中，IntSet类型的String方法的接收者是一个指针类型，所以我们不能在一个不能寻址的IntSet值上调用这个方法：
|
||||
|
||||
```go
|
||||
type IntSet struct { /* ... */ }
|
||||
@@ -34,23 +34,23 @@ func (*IntSet) String() string
|
||||
var _ = IntSet{}.String() // compile error: String requires *IntSet receiver
|
||||
```
|
||||
|
||||
但是我們可以在一個IntSet值上調用這個方法：
|
||||
但是我们可以在一个IntSet值上调用这个方法：
|
||||
|
||||
```go
|
||||
var s IntSet
|
||||
var _ = s.String() // OK: s is a variable and &s has a String method
|
||||
```
|
||||
|
||||
然而，由於隻有*IntSet類型有String方法，所有也隻有*IntSet類型實現了fmt.Stringer接口：
|
||||
然而，由于只有*IntSet类型有String方法，所有也只有*IntSet类型实现了fmt.Stringer接口：
|
||||
|
||||
```go
|
||||
var _ fmt.Stringer = &s // OK
|
||||
var _ fmt.Stringer = s // compile error: IntSet lacks String method
|
||||
```
|
||||
|
||||
12.8章包含了一個打印出任意值的所有方法的程序，然後可以使用godoc -analysis=type tool(§10.7.4)展示每個類型的方法和具體類型和接口之間的關繫
|
||||
12.8章包含了一个打印出任意值的所有方法的程序，然后可以使用godoc -analysis=type tool(§10.7.4)展示每个类型的方法和具体类型和接口之间的关系
|
||||
|
||||
就像信封封裝和隱藏信件起來一樣，接口類型封裝和隱藏具體類型和它的值。卽使具體類型有其它的方法也隻有接口類型暴露出來的方法會被調用到：
|
||||
就像信封封装和隐藏信件起来一样，接口类型封装和隐藏具体类型和它的值。即使具体类型有其它的方法也只有接口类型暴露出来的方法会被调用到：
|
||||
|
||||
```go
|
||||
os.Stdout.Write([]byte("hello")) // OK: *os.File has Write method
|
||||
@@ -62,9 +62,9 @@ w.Write([]byte("hello")) // OK: io.Writer has Write method
|
||||
w.Close() // compile error: io.Writer lacks Close method
|
||||
```
|
||||
|
||||
一個有更多方法的接口類型，比如io.ReadWriter，和少一些方法的接口類型,例如io.Reader，進行對比；更多方法的接口類型會告訴我們更多關於它的值持有的信息，併且對實現它的類型要求更加嚴格。那麽關於interface{}類型，它沒有任何方法，請講出哪些具體的類型實現了它？
|
||||
一个有更多方法的接口类型，比如io.ReadWriter，和少一些方法的接口类型,例如io.Reader，进行对比；更多方法的接口类型会告诉我们更多关于它的值持有的信息，并且对实现它的类型要求更加严格。那么关于interface{}类型，它没有任何方法，请讲出哪些具体的类型实现了它？
|
||||
|
||||
這看上去好像沒有用，但實際上interface{}被稱爲空接口類型是不可或缺的。因爲空接口類型對實現它的類型沒有要求，所以我們可以將任意一個值賦給空接口類型。
|
||||
这看上去好像没有用，但实际上interface{}被称为空接口类型是不可或缺的。因为空接口类型对实现它的类型没有要求，所以我们可以将任意一个值赋给空接口类型。
|
||||
|
||||
```go
|
||||
var any interface{}
|
||||
@@ -75,29 +75,29 @@ any = map[string]int{"one": 1}
|
||||
any = new(bytes.Buffer)
|
||||
```
|
||||
|
||||
盡管不是很明顯，從本書最早的的例子中我們就已經在使用空接口類型。它允許像fmt.Println或者5.7章中的errorf函數接受任何類型的參數。
|
||||
尽管不是很明显，从本书最早的的例子中我们就已经在使用空接口类型。它允许像fmt.Println或者5.7章中的errorf函数接受任何类型的参数。
|
||||
|
||||
對於創建的一個interface{}值持有一個boolean，float，string，map，pointer，或者任意其它的類型；我們當然不能直接對它持有的值做操作，因爲interface{}沒有任何方法。我們會在7.10章中學到一種用類型斷言來獲取interface{}中值的方法。
|
||||
对于创建的一个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
|
||||
var w io.Writer = new(bytes.Buffer)
|
||||
```
|
||||
|
||||
因爲任意*bytes.Buffer的值，甚至包括nil通過(*bytes.Buffer)(nil)進行顯示的轉換都實現了這個接口，所以我們不必分配一個新的變量。併且因爲我們絶不會引用變量w，我們可以使用空標識符來來進行代替。總的看，這些變化可以讓我們得到一個更樸素的版本：
|
||||
因为任意*bytes.Buffer的值，甚至包括nil通过(*bytes.Buffer)(nil)进行显示的转换都实现了这个接口，所以我们不必分配一个新的变量。并且因为我们绝不会引用变量w，我们可以使用空标识符来来进行代替。总的看，这些变化可以让我们得到一个更朴素的版本：
|
||||
|
||||
```go
|
||||
// *bytes.Buffer must satisfy io.Writer
|
||||
var _ io.Writer = (*bytes.Buffer)(nil)
|
||||
```
|
||||
|
||||
非空的接口類型比如io.Writer經常被指針類型實現，尤其當一個或多個接口方法像Write方法那樣隱式的給接收者帶來變化的時候。一個結構體的指針是非常常見的承載方法的類型。
|
||||
非空的接口类型比如io.Writer经常被指针类型实现，尤其当一个或多个接口方法像Write方法那样隐式的给接收者带来变化的时候。一个结构体的指针是非常常见的承载方法的类型。
|
||||
|
||||
但是併不意味着隻有指針類型滿足接口類型，甚至連一些有設置方法的接口類型也可能會被Go語言中其它的引用類型實現。我們已經看過slice類型的方法(geometry.Path, §6.1)和map類型的方法(url.Values, §6.2.1)，後面還會看到函數類型的方法的例子(http.HandlerFunc, §7.7)。甚至基本的類型也可能會實現一些接口；就如我們在7.4章中看到的time.Duration類型實現了fmt.Stringer接口。
|
||||
但是并不意味着只有指针类型满足接口类型，甚至连一些有设置方法的接口类型也可能会被Go语言中其它的引用类型实现。我们已经看过slice类型的方法(geometry.Path, §6.1)和map类型的方法(url.Values, §6.2.1)，后面还会看到函数类型的方法的例子(http.HandlerFunc, §7.7)。甚至基本的类型也可能会实现一些接口；就如我们在7.4章中看到的time.Duration类型实现了fmt.Stringer接口。
|
||||
|
||||
一個具體的類型可能實現了很多不相關的接口。考慮在一個組織出售數字文化産品比如音樂，電影和書籍的程序中可能定義了下列的具體類型：
|
||||
一个具体的类型可能实现了很多不相关的接口。考虑在一个组织出售数字文化产品比如音乐，电影和书籍的程序中可能定义了下列的具体类型：
|
||||
|
||||
```
|
||||
Album
|
||||
@@ -109,7 +109,7 @@ TVEpisode
|
||||
Track
|
||||
```
|
||||
|
||||
我們可以把每個抽象的特點用接口來表示。一些特性對於所有的這些文化産品都是共通的，例如標題，創作日期和作者列表。
|
||||
我们可以把每个抽象的特点用接口来表示。一些特性对于所有的这些文化产品都是共通的，例如标题，创作日期和作者列表。
|
||||
|
||||
```go
|
||||
type Artifact interface {
|
||||
@@ -118,7 +118,7 @@ type Artifact interface {
|
||||
Created() time.Time
|
||||
}
|
||||
```
|
||||
其它的一些特性隻對特定類型的文化産品才有。和文字排版特性相關的隻有books和magazines，還有隻有movies和TV劇集和屏幕分辨率相關。
|
||||
其它的一些特性只对特定类型的文化产品才有。和文字排版特性相关的只有books和magazines，还有只有movies和TV剧集和屏幕分辨率相关。
|
||||
|
||||
```go
|
||||
type Text interface {
|
||||
@@ -139,7 +139,7 @@ type Video interface {
|
||||
}
|
||||
```
|
||||
|
||||
這些接口不止是一種有用的方式來分組相關的具體類型和表示他們之間的共同特定。我們後面可能會發現其它的分組。舉例，如果我們發現我們需要以同樣的方式處理Audio和Video，我們可以定義一個Streamer接口來代表它們之間相同的部分而不必對已經存在的類型做改變。
|
||||
这些接口不止是一种有用的方式来分组相关的具体类型和表示他们之间的共同特定。我们后面可能会发现其它的分组。举例，如果我们发现我们需要以同样的方式处理Audio和Video，我们可以定义一个Streamer接口来代表它们之间相同的部分而不必对已经存在的类型做改变。
|
||||
|
||||
```go
|
||||
type Streamer interface {
|
||||
@@ -149,4 +149,4 @@ type Streamer interface {
|
||||
}
|
||||
```
|
||||
|
||||
每一個具體類型的組基於它們相同的行爲可以表示成一個接口類型。不像基於類的語言，他們一個類實現的接口集合需要進行顯式的定義，在Go語言中我們可以在需要的時候定義一個新的抽象或者特定特點的組，而不需要脩改具體類型的定義。當具體的類型來自不同的作者時這種方式會特别有用。當然也確實沒有必要在具體的類型中指出這些共性。
|
||||
每一个具体类型的组基于它们相同的行为可以表示成一个接口类型。不像基于类的语言，他们一个类实现的接口集合需要进行显式的定义，在Go语言中我们可以在需要的时候定义一个新的抽象或者特定特点的组，而不需要修改具体类型的定义。当具体的类型来自不同的作者时这种方式会特别有用。当然也确实没有必要在具体的类型中指出这些共性。
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
## 7.4. flag.Value接口
|
||||
|
||||
在本章，我們會學到另一個標準的接口類型flag.Value是怎麽幫助命令行標記定義新的符號的。思考下面這個會休眠特定時間的程序：
|
||||
在本章，我们会学到另一个标准的接口类型flag.Value是怎么帮助命令行标记定义新的符号的。思考下面这个会休眠特定时间的程序：
|
||||
|
||||
<u></i>gopl.io/ch7/sleep</i></u>
|
||||
```go
|
||||
@@ -14,7 +14,7 @@ func main() {
|
||||
}
|
||||
```
|
||||
|
||||
在它休眠前它會打印出休眠的時間週期。fmt包調用time.Duration的String方法打印這個時間週期是以用戶友好的註解方式，而不是一個納秒數字：
|
||||
在它休眠前它会打印出休眠的时间周期。fmt包调用time.Duration的String方法打印这个时间周期是以用户友好的注解方式，而不是一个纳秒数字：
|
||||
|
||||
```
|
||||
$ go build gopl.io/ch7/sleep
|
||||
@@ -22,7 +22,7 @@ $ ./sleep
|
||||
Sleeping for 1s...
|
||||
```
|
||||
|
||||
默認情況下，休眠週期是一秒，但是可以通過 -period 這個命令行標記來控製。flag.Duration函數創建一個time.Duration類型的標記變量併且允許用戶通過多種用戶友好的方式來設置這個變量的大小，這種方式還包括和String方法相同的符號排版形式。這種對稱設計使得用戶交互良好。
|
||||
默认情况下，休眠周期是一秒，但是可以通过 -period 这个命令行标记来控制。flag.Duration函数创建一个time.Duration类型的标记变量并且允许用户通过多种用户友好的方式来设置这个变量的大小，这种方式还包括和String方法相同的符号排版形式。这种对称设计使得用户交互良好。
|
||||
|
||||
```
|
||||
$ ./sleep -period 50ms
|
||||
@@ -35,7 +35,7 @@ $ ./sleep -period "1 day"
|
||||
invalid value "1 day" for flag -period: time: invalid duration 1 day
|
||||
```
|
||||
|
||||
因爲時間週期標記值非常的有用，所以這個特性被構建到了flag包中；但是我們爲我們自己的數據類型定義新的標記符號是簡單容易的。我們隻需要定義一個實現flag.Value接口的類型，如下：
|
||||
因为时间周期标记值非常的有用，所以这个特性被构建到了flag包中；但是我们为我们自己的数据类型定义新的标记符号是简单容易的。我们只需要定义一个实现flag.Value接口的类型，如下：
|
||||
|
||||
```go
|
||||
package flag
|
||||
@@ -47,9 +47,9 @@ type Value interface {
|
||||
}
|
||||
```
|
||||
|
||||
String方法格式化標記的值用在命令行幫組消息中；這樣每一個flag.Value也是一個fmt.Stringer。Set方法解析它的字符串參數併且更新標記變量的值。實際上，Set方法和String是兩個相反的操作，所以最好的辦法就是對他們使用相同的註解方式。
|
||||
String方法格式化标记的值用在命令行帮组消息中；这样每一个flag.Value也是一个fmt.Stringer。Set方法解析它的字符串参数并且更新标记变量的值。实际上，Set方法和String是两个相反的操作，所以最好的办法就是对他们使用相同的注解方式。
|
||||
|
||||
讓我們定義一個允許通過攝氏度或者華氏溫度變換的形式指定溫度的celsiusFlag類型。註意celsiusFlag內嵌了一個Celsius類型(§2.5)，因此不用實現本身就已經有String方法了。爲了實現flag.Value，我們隻需要定義Set方法：
|
||||
让我们定义一个允许通过摄氏度或者华氏温度变换的形式指定温度的celsiusFlag类型。注意celsiusFlag内嵌了一个Celsius类型(§2.5)，因此不用实现本身就已经有String方法了。为了实现flag.Value，我们只需要定义Set方法：
|
||||
|
||||
<u><i>gopl.io/ch7/tempconv</i></u>
|
||||
```go
|
||||
@@ -72,9 +72,9 @@ func (f *celsiusFlag) Set(s string) error {
|
||||
}
|
||||
```
|
||||
|
||||
調用fmt.Sscanf函數從輸入s中解析一個浮點數（value）和一個字符串（unit）。雖然通常必須檢査Sscanf的錯誤返迴，但是在這個例子中我們不需要因爲如果有錯誤發生，就沒有switch case會匹配到。
|
||||
调用fmt.Sscanf函数从输入s中解析一个浮点数（value）和一个字符串（unit）。虽然通常必须检查Sscanf的错误返回，但是在这个例子中我们不需要因为如果有错误发生，就没有switch case会匹配到。
|
||||
|
||||
下面的CelsiusFlag函數將所有邏輯都封裝在一起。它返迴一個內嵌在celsiusFlag變量f中的Celsius指針給調用者。Celsius字段是一個會通過Set方法在標記處理的過程中更新的變量。調用Var方法將標記加入應用的命令行標記集合中，有異常複雜命令行接口的全局變量flag.CommandLine.Programs可能有幾個這個類型的變量。調用Var方法將一個*celsiusFlag參數賦值給一個flag.Value參數,導致編譯器去檢査*celsiusFlag是否有必須的方法。
|
||||
下面的CelsiusFlag函数将所有逻辑都封装在一起。它返回一个内嵌在celsiusFlag变量f中的Celsius指针给调用者。Celsius字段是一个会通过Set方法在标记处理的过程中更新的变量。调用Var方法将标记加入应用的命令行标记集合中，有异常复杂命令行接口的全局变量flag.CommandLine.Programs可能有几个这个类型的变量。调用Var方法将一个*celsiusFlag参数赋值给一个flag.Value参数,导致编译器去检查*celsiusFlag是否有必须的方法。
|
||||
|
||||
```go
|
||||
// CelsiusFlag defines a Celsius flag with the specified name,
|
||||
@@ -87,7 +87,7 @@ func CelsiusFlag(name string, value Celsius, usage string) *Celsius {
|
||||
}
|
||||
```
|
||||
|
||||
現在我們可以開始在我們的程序中使用新的標記：
|
||||
现在我们可以开始在我们的程序中使用新的标记：
|
||||
|
||||
<u><i>gopl.io/ch7/tempflag</i></u>
|
||||
```go
|
||||
@@ -99,7 +99,7 @@ func main() {
|
||||
}
|
||||
```
|
||||
|
||||
下面是典型的場景：
|
||||
下面是典型的场景：
|
||||
|
||||
```
|
||||
$ go build gopl.io/ch7/tempflag
|
||||
@@ -120,6 +120,6 @@ Usage of ./tempflag:
|
||||
the temperature (default 20°C)
|
||||
```
|
||||
|
||||
**練習 7.6：** 對tempFlag加入支持開爾文溫度。
|
||||
**练习 7.6：** 对tempFlag加入支持开尔文温度。
|
||||
|
||||
**練習 7.7：** 解釋爲什麽幫助信息在它的默認值是20.0沒有包含°C的情況下輸出了°C。
|
||||
**练习 7.7：** 解释为什么帮助信息在它的默认值是20.0没有包含°C的情况下输出了°C。
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
### 7.5.1. 警告：一個包含nil指針的接口不是nil接口
|
||||
### 7.5.1. 警告：一个包含nil指针的接口不是nil接口
|
||||
|
||||
一個不包含任何值的nil接口值和一個剛好包含nil指針的接口值是不同的。這個細微區别産生了一個容易絆倒每個Go程序員的陷阱。
|
||||
一个不包含任何值的nil接口值和一个刚好包含nil指针的接口值是不同的。这个细微区别产生了一个容易绊倒每个Go程序员的陷阱。
|
||||
|
||||
思考下面的程序。當debug變量設置爲true時，main函數會將f函數的輸出收集到一個bytes.Buffer類型中。
|
||||
思考下面的程序。当debug变量设置为true时，main函数会将f函数的输出收集到一个bytes.Buffer类型中。
|
||||
|
||||
```go
|
||||
const debug = true
|
||||
@@ -27,7 +27,7 @@ func f(out io.Writer) {
|
||||
}
|
||||
```
|
||||
|
||||
我們可能會預計當把變量debug設置爲false時可以禁止對輸出的收集，但是實際上在out.Write方法調用時程序發生了panic：
|
||||
我们可能会预计当把变量debug设置为false时可以禁止对输出的收集，但是实际上在out.Write方法调用时程序发生了panic：
|
||||
|
||||
```go
|
||||
if out != nil {
|
||||
@@ -35,13 +35,13 @@ if out != nil {
|
||||
}
|
||||
```
|
||||
|
||||
當main函數調用函數f時，它給f函數的out參數賦了一個\*bytes.Buffer的空指針，所以out的動態值是nil。然而，它的動態類型是\*bytes.Buffer，意思就是out變量是一個包含空指針值的非空接口（如圖7.5），所以防禦性檢査out!=nil的結果依然是true。
|
||||
当main函数调用函数f时，它给f函数的out参数赋了一个\*bytes.Buffer的空指针，所以out的动态值是nil。然而，它的动态类型是\*bytes.Buffer，意思就是out变量是一个包含空指针值的非空接口（如图7.5），所以防御性检查out!=nil的结果依然是true。
|
||||
|
||||
|
||||
|
||||
動態分配機製依然決定(\*bytes.Buffer).Write的方法會被調用，但是這次的接收者的值是nil。對於一些如\*os.File的類型，nil是一個有效的接收者(§6.2.1)，但是\*bytes.Buffer類型不在這些類型中。這個方法會被調用，但是當它嚐試去獲取緩衝區時會發生panic。
|
||||
动态分配机制依然决定(\*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
|
||||
@@ -51,4 +51,4 @@ if debug {
|
||||
f(buf) // OK
|
||||
```
|
||||
|
||||
現在我們已經把接口值的技巧都講完了，讓我們來看更多的一些在Go標準庫中的重要接口類型。在下面的三章中，我們會看到接口類型是怎樣用在排序，web服務，錯誤處理中的。
|
||||
现在我们已经把接口值的技巧都讲完了，让我们来看更多的一些在Go标准库中的重要接口类型。在下面的三章中，我们会看到接口类型是怎样用在排序，web服务，错误处理中的。
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
## 7.5. 接口值
|
||||
概念上講一個接口的值，接口值，由兩個部分組成，一個具體的類型和那個類型的值。它們被稱爲接口的動態類型和動態值。對於像Go語言這種靜態類型的語言，類型是編譯期的概念；因此一個類型不是一個值。在我們的概念模型中，一些提供每個類型信息的值被稱爲類型描述符，比如類型的名稱和方法。在一個接口值中，類型部分代表與之相關類型的描述符。
|
||||
概念上讲一个接口的值，接口值，由两个部分组成，一个具体的类型和那个类型的值。它们被称为接口的动态类型和动态值。对于像Go语言这种静态类型的语言，类型是编译期的概念；因此一个类型不是一个值。在我们的概念模型中，一些提供每个类型信息的值被称为类型描述符，比如类型的名称和方法。在一个接口值中，类型部分代表与之相关类型的描述符。
|
||||
|
||||
下面4個語句中，變量w得到了3個不同的值。（開始和最後的值是相同的）
|
||||
下面4个语句中，变量w得到了3个不同的值。（开始和最后的值是相同的）
|
||||
|
||||
```go
|
||||
var w io.Writer
|
||||
@@ -10,92 +10,92 @@ w = new(bytes.Buffer)
|
||||
w = nil
|
||||
```
|
||||
|
||||
讓我們進一步觀察在每一個語句後的w變量的值和動態行爲。第一個語句定義了變量w:
|
||||
让我们进一步观察在每一个语句后的w变量的值和动态行为。第一个语句定义了变量w:
|
||||
|
||||
```go
|
||||
var w io.Writer
|
||||
```
|
||||
|
||||
在Go語言中，變量總是被一個定義明確的值初始化，卽使接口類型也不例外。對於一個接口的零值就是它的類型和值的部分都是nil（圖7.1）。
|
||||
在Go语言中，变量总是被一个定义明确的值初始化，即使接口类型也不例外。对于一个接口的零值就是它的类型和值的部分都是nil（图7.1）。
|
||||
|
||||
|
||||
|
||||
一個接口值基於它的動態類型被描述爲空或非空，所以這是一個空的接口值。你可以通過使用w==nil或者w!=nil來判讀接口值是否爲空。調用一個空接口值上的任意方法都會産生panic:
|
||||
一个接口值基于它的动态类型被描述为空或非空，所以这是一个空的接口值。你可以通过使用w==nil或者w!=nil来判读接口值是否为空。调用一个空接口值上的任意方法都会产生panic:
|
||||
|
||||
```go
|
||||
w.Write([]byte("hello")) // panic: nil pointer dereference
|
||||
```
|
||||
|
||||
第二個語句將一個*os.File類型的值賦給變量w:
|
||||
第二个语句将一个*os.File类型的值赋给变量w:
|
||||
|
||||
```go
|
||||
w = os.Stdout
|
||||
```
|
||||
|
||||
這個賦值過程調用了一個具體類型到接口類型的隱式轉換，這和顯式的使用io.Writer(os.Stdout)是等價的。這類轉換不管是顯式的還是隱式的，都會刻畵出操作到的類型和值。這個接口值的動態類型被設爲*os.Stdout指針的類型描述符，它的動態值持有os.Stdout的拷貝；這是一個代表處理標準輸出的os.File類型變量的指針（圖7.2）。
|
||||
这个赋值过程调用了一个具体类型到接口类型的隐式转换，这和显式的使用io.Writer(os.Stdout)是等价的。这类转换不管是显式的还是隐式的，都会刻画出操作到的类型和值。这个接口值的动态类型被设为*os.Stdout指针的类型描述符，它的动态值持有os.Stdout的拷贝；这是一个代表处理标准输出的os.File类型变量的指针（图7.2）。
|
||||
|
||||
|
||||
|
||||
調用一個包含\*os.File類型指針的接口值的Write方法，使得(\*os.File).Write方法被調用。這個調用輸出“hello”。
|
||||
调用一个包含\*os.File类型指针的接口值的Write方法，使得(\*os.File).Write方法被调用。这个调用输出“hello”。
|
||||
|
||||
```go
|
||||
w.Write([]byte("hello")) // "hello"
|
||||
```
|
||||
|
||||
通常在編譯期，我們不知道接口值的動態類型是什麽，所以一個接口上的調用必須使用動態分配。因爲不是直接進行調用，所以編譯器必須把代碼生成在類型描述符的方法Write上，然後間接調用那個地址。這個調用的接收者是一個接口動態值的拷貝，os.Stdout。效果和下面這個直接調用一樣：
|
||||
通常在编译期，我们不知道接口值的动态类型是什么，所以一个接口上的调用必须使用动态分配。因为不是直接进行调用，所以编译器必须把代码生成在类型描述符的方法Write上，然后间接调用那个地址。这个调用的接收者是一个接口动态值的拷贝，os.Stdout。效果和下面这个直接调用一样：
|
||||
|
||||
```go
|
||||
os.Stdout.Write([]byte("hello")) // "hello"
|
||||
```
|
||||
|
||||
第三個語句給接口值賦了一個*bytes.Buffer類型的值
|
||||
第三个语句给接口值赋了一个*bytes.Buffer类型的值
|
||||
|
||||
```go
|
||||
w = new(bytes.Buffer)
|
||||
```
|
||||
|
||||
現在動態類型是*bytes.Buffer併且動態值是一個指向新分配的緩衝區的指針（圖7.3）。
|
||||
现在动态类型是*bytes.Buffer并且动态值是一个指向新分配的缓冲区的指针（图7.3）。
|
||||
|
||||
|
||||
|
||||
Write方法的調用也使用了和之前一樣的機製：
|
||||
Write方法的调用也使用了和之前一样的机制：
|
||||
|
||||
```go
|
||||
w.Write([]byte("hello")) // writes "hello" to the bytes.Buffers
|
||||
```
|
||||
|
||||
這次類型描述符是\*bytes.Buffer，所以調用了(\*bytes.Buffer).Write方法，併且接收者是該緩衝區的地址。這個調用把字符串“hello”添加到緩衝區中。
|
||||
这次类型描述符是\*bytes.Buffer，所以调用了(\*bytes.Buffer).Write方法，并且接收者是该缓冲区的地址。这个调用把字符串“hello”添加到缓冲区中。
|
||||
|
||||
最後，第四個語句將nil賦給了接口值：
|
||||
最后，第四个语句将nil赋给了接口值：
|
||||
|
||||
```go
|
||||
w = nil
|
||||
```
|
||||
|
||||
這個重置將它所有的部分都設爲nil值，把變量w恢複到和它之前定義時相同的狀態圖，在圖7.1中可以看到。
|
||||
这个重置将它所有的部分都设为nil值，把变量w恢复到和它之前定义时相同的状态图，在图7.1中可以看到。
|
||||
|
||||
一個接口值可以持有任意大的動態值。例如，表示時間實例的time.Time類型，這個類型有幾個對外不公開的字段。我們從它上面創建一個接口值,
|
||||
一个接口值可以持有任意大的动态值。例如，表示时间实例的time.Time类型，这个类型有几个对外不公开的字段。我们从它上面创建一个接口值,
|
||||
|
||||
```go
|
||||
var x interface{} = time.Now()
|
||||
```
|
||||
|
||||
結果可能和圖7.4相似。從概念上講，不論接口值多大，動態值總是可以容下它。（這隻是一個概念上的模型；具體的實現可能會非常不同）
|
||||
结果可能和图7.4相似。从概念上讲，不论接口值多大，动态值总是可以容下它。（这只是一个概念上的模型；具体的实现可能会非常不同）
|
||||
|
||||
|
||||
|
||||
接口值可以使用＝＝和！＝來進行比較。兩個接口值相等僅當它們都是nil值或者它們的動態類型相同併且動態值也根據這個動態類型的＝＝操作相等。因爲接口值是可比較的，所以它們可以用在map的鍵或者作爲switch語句的操作數。
|
||||
接口值可以使用＝＝和！＝来进行比较。两个接口值相等仅当它们都是nil值或者它们的动态类型相同并且动态值也根据这个动态类型的＝＝操作相等。因为接口值是可比较的，所以它们可以用在map的键或者作为switch语句的操作数。
|
||||
|
||||
然而，如果兩個接口值的動態類型相同，但是這個動態類型是不可比較的（比如切片），將它們進行比較就會失敗併且panic:
|
||||
然而，如果两个接口值的动态类型相同，但是这个动态类型是不可比较的（比如切片），将它们进行比较就会失败并且panic:
|
||||
|
||||
```go
|
||||
var x interface{} = []int{1, 2, 3}
|
||||
fmt.Println(x == x) // panic: comparing uncomparable type []int
|
||||
```
|
||||
|
||||
考慮到這點，接口類型是非常與衆不同的。其它類型要麽是安全的可比較類型（如基本類型和指針）要麽是完全不可比較的類型（如切片，映射類型，和函數），但是在比較接口值或者包含了接口值的聚合類型時，我們必須要意識到潛在的panic。同樣的風險也存在於使用接口作爲map的鍵或者switch的操作數。隻能比較你非常確定它們的動態值是可比較類型的接口值。
|
||||
考虑到这点，接口类型是非常与众不同的。其它类型要么是安全的可比较类型（如基本类型和指针）要么是完全不可比较的类型（如切片，映射类型，和函数），但是在比较接口值或者包含了接口值的聚合类型时，我们必须要意识到潜在的panic。同样的风险也存在于使用接口作为map的键或者switch的操作数。只能比较你非常确定它们的动态值是可比较类型的接口值。
|
||||
|
||||
當我們處理錯誤或者調試的過程中，得知接口值的動態類型是非常有幫助的。所以我們使用fmt包的%T動作:
|
||||
当我们处理错误或者调试的过程中，得知接口值的动态类型是非常有帮助的。所以我们使用fmt包的%T动作:
|
||||
|
||||
```go
|
||||
var w io.Writer
|
||||
@@ -106,6 +106,6 @@ w = new(bytes.Buffer)
|
||||
fmt.Printf("%T\n", w) // "*bytes.Buffer"
|
||||
```
|
||||
|
||||
在fmt包內部，使用反射來獲取接口動態類型的名稱。我們會在第12章中學到反射相關的知識。
|
||||
在fmt包内部，使用反射来获取接口动态类型的名称。我们会在第12章中学到反射相关的知识。
|
||||
|
||||
{% include "./ch7-05-1.md" %}
|
||||
|
||||
@@ -1,9 +1,9 @@
|
||||
## 7.6. sort.Interface接口
|
||||
排序操作和字符串格式化一樣是很多程序經常使用的操作。盡管一個最短的快排程序隻要15行就可以搞定，但是一個健壯的實現需要更多的代碼，併且我們不希望每次我們需要的時候都重寫或者拷貝這些代碼。
|
||||
排序操作和字符串格式化一样是很多程序经常使用的操作。尽管一个最短的快排程序只要15行就可以搞定，但是一个健壮的实现需要更多的代码，并且我们不希望每次我们需要的时候都重写或者拷贝这些代码。
|
||||
|
||||
幸運的是，sort包內置的提供了根據一些排序函數來對任何序列排序的功能。它的設計非常獨到。在很多語言中，排序算法都是和序列數據類型關聯，同時排序函數和具體類型元素關聯。相比之下，Go語言的sort.Sort函數不會對具體的序列和它的元素做任何假設。相反，它使用了一個接口類型sort.Interface來指定通用的排序算法和可能被排序到的序列類型之間的約定。這個接口的實現由序列的具體表示和它希望排序的元素決定，序列的表示經常是一個切片。
|
||||
幸运的是，sort包内置的提供了根据一些排序函数来对任何序列排序的功能。它的设计非常独到。在很多语言中，排序算法都是和序列数据类型关联，同时排序函数和具体类型元素关联。相比之下，Go语言的sort.Sort函数不会对具体的序列和它的元素做任何假设。相反，它使用了一个接口类型sort.Interface来指定通用的排序算法和可能被排序到的序列类型之间的约定。这个接口的实现由序列的具体表示和它希望排序的元素决定，序列的表示经常是一个切片。
|
||||
|
||||
一個內置的排序算法需要知道三個東西：序列的長度，表示兩個元素比較的結果，一種交換兩個元素的方式；這就是sort.Interface的三個方法：
|
||||
一个内置的排序算法需要知道三个东西：序列的长度，表示两个元素比较的结果，一种交换两个元素的方式；这就是sort.Interface的三个方法：
|
||||
|
||||
```go
|
||||
package sort
|
||||
@@ -15,7 +15,7 @@ type Interface interface {
|
||||
}
|
||||
```
|
||||
|
||||
爲了對序列進行排序，我們需要定義一個實現了這三個方法的類型，然後對這個類型的一個實例應用sort.Sort函數。思考對一個字符串切片進行排序，這可能是最簡單的例子了。下面是這個新的類型StringSlice和它的Len，Less和Swap方法
|
||||
为了对序列进行排序，我们需要定义一个实现了这三个方法的类型，然后对这个类型的一个实例应用sort.Sort函数。思考对一个字符串切片进行排序，这可能是最简单的例子了。下面是这个新的类型StringSlice和它的Len，Less和Swap方法
|
||||
|
||||
```go
|
||||
type StringSlice []string
|
||||
@@ -24,21 +24,21 @@ func (p StringSlice) Less(i, j int) bool { return p[i] < p[j] }
|
||||
func (p StringSlice) Swap(i, j int) { p[i], p[j] = p[j], p[i] }
|
||||
```
|
||||
|
||||
現在我們可以通過像下面這樣將一個切片轉換爲一個StringSlice類型來進行排序：
|
||||
现在我们可以通过像下面这样将一个切片转换为一个StringSlice类型来进行排序：
|
||||
|
||||
```go
|
||||
sort.Sort(StringSlice(names))
|
||||
```
|
||||
|
||||
這個轉換得到一個相同長度，容量，和基於names數組的切片值；併且這個切片值的類型有三個排序需要的方法。
|
||||
这个转换得到一个相同长度，容量，和基于names数组的切片值；并且这个切片值的类型有三个排序需要的方法。
|
||||
|
||||
對字符串切片的排序是很常用的需要，所以sort包提供了StringSlice類型，也提供了Strings函數能讓上面這些調用簡化成sort.Strings(names)。
|
||||
对字符串切片的排序是很常用的需要，所以sort包提供了StringSlice类型，也提供了Strings函数能让上面这些调用简化成sort.Strings(names)。
|
||||
|
||||
這里用到的技術很容易適用到其它排序序列中，例如我們可以忽略大些或者含有特殊的字符。（本書使用Go程序對索引詞和頁碼進行排序也用到了這個技術，對羅馬數字做了額外邏輯處理。）對於更複雜的排序，我們使用相同的方法，但是會用更複雜的數據結構和更複雜地實現sort.Interface的方法。
|
||||
这里用到的技术很容易适用到其它排序序列中，例如我们可以忽略大些或者含有特殊的字符。（本书使用Go程序对索引词和页码进行排序也用到了这个技术，对罗马数字做了额外逻辑处理。）对于更复杂的排序，我们使用相同的方法，但是会用更复杂的数据结构和更复杂地实现sort.Interface的方法。
|
||||
|
||||
我們會運行上面的例子來對一個表格中的音樂播放列表進行排序。每個track都是單獨的一行，每一列都是這個track的屬性像藝術家，標題，和運行時間。想象一個圖形用戶界面來呈現這個表格，併且點擊一個屬性的頂部會使這個列表按照這個屬性進行排序；再一次點擊相同屬性的頂部會進行逆向排序。讓我們看下每個點擊會發生什麽響應。
|
||||
我们会运行上面的例子来对一个表格中的音乐播放列表进行排序。每个track都是单独的一行，每一列都是这个track的属性像艺术家，标题，和运行时间。想象一个图形用户界面来呈现这个表格，并且点击一个属性的顶部会使这个列表按照这个属性进行排序；再一次点击相同属性的顶部会进行逆向排序。让我们看下每个点击会发生什么响应。
|
||||
|
||||
下面的變量tracks包好了一個播放列表。（One of the authors apologizes for the other author’s musical tastes.）每個元素都不是Track本身而是指向它的指針。盡管我們在下面的代碼中直接存儲Tracks也可以工作，sort函數會交換很多對元素，所以如果每個元素都是指針會更快而不是全部Track類型，指針是一個機器字碼長度而Track類型可能是八個或更多。
|
||||
下面的变量tracks包好了一个播放列表。（One of the authors apologizes for the other author’s musical tastes.）每个元素都不是Track本身而是指向它的指针。尽管我们在下面的代码中直接存储Tracks也可以工作，sort函数会交换很多对元素，所以如果每个元素都是指针会更快而不是全部Track类型，指针是一个机器字码长度而Track类型可能是八个或更多。
|
||||
|
||||
<u><i>gopl.io/ch7/sorting</i></u>
|
||||
```go
|
||||
@@ -66,7 +66,7 @@ func length(s string) time.Duration {
|
||||
}
|
||||
```
|
||||
|
||||
printTracks函數將播放列表打印成一個表格。一個圖形化的展示可能會更好點，但是這個小程序使用text/tabwriter包來生成一個列是整齊對齊和隔開的表格，像下面展示的這樣。註意到*tabwriter.Writer是滿足io.Writer接口的。它會收集每一片寫向它的數據；它的Flush方法會格式化整個表格併且將它寫向os.Stdout（標準輸出）。
|
||||
printTracks函数将播放列表打印成一个表格。一个图形化的展示可能会更好点，但是这个小程序使用text/tabwriter包来生成一个列是整齐对齐和隔开的表格，像下面展示的这样。注意到*tabwriter.Writer是满足io.Writer接口的。它会收集每一片写向它的数据；它的Flush方法会格式化整个表格并且将它写向os.Stdout（标准输出）。
|
||||
|
||||
```go
|
||||
func printTracks(tracks []*Track) {
|
||||
@@ -81,7 +81,7 @@ func printTracks(tracks []*Track) {
|
||||
}
|
||||
```
|
||||
|
||||
爲了能按照Artist字段對播放列表進行排序，我們會像對StringSlice那樣定義一個新的帶有必須Len，Less和Swap方法的切片類型。
|
||||
为了能按照Artist字段对播放列表进行排序，我们会像对StringSlice那样定义一个新的带有必须Len，Less和Swap方法的切片类型。
|
||||
|
||||
```go
|
||||
type byArtist []*Track
|
||||
@@ -90,13 +90,13 @@ func (x byArtist) Less(i, j int) bool { return x[i].Artist < x[j].Artist }
|
||||
func (x byArtist) Swap(i, j int) { x[i], x[j] = x[j], x[i] }
|
||||
```
|
||||
|
||||
爲了調用通用的排序程序，我們必須先將tracks轉換爲新的byArtist類型，它定義了具體的排序：
|
||||
为了调用通用的排序程序，我们必须先将tracks转换为新的byArtist类型，它定义了具体的排序：
|
||||
|
||||
```go
|
||||
sort.Sort(byArtist(tracks))
|
||||
```
|
||||
|
||||
在按照artist對這個切片進行排序後，printTrack的輸出如下
|
||||
在按照artist对这个切片进行排序后，printTrack的输出如下
|
||||
|
||||
```
|
||||
Title Artist Album Year Length
|
||||
@@ -107,13 +107,13 @@ Ready 2 Go Martin Solveig Smash 2011 4m24s
|
||||
Go Moby Moby 1992 3m37s
|
||||
```
|
||||
|
||||
如果用戶第二次請求“按照artist排序”，我們會對tracks進行逆向排序。然而我們不需要定義一個有顛倒Less方法的新類型byReverseArtist，因爲sort包中提供了Reverse函數將排序順序轉換成逆序。
|
||||
如果用户第二次请求“按照artist排序”，我们会对tracks进行逆向排序。然而我们不需要定义一个有颠倒Less方法的新类型byReverseArtist，因为sort包中提供了Reverse函数将排序顺序转换成逆序。
|
||||
|
||||
```go
|
||||
sort.Sort(sort.Reverse(byArtist(tracks)))
|
||||
```
|
||||
|
||||
在按照artist對這個切片進行逆向排序後，printTrack的輸出如下
|
||||
在按照artist对这个切片进行逆向排序后，printTrack的输出如下
|
||||
|
||||
```
|
||||
Title Artist Album Year Length
|
||||
@@ -124,7 +124,7 @@ Go Delilah From the Roots Up 2012 3m38s
|
||||
Go Ahead Alicia Keys As I Am 2007 4m36s
|
||||
```
|
||||
|
||||
sort.Reverse函數值得進行更近一步的學習因爲它使用了(§6.3)章中的組合，這是一個重要的思路。sort包定義了一個不公開的struct類型reverse，它嵌入了一個sort.Interface。reverse的Less方法調用了內嵌的sort.Interface值的Less方法，但是通過交換索引的方式使排序結果變成逆序。
|
||||
sort.Reverse函数值得进行更近一步的学习因为它使用了(§6.3)章中的组合，这是一个重要的思路。sort包定义了一个不公开的struct类型reverse，它嵌入了一个sort.Interface。reverse的Less方法调用了内嵌的sort.Interface值的Less方法，但是通过交换索引的方式使排序结果变成逆序。
|
||||
|
||||
```go
|
||||
package sort
|
||||
@@ -136,9 +136,9 @@ func (r reverse) Less(i, j int) bool { return r.Interface.Less(j, i) }
|
||||
func Reverse(data Interface) Interface { return reverse{data} }
|
||||
```
|
||||
|
||||
reverse的另外兩個方法Len和Swap隱式地由原有內嵌的sort.Interface提供。因爲reverse是一個不公開的類型，所以導出函數Reverse函數返迴一個包含原有sort.Interface值的reverse類型實例。
|
||||
reverse的另外两个方法Len和Swap隐式地由原有内嵌的sort.Interface提供。因为reverse是一个不公开的类型，所以导出函数Reverse函数返回一个包含原有sort.Interface值的reverse类型实例。
|
||||
|
||||
爲了可以按照不同的列進行排序，我們必須定義一個新的類型例如byYear：
|
||||
为了可以按照不同的列进行排序，我们必须定义一个新的类型例如byYear：
|
||||
|
||||
```go
|
||||
type byYear []*Track
|
||||
@@ -147,7 +147,7 @@ func (x byYear) Less(i, j int) bool { return x[i].Year < x[j].Year }
|
||||
func (x byYear) Swap(i, j int) { x[i], x[j] = x[j], x[i] }
|
||||
```
|
||||
|
||||
在使用sort.Sort(byYear(tracks))按照年對tracks進行排序後，printTrack展示了一個按時間先後順序的列表：
|
||||
在使用sort.Sort(byYear(tracks))按照年对tracks进行排序后，printTrack展示了一个按时间先后顺序的列表：
|
||||
|
||||
```
|
||||
Title Artist Album Year Length
|
||||
@@ -158,7 +158,7 @@ Ready 2 Go Martin Solveig Smash 2011 4m24s
|
||||
Go Delilah From the Roots Up 2012 3m38s
|
||||
```
|
||||
|
||||
對於我們需要的每個切片元素類型和每個排序函數，我們需要定義一個新的sort.Interface實現。如你所見，Len和Swap方法對於所有的切片類型都有相同的定義。下個例子，具體的類型customSort會將一個切片和函數結合，使我們隻需要寫比較函數就可以定義一個新的排序。順便説下，實現了sort.Interface的具體類型不一定是切片類型；customSort是一個結構體類型。
|
||||
对于我们需要的每个切片元素类型和每个排序函数，我们需要定义一个新的sort.Interface实现。如你所见，Len和Swap方法对于所有的切片类型都有相同的定义。下个例子，具体的类型customSort会将一个切片和函数结合，使我们只需要写比较函数就可以定义一个新的排序。顺便说下，实现了sort.Interface的具体类型不一定是切片类型；customSort是一个结构体类型。
|
||||
|
||||
```go
|
||||
type customSort struct {
|
||||
@@ -171,7 +171,7 @@ func (x customSort) Less(i, j int) bool { return x.less(x.t[i], x.t[j]) }
|
||||
func (x customSort) Swap(i, j int) { x.t[i], x.t[j] = x.t[j], x.t[i] }
|
||||
```
|
||||
|
||||
讓我們定義一個多層的排序函數，它主要的排序鍵是標題，第二個鍵是年，第三個鍵是運行時間Length。下面是該排序的調用，其中這個排序使用了匿名排序函數：
|
||||
让我们定义一个多层的排序函数，它主要的排序键是标题，第二个键是年，第三个键是运行时间Length。下面是该排序的调用，其中这个排序使用了匿名排序函数：
|
||||
|
||||
```go
|
||||
sort.Sort(customSort{tracks, func(x, y *Track) bool {
|
||||
@@ -188,7 +188,7 @@ sort.Sort(customSort{tracks, func(x, y *Track) bool {
|
||||
}})
|
||||
```
|
||||
|
||||
這下面是排序的結果。註意到兩個標題是“Go”的track按照標題排序是相同的順序，但是在按照year排序上更久的那個track優先。
|
||||
这下面是排序的结果。注意到两个标题是“Go”的track按照标题排序是相同的顺序，但是在按照year排序上更久的那个track优先。
|
||||
|
||||
```
|
||||
Title Artist Album Year Length
|
||||
@@ -199,7 +199,7 @@ Go Ahead Alicia Keys As I Am 2007 4m36s
|
||||
Ready 2 Go Martin Solveig Smash 2011 4m24s
|
||||
```
|
||||
|
||||
盡管對長度爲n的序列排序需要 O(n log n)次比較操作，檢査一個序列是否已經有序至少需要n−1次比較。sort包中的IsSorted函數幫我們做這樣的檢査。像sort.Sort一樣，它也使用sort.Interface對這個序列和它的排序函數進行抽象，但是它從不會調用Swap方法：這段代碼示范了IntsAreSorted和Ints函數和IntSlice類型的使用：
|
||||
尽管对长度为n的序列排序需要 O(n log n)次比较操作，检查一个序列是否已经有序至少需要n−1次比较。sort包中的IsSorted函数帮我们做这样的检查。像sort.Sort一样，它也使用sort.Interface对这个序列和它的排序函数进行抽象，但是它从不会调用Swap方法：这段代码示范了IntsAreSorted和Ints函数和IntSlice类型的使用：
|
||||
|
||||
```go
|
||||
values := []int{3, 1, 4, 1}
|
||||
@@ -212,10 +212,10 @@ fmt.Println(values) // "[4 3 1 1]"
|
||||
fmt.Println(sort.IntsAreSorted(values)) // "false"
|
||||
```
|
||||
|
||||
爲了使用方便，sort包爲[]int,[]string和[]float64的正常排序提供了特定版本的函數和類型。對於其他類型，例如[]int64或者[]uint，盡管路徑也很簡單，還是依賴我們自己實現。
|
||||
为了使用方便，sort包为[]int,[]string和[]float64的正常排序提供了特定版本的函数和类型。对于其他类型，例如[]int64或者[]uint，尽管路径也很简单，还是依赖我们自己实现。
|
||||
|
||||
**練習 7.8：** 很多圖形界面提供了一個有狀態的多重排序表格插件：主要的排序鍵是最近一次點擊過列頭的列，第二個排序鍵是第二最近點擊過列頭的列，等等。定義一個sort.Interface的實現用在這樣的表格中。比較這個實現方式和重複使用sort.Stable來排序的方式。
|
||||
**练习 7.8：** 很多图形界面提供了一个有状态的多重排序表格插件：主要的排序键是最近一次点击过列头的列，第二个排序键是第二最近点击过列头的列，等等。定义一个sort.Interface的实现用在这样的表格中。比较这个实现方式和重复使用sort.Stable来排序的方式。
|
||||
|
||||
**練習 7.9：** 使用html/template包 (§4.6) 替代printTracks將tracks展示成一個HTML表格。將這個解決方案用在前一個練習中，讓每次點擊一個列的頭部産生一個HTTP請求來排序這個表格。
|
||||
**练习 7.9：** 使用html/template包 (§4.6) 替代printTracks将tracks展示成一个HTML表格。将这个解决方案用在前一个练习中，让每次点击一个列的头部产生一个HTTP请求来排序这个表格。
|
||||
|
||||
**練習 7.10：** sort.Interface類型也可以適用在其它地方。編寫一個IsPalindrome(s sort.Interface) bool函數表明序列s是否是迴文序列，換句話説反向排序不會改變這個序列。假設如果!s.Less(i, j) && !s.Less(j, i)則索引i和j上的元素相等。
|
||||
**练习 7.10：** sort.Interface类型也可以适用在其它地方。编写一个IsPalindrome(s sort.Interface) bool函数表明序列s是否是回文序列，换句话说反向排序不会改变这个序列。假设如果!s.Less(i, j) && !s.Less(j, i)则索引i和j上的元素相等。
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
## 7.7. http.Handler接口
|
||||
|
||||
在第一章中，我們粗略的了解了怎麽用net/http包去實現網絡客戶端(§1.5)和服務器(§1.7)。在這個小節中，我們會對那些基於http.Handler接口的服務器API做更進一步的學習：
|
||||
在第一章中，我们粗略的了解了怎么用net/http包去实现网络客户端(§1.5)和服务器(§1.7)。在这个小节中，我们会对那些基于http.Handler接口的服务器API做更进一步的学习：
|
||||
|
||||
<u><i>net/http</i></u>
|
||||
```go
|
||||
@@ -13,9 +13,9 @@ type Handler interface {
|
||||
func ListenAndServe(address string, h Handler) error
|
||||
```
|
||||
|
||||
ListenAndServe函數需要一個例如“localhost:8000”的服務器地址，和一個所有請求都可以分派的Handler接口實例。它會一直運行，直到這個服務因爲一個錯誤而失敗（或者啟動失敗），它的返迴值一定是一個非空的錯誤。
|
||||
ListenAndServe函数需要一个例如“localhost:8000”的服务器地址，和一个所有请求都可以分派的Handler接口实例。它会一直运行，直到这个服务因为一个错误而失败（或者启动失败），它的返回值一定是一个非空的错误。
|
||||
|
||||
想象一個電子商務網站，爲了銷售它的數據庫將它物品的價格映射成美元。下面這個程序可能是能想到的最簡單的實現了。它將庫存清單模型化爲一個命名爲database的map類型，我們給這個類型一個ServeHttp方法，這樣它可以滿足http.Handler接口。這個handler會遍歷整個map併輸出物品信息。
|
||||
想象一个电子商务网站，为了销售它的数据库将它物品的价格映射成美元。下面这个程序可能是能想到的最简单的实现了。它将库存清单模型化为一个命名为database的map类型，我们给这个类型一个ServeHttp方法，这样它可以满足http.Handler接口。这个handler会遍历整个map并输出物品信息。
|
||||
|
||||
<u><i>gopl.io/ch7/http1</i></u>
|
||||
```go
|
||||
@@ -37,14 +37,14 @@ func (db database) ServeHTTP(w http.ResponseWriter, req *http.Request) {
|
||||
}
|
||||
```
|
||||
|
||||
如果我們啟動這個服務，
|
||||
如果我们启动这个服务，
|
||||
|
||||
```
|
||||
$ go build gopl.io/ch7/http1
|
||||
$ ./http1 &
|
||||
```
|
||||
|
||||
然後用1.5節中的獲取程序（如果你更喜歡可以使用web瀏覽器）來連接服務器,我們得到下面的輸出：
|
||||
然后用1.5节中的获取程序（如果你更喜欢可以使用web浏览器）来连接服务器,我们得到下面的输出：
|
||||
|
||||
```
|
||||
$ go build gopl.io/ch1/fetch
|
||||
@@ -53,7 +53,7 @@ shoes: $50.00
|
||||
socks: $5.00
|
||||
```
|
||||
|
||||
目前爲止，這個服務器不考慮URL隻能爲每個請求列出它全部的庫存清單。更眞實的服務器會定義多個不同的URL，每一個都會觸發一個不同的行爲。讓我們使用/list來調用已經存在的這個行爲併且增加另一個/price調用表明單個貨品的價格，像這樣/price?item=socks來指定一個請求參數。
|
||||
目前为止，这个服务器不考虑URL只能为每个请求列出它全部的库存清单。更真实的服务器会定义多个不同的URL，每一个都会触发一个不同的行为。让我们使用/list来调用已经存在的这个行为并且增加另一个/price调用表明单个货品的价格，像这样/price?item=socks来指定一个请求参数。
|
||||
|
||||
<u><i>gopl.io/ch7/http2</i></u>
|
||||
```go
|
||||
@@ -79,16 +79,16 @@ func (db database) ServeHTTP(w http.ResponseWriter, req *http.Request) {
|
||||
}
|
||||
```
|
||||
|
||||
現在handler基於URL的路徑部分（req.URL.Path）來決定執行什麽邏輯。如果這個handler不能識别這個路徑，它會通過調用w.WriteHeader(http.StatusNotFound)返迴客戶端一個HTTP錯誤；這個檢査應該在向w寫入任何值前完成。（順便提一下，http.ResponseWriter是另一個接口。它在io.Writer上增加了發送HTTP相應頭的方法。）等效地，我們可以使用實用的http.Error函數：
|
||||
现在handler基于URL的路径部分（req.URL.Path）来决定执行什么逻辑。如果这个handler不能识别这个路径，它会通过调用w.WriteHeader(http.StatusNotFound)返回客户端一个HTTP错误；这个检查应该在向w写入任何值前完成。（顺便提一下，http.ResponseWriter是另一个接口。它在io.Writer上增加了发送HTTP相应头的方法。）等效地，我们可以使用实用的http.Error函数：
|
||||
|
||||
```go
|
||||
msg := fmt.Sprintf("no such page: %s\n", req.URL)
|
||||
http.Error(w, msg, http.StatusNotFound) // 404
|
||||
```
|
||||
|
||||
/price的case會調用URL的Query方法來將HTTP請求參數解析爲一個map，或者更準確地説一個net/url包中url.Values(§6.2.1)類型的多重映射。然後找到第一個item參數併査找它的價格。如果這個貨品沒有找到會返迴一個錯誤。
|
||||
/price的case会调用URL的Query方法来将HTTP请求参数解析为一个map，或者更准确地说一个net/url包中url.Values(§6.2.1)类型的多重映射。然后找到第一个item参数并查找它的价格。如果这个货品没有找到会返回一个错误。
|
||||
|
||||
這里是一個和新服務器會話的例子：
|
||||
这里是一个和新服务器会话的例子：
|
||||
|
||||
```
|
||||
$ go build gopl.io/ch7/http2
|
||||
@@ -107,12 +107,12 @@ $ ./fetch http://localhost:8000/help
|
||||
no such page: /help
|
||||
```
|
||||
|
||||
顯然我們可以繼續向ServeHTTP方法中添加case，但在一個實際的應用中，將每個case中的邏輯定義到一個分開的方法或函數中會很實用。此外，相近的URL可能需要相似的邏輯；例如幾個圖片文件可能有形如/images/\*.png的URL。因爲這些原因，net/http包提供了一個請求多路器ServeMux來簡化URL和handlers的聯繫。一個ServeMux將一批http.Handler聚集到一個單一的http.Handler中。再一次，我們可以看到滿足同一接口的不同類型是可替換的：web服務器將請求指派給任意的http.Handler
|
||||
而不需要考慮它後面的具體類型。
|
||||
显然我们可以继续向ServeHTTP方法中添加case，但在一个实际的应用中，将每个case中的逻辑定义到一个分开的方法或函数中会很实用。此外，相近的URL可能需要相似的逻辑；例如几个图片文件可能有形如/images/\*.png的URL。因为这些原因，net/http包提供了一个请求多路器ServeMux来简化URL和handlers的联系。一个ServeMux将一批http.Handler聚集到一个单一的http.Handler中。再一次，我们可以看到满足同一接口的不同类型是可替换的：web服务器将请求指派给任意的http.Handler
|
||||
而不需要考虑它后面的具体类型。
|
||||
|
||||
對於更複雜的應用，一些ServeMux可以通過組合來處理更加錯綜複雜的路由需求。Go語言目前沒有一個權威的web框架，就像Ruby語言有Rails和python有Django。這併不是説這樣的框架不存在，而是Go語言標準庫中的構建模塊就已經非常靈活以至於這些框架都是不必要的。此外，盡管在一個項目早期使用框架是非常方便的，但是它們帶來額外的複雜度會使長期的維護更加睏難。
|
||||
对于更复杂的应用，一些ServeMux可以通过组合来处理更加错综复杂的路由需求。Go语言目前没有一个权威的web框架，就像Ruby语言有Rails和python有Django。这并不是说这样的框架不存在，而是Go语言标准库中的构建模块就已经非常灵活以至于这些框架都是不必要的。此外，尽管在一个项目早期使用框架是非常方便的，但是它们带来额外的复杂度会使长期的维护更加困难。
|
||||
|
||||
在下面的程序中，我們創建一個ServeMux併且使用它將URL和相應處理/list和/price操作的handler聯繫起來，這些操作邏輯都已經被分到不同的方法中。然後我門在調用ListenAndServe函數中使用ServeMux最爲主要的handler。
|
||||
在下面的程序中，我们创建一个ServeMux并且使用它将URL和相应处理/list和/price操作的handler联系起来，这些操作逻辑都已经被分到不同的方法中。然后我门在调用ListenAndServe函数中使用ServeMux最为主要的handler。
|
||||
|
||||
<u><i>gopl.io/ch7/http3</i></u>
|
||||
```go
|
||||
@@ -144,15 +144,15 @@ func (db database) price(w http.ResponseWriter, req *http.Request) {
|
||||
}
|
||||
```
|
||||
|
||||
讓我們關註這兩個註冊到handlers上的調用。第一個db.list是一個方法值 (§6.4)，它是下面這個類型的值
|
||||
让我们关注这两个注册到handlers上的调用。第一个db.list是一个方法值 (§6.4)，它是下面这个类型的值
|
||||
|
||||
```go
|
||||
func(w http.ResponseWriter, req *http.Request)
|
||||
```
|
||||
|
||||
也就是説db.list的調用會援引一個接收者是db的database.list方法。所以db.list是一個實現了handler類似行爲的函數，但是因爲它沒有方法，所以它不滿足http.Handler接口併且不能直接傳給mux.Handle。
|
||||
也就是说db.list的调用会援引一个接收者是db的database.list方法。所以db.list是一个实现了handler类似行为的函数，但是因为它没有方法，所以它不满足http.Handler接口并且不能直接传给mux.Handle。
|
||||
|
||||
語句http.HandlerFunc(db.list)是一個轉換而非一個函數調用，因爲http.HandlerFunc是一個類型。它有如下的定義：
|
||||
语句http.HandlerFunc(db.list)是一个转换而非一个函数调用，因为http.HandlerFunc是一个类型。它有如下的定义：
|
||||
|
||||
<u><i>net/http</i></u>
|
||||
```go
|
||||
@@ -165,9 +165,9 @@ func (f HandlerFunc) ServeHTTP(w ResponseWriter, r *Request) {
|
||||
}
|
||||
```
|
||||
|
||||
HandlerFunc顯示了在Go語言接口機製中一些不同尋常的特點。這是一個有實現了接口http.Handler方法的函數類型。ServeHTTP方法的行爲調用了它本身的函數。因此HandlerFunc是一個讓函數值滿足一個接口的適配器，這里函數和這個接口僅有的方法有相同的函數籤名。實際上，這個技巧讓一個單一的類型例如database以多種方式滿足http.Handler接口：一種通過它的list方法，一種通過它的price方法等等。
|
||||
HandlerFunc显示了在Go语言接口机制中一些不同寻常的特点。这是一个有实现了接口http.Handler方法的函数类型。ServeHTTP方法的行为调用了它本身的函数。因此HandlerFunc是一个让函数值满足一个接口的适配器，这里函数和这个接口仅有的方法有相同的函数签名。实际上，这个技巧让一个单一的类型例如database以多种方式满足http.Handler接口：一种通过它的list方法，一种通过它的price方法等等。
|
||||
|
||||
因爲handler通過這種方式註冊非常普遍，ServeMux有一個方便的HandleFunc方法，它幫我們簡化handler註冊代碼成這樣：
|
||||
因为handler通过这种方式注册非常普遍，ServeMux有一个方便的HandleFunc方法，它帮我们简化handler注册代码成这样：
|
||||
|
||||
<u><i>gopl.io/ch7/http3a</i></u>
|
||||
```go
|
||||
@@ -175,11 +175,11 @@ mux.HandleFunc("/list", db.list)
|
||||
mux.HandleFunc("/price", db.price)
|
||||
```
|
||||
|
||||
從上面的代碼很容易看出應該怎麽構建一個程序，它有兩個不同的web服務器監聽不同的端口的，併且定義不同的URL將它們指派到不同的handler。我們隻要構建另外一個ServeMux併且在調用一次ListenAndServe（可能併行的）。但是在大多數程序中，一個web服務器就足夠了。此外，在一個應用程序的多個文件中定義HTTP handler也是非常典型的，如果它們必須全部都顯示的註冊到這個應用的ServeMux實例上會比較麻煩。
|
||||
从上面的代码很容易看出应该怎么构建一个程序，它有两个不同的web服务器监听不同的端口的，并且定义不同的URL将它们指派到不同的handler。我们只要构建另外一个ServeMux并且在调用一次ListenAndServe（可能并行的）。但是在大多数程序中，一个web服务器就足够了。此外，在一个应用程序的多个文件中定义HTTP handler也是非常典型的，如果它们必须全部都显示的注册到这个应用的ServeMux实例上会比较麻烦。
|
||||
|
||||
所以爲了方便，net/http包提供了一個全局的ServeMux實例DefaultServerMux和包級别的http.Handle和http.HandleFunc函數。現在，爲了使用DefaultServeMux作爲服務器的主handler，我們不需要將它傳給ListenAndServe函數；nil值就可以工作。
|
||||
所以为了方便，net/http包提供了一个全局的ServeMux实例DefaultServerMux和包级别的http.Handle和http.HandleFunc函数。现在，为了使用DefaultServeMux作为服务器的主handler，我们不需要将它传给ListenAndServe函数；nil值就可以工作。
|
||||
|
||||
然後服務器的主函數可以簡化成：
|
||||
然后服务器的主函数可以简化成：
|
||||
|
||||
<u><i>gopl.io/ch7/http4</i></u>
|
||||
```go
|
||||
@@ -191,8 +191,8 @@ func main() {
|
||||
}
|
||||
```
|
||||
|
||||
最後，一個重要的提示：就像我們在1.7節中提到的，web服務器在一個新的協程中調用每一個handler，所以當handler獲取其它協程或者這個handler本身的其它請求也可以訪問的變量時一定要使用預防措施比如鎖機製。我們後面的兩章中講到併發相關的知識。
|
||||
最后，一个重要的提示：就像我们在1.7节中提到的，web服务器在一个新的协程中调用每一个handler，所以当handler获取其它协程或者这个handler本身的其它请求也可以访问的变量时一定要使用预防措施比如锁机制。我们后面的两章中讲到并发相关的知识。
|
||||
|
||||
**練習 7.11：** 增加額外的handler讓客服端可以創建，讀取，更新和刪除數據庫記録。例如，一個形如 `/update?item=socks&price=6` 的請求會更新庫存清單里一個貨品的價格併且當這個貨品不存在或價格無效時返迴一個錯誤值。（註意：這個脩改會引入變量同時更新的問題）
|
||||
**练习 7.11：** 增加额外的handler让客服端可以创建，读取，更新和删除数据库记录。例如，一个形如 `/update?item=socks&price=6` 的请求会更新库存清单里一个货品的价格并且当这个货品不存在或价格无效时返回一个错误值。（注意：这个修改会引入变量同时更新的问题）
|
||||
|
||||
**練習 7.12：** 脩改/list的handler讓它把輸出打印成一個HTML的表格而不是文本。html/template包(§4.6)可能會對你有幫助。
|
||||
**练习 7.12：** 修改/list的handler让它把输出打印成一个HTML的表格而不是文本。html/template包(§4.6)可能会对你有帮助。
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
## 7.8. error接口
|
||||
|
||||
從本書的開始，我們就已經創建和使用過神祕的預定義error類型，而且沒有解釋它究竟是什麽。實際上它就是interface類型，這個類型有一個返迴錯誤信息的單一方法：
|
||||
从本书的开始，我们就已经创建和使用过神秘的预定义error类型，而且没有解释它究竟是什么。实际上它就是interface类型，这个类型有一个返回错误信息的单一方法：
|
||||
|
||||
```go
|
||||
type error interface {
|
||||
@@ -8,7 +8,7 @@ type error interface {
|
||||
}
|
||||
```
|
||||
|
||||
創建一個error最簡單的方法就是調用errors.New函數，它會根據傳入的錯誤信息返迴一個新的error。整個errors包僅隻有4行：
|
||||
创建一个error最简单的方法就是调用errors.New函数，它会根据传入的错误信息返回一个新的error。整个errors包仅只有4行：
|
||||
|
||||
```go
|
||||
package errors
|
||||
@@ -20,13 +20,13 @@ type errorString struct { text string }
|
||||
func (e *errorString) Error() string { return e.text }
|
||||
```
|
||||
|
||||
承載errorString的類型是一個結構體而非一個字符串，這是爲了保護它表示的錯誤避免粗心（或有意）的更新。併且因爲是指針類型*errorString滿足error接口而非errorString類型，所以每個New函數的調用都分配了一個獨特的和其他錯誤不相同的實例。我們也不想要重要的error例如io.EOF和一個剛好有相同錯誤消息的error比較後相等。
|
||||
承载errorString的类型是一个结构体而非一个字符串，这是为了保护它表示的错误避免粗心（或有意）的更新。并且因为是指针类型*errorString满足error接口而非errorString类型，所以每个New函数的调用都分配了一个独特的和其他错误不相同的实例。我们也不想要重要的error例如io.EOF和一个刚好有相同错误消息的error比较后相等。
|
||||
|
||||
```go
|
||||
fmt.Println(errors.New("EOF") == errors.New("EOF")) // "false"
|
||||
```
|
||||
|
||||
調用errors.New函數是非常稀少的，因爲有一個方便的封裝函數fmt.Errorf，它還會處理字符串格式化。我們曾多次在第5章中用到它。
|
||||
调用errors.New函数是非常稀少的，因为有一个方便的封装函数fmt.Errorf，它还会处理字符串格式化。我们曾多次在第5章中用到它。
|
||||
|
||||
```go
|
||||
package fmt
|
||||
@@ -38,7 +38,7 @@ func Errorf(format string, args ...interface{}) error {
|
||||
}
|
||||
```
|
||||
|
||||
雖然*errorString可能是最簡單的錯誤類型，但遠非隻有它一個。例如，syscall包提供了Go語言底層繫統調用API。在多個平台上，它定義一個實現error接口的數字類型Errno，併且在Unix平台上，Errno的Error方法會從一個字符串表中査找錯誤消息，如下面展示的這樣：
|
||||
虽然*errorString可能是最简单的错误类型，但远非只有它一个。例如，syscall包提供了Go语言底层系统调用API。在多个平台上，它定义一个实现error接口的数字类型Errno，并且在Unix平台上，Errno的Error方法会从一个字符串表中查找错误消息，如下面展示的这样：
|
||||
|
||||
```go
|
||||
package syscall
|
||||
@@ -60,7 +60,7 @@ func (e Errno) Error() string {
|
||||
}
|
||||
```
|
||||
|
||||
下面的語句創建了一個持有Errno值爲2的接口值，表示POSIX ENOENT狀況：
|
||||
下面的语句创建了一个持有Errno值为2的接口值，表示POSIX ENOENT状况：
|
||||
|
||||
```go
|
||||
var err error = syscall.Errno(2)
|
||||
@@ -68,8 +68,8 @@ fmt.Println(err.Error()) // "no such file or directory"
|
||||
fmt.Println(err) // "no such file or directory"
|
||||
```
|
||||
|
||||
err的值圖形化的呈現在圖7.6中。
|
||||
err的值图形化的呈现在图7.6中。
|
||||
|
||||
|
||||
|
||||
Errno是一個繫統調用錯誤的高效表示方式，它通過一個有限的集合進行描述，併且它滿足標準的錯誤接口。我們會在第7.11節了解到其它滿足這個接口的類型。
|
||||
Errno是一个系统调用错误的高效表示方式，它通过一个有限的集合进行描述，并且它满足标准的错误接口。我们会在第7.11节了解到其它满足这个接口的类型。
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
## 7.9. 示例: 表達式求值
|
||||
## 7.9. 示例: 表达式求值
|
||||
|
||||
在本節中，我們會構建一個簡單算術表達式的求值器。我們將使用一個接口Expr來表示Go語言中任意的表達式。現在這個接口不需要有方法，但是我們後面會爲它增加一些。
|
||||
在本节中，我们会构建一个简单算术表达式的求值器。我们将使用一个接口Expr来表示Go语言中任意的表达式。现在这个接口不需要有方法，但是我们后面会为它增加一些。
|
||||
|
||||
```go
|
||||
// An Expr is an arithmetic expression.
|
||||
type Expr interface{}
|
||||
```
|
||||
|
||||
我們的表達式語言由浮點數符號（小數點）；二元操作符+，-，\*， 和/；一元操作符-x和+x；調用pow(x,y)，sin(x)，和sqrt(x)的函數；例如x和pi的變量；當然也有括號和標準的優先級運算符。所有的值都是float64類型。這下面是一些表達式的例子：
|
||||
我们的表达式语言由浮点数符号（小数点）；二元操作符+，-，\*， 和/；一元操作符-x和+x；调用pow(x,y)，sin(x)，和sqrt(x)的函数；例如x和pi的变量；当然也有括号和标准的优先级运算符。所有的值都是float64类型。这下面是一些表达式的例子：
|
||||
|
||||
```go
|
||||
sqrt(A / pi)
|
||||
@@ -15,7 +15,7 @@ pow(x, 3) + pow(y, 3)
|
||||
(F - 32) * 5 / 9
|
||||
```
|
||||
|
||||
下面的五個具體類型表示了具體的表達式類型。Var類型表示對一個變量的引用。（我們很快會知道爲什麽它可以被輸出。）literal類型表示一個浮點型常量。unary和binary類型表示有一到兩個運算對象的運算符表達式，這些操作數可以是任意的Expr類型。call類型表示對一個函數的調用；我們限製它的fn字段隻能是pow，sin或者sqrt。
|
||||
下面的五个具体类型表示了具体的表达式类型。Var类型表示对一个变量的引用。（我们很快会知道为什么它可以被输出。）literal类型表示一个浮点型常量。unary和binary类型表示有一到两个运算对象的运算符表达式，这些操作数可以是任意的Expr类型。call类型表示对一个函数的调用；我们限制它的fn字段只能是pow，sin或者sqrt。
|
||||
|
||||
<u><i>gopl.io/ch7/eval</i></u>
|
||||
```go
|
||||
@@ -44,13 +44,13 @@ type call struct {
|
||||
}
|
||||
```
|
||||
|
||||
爲了計算一個包含變量的表達式，我們需要一個environment變量將變量的名字映射成對應的值：
|
||||
为了计算一个包含变量的表达式，我们需要一个environment变量将变量的名字映射成对应的值：
|
||||
|
||||
```go
|
||||
type Env map[Var]float64
|
||||
```
|
||||
|
||||
我們也需要每個表示式去定義一個Eval方法，這個方法會根據給定的environment變量返迴表達式的值。因爲每個表達式都必須提供這個方法，我們將它加入到Expr接口中。這個包隻會對外公開Expr，Env，和Var類型。調用方不需要獲取其它的表達式類型就可以使用這個求值器。
|
||||
我们也需要每个表示式去定义一个Eval方法，这个方法会根据给定的environment变量返回表达式的值。因为每个表达式都必须提供这个方法，我们将它加入到Expr接口中。这个包只会对外公开Expr，Env，和Var类型。调用方不需要获取其它的表达式类型就可以使用这个求值器。
|
||||
|
||||
```go
|
||||
type Expr interface {
|
||||
@@ -59,7 +59,7 @@ type Expr interface {
|
||||
}
|
||||
```
|
||||
|
||||
下面給大家展示一個具體的Eval方法。Var類型的這個方法對一個environment變量進行査找，如果這個變量沒有在environment中定義過這個方法會返迴一個零值，literal類型的這個方法簡單的返迴它眞實的值。
|
||||
下面给大家展示一个具体的Eval方法。Var类型的这个方法对一个environment变量进行查找，如果这个变量没有在environment中定义过这个方法会返回一个零值，literal类型的这个方法简单的返回它真实的值。
|
||||
|
||||
```go
|
||||
func (v Var) Eval(env Env) float64 {
|
||||
@@ -71,7 +71,7 @@ func (l literal) Eval(_ Env) float64 {
|
||||
}
|
||||
```
|
||||
|
||||
unary和binary的Eval方法會遞歸的計算它的運算對象，然後將運算符op作用到它們上。我們不將被零或無窮數除作爲一個錯誤，因爲它們都會産生一個固定的結果無限。最後，call的這個方法會計算對於pow，sin，或者sqrt函數的參數值，然後調用對應在math包中的函數。
|
||||
unary和binary的Eval方法会递归的计算它的运算对象，然后将运算符op作用到它们上。我们不将被零或无穷数除作为一个错误，因为它们都会产生一个固定的结果无限。最后，call的这个方法会计算对于pow，sin，或者sqrt函数的参数值，然后调用对应在math包中的函数。
|
||||
|
||||
```go
|
||||
func (u unary) Eval(env Env) float64 {
|
||||
@@ -111,9 +111,9 @@ func (c call) Eval(env Env) float64 {
|
||||
}
|
||||
```
|
||||
|
||||
一些方法會失敗。例如，一個call表達式可能未知的函數或者錯誤的參數個數。用一個無效的運算符如!或者<去構建一個unary或者binary表達式也是可能會發生的（盡管下面提到的Parse函數不會這樣做）。這些錯誤會讓Eval方法panic。其它的錯誤，像計算一個沒有在environment變量中出現過的Var，隻會讓Eval方法返迴一個錯誤的結果。所有的這些錯誤都可以通過在計算前檢査Expr來發現。這是我們接下來要講的Check方法的工作，但是讓我們先測試Eval方法。
|
||||
一些方法会失败。例如，一个call表达式可能未知的函数或者错误的参数个数。用一个无效的运算符如!或者<去构建一个unary或者binary表达式也是可能会发生的（尽管下面提到的Parse函数不会这样做）。这些错误会让Eval方法panic。其它的错误，像计算一个没有在environment变量中出现过的Var，只会让Eval方法返回一个错误的结果。所有的这些错误都可以通过在计算前检查Expr来发现。这是我们接下来要讲的Check方法的工作，但是让我们先测试Eval方法。
|
||||
|
||||
下面的TestEval函數是對evaluator的一個測試。它使用了我們會在第11章講解的testing包，但是現在知道調用t.Errof會報告一個錯誤就足夠了。這個函數循環遍歷一個表格中的輸入，這個表格中定義了三個表達式和針對每個表達式不同的環境變量。第一個表達式根據給定圓的面積A計算它的半徑，第二個表達式通過兩個變量x和y計算兩個立方體的體積之和，第三個表達式將華氏溫度F轉換成攝氏度。
|
||||
下面的TestEval函数是对evaluator的一个测试。它使用了我们会在第11章讲解的testing包，但是现在知道调用t.Errof会报告一个错误就足够了。这个函数循环遍历一个表格中的输入，这个表格中定义了三个表达式和针对每个表达式不同的环境变量。第一个表达式根据给定圆的面积A计算它的半径，第二个表达式通过两个变量x和y计算两个立方体的体积之和，第三个表达式将华氏温度F转换成摄氏度。
|
||||
|
||||
```go
|
||||
func TestEval(t *testing.T) {
|
||||
@@ -151,15 +151,15 @@ func TestEval(t *testing.T) {
|
||||
}
|
||||
```
|
||||
|
||||
對於表格中的每一條記録，這個測試會解析它的表達式然後在環境變量中計算它，輸出結果。這里我們沒有空間來展示Parse函數，但是如果你使用go get下載這個包你就可以看到這個函數。
|
||||
对于表格中的每一条记录，这个测试会解析它的表达式然后在环境变量中计算它，输出结果。这里我们没有空间来展示Parse函数，但是如果你使用go get下载这个包你就可以看到这个函数。
|
||||
|
||||
go test(§11.1) 命令會運行一個包的測試用例：
|
||||
go test(§11.1) 命令会运行一个包的测试用例：
|
||||
|
||||
```
|
||||
$ go test -v gopl.io/ch7/eval
|
||||
```
|
||||
|
||||
這個-v標識可以讓我們看到測試用例打印的輸出；正常情況下像這個一樣成功的測試用例會阻止打印結果的輸出。這里是測試用例里fmt.Printf語句的輸出：
|
||||
这个-v标识可以让我们看到测试用例打印的输出；正常情况下像这个一样成功的测试用例会阻止打印结果的输出。这里是测试用例里fmt.Printf语句的输出：
|
||||
|
||||
```
|
||||
sqrt(A / pi)
|
||||
@@ -175,9 +175,9 @@ pow(x, 3) + pow(y, 3)
|
||||
map[F:212] => 100
|
||||
```
|
||||
|
||||
幸運的是目前爲止所有的輸入都是適合的格式，但是我們的運氣不可能一直都有。甚至在解釋型語言中，爲了靜態錯誤檢査語法是非常常見的；靜態錯誤就是不用運行程序就可以檢測出來的錯誤。通過將靜態檢査和動態的部分分開，我們可以快速的檢査錯誤併且對於多次檢査隻執行一次而不是每次表達式計算的時候都進行檢査。
|
||||
幸运的是目前为止所有的输入都是适合的格式，但是我们的运气不可能一直都有。甚至在解释型语言中，为了静态错误检查语法是非常常见的；静态错误就是不用运行程序就可以检测出来的错误。通过将静态检查和动态的部分分开，我们可以快速的检查错误并且对于多次检查只执行一次而不是每次表达式计算的时候都进行检查。
|
||||
|
||||
讓我們往Expr接口中增加另一個方法。Check方法在一個表達式語義樹檢査出靜態錯誤。我們馬上會説明它的vars參數。
|
||||
让我们往Expr接口中增加另一个方法。Check方法在一个表达式语义树检查出静态错误。我们马上会说明它的vars参数。
|
||||
|
||||
```go
|
||||
type Expr interface {
|
||||
@@ -187,7 +187,7 @@ type Expr interface {
|
||||
}
|
||||
```
|
||||
|
||||
具體的Check方法展示在下面。literal和Var類型的計算不可能失敗，所以這些類型的Check方法會返迴一個nil值。對於unary和binary的Check方法會首先檢査操作符是否有效，然後遞歸的檢査運算單元。相似地對於call的這個方法首先檢査調用的函數是否已知併且有沒有正確個數的參數，然後遞歸的檢査每一個參數。
|
||||
具体的Check方法展示在下面。literal和Var类型的计算不可能失败，所以这些类型的Check方法会返回一个nil值。对于unary和binary的Check方法会首先检查操作符是否有效，然后递归的检查运算单元。相似地对于call的这个方法首先检查调用的函数是否已知并且有没有正确个数的参数，然后递归的检查每一个参数。
|
||||
|
||||
```go
|
||||
func (v Var) Check(vars map[Var]bool) error {
|
||||
@@ -236,7 +236,7 @@ func (c call) Check(vars map[Var]bool) error {
|
||||
var numParams = map[string]int{"pow": 2, "sin": 1, "sqrt": 1}
|
||||
```
|
||||
|
||||
我們在兩個組中有選擇地列出有問題的輸入和它們得出的錯誤。Parse函數（這里沒有出現）會報出一個語法錯誤和Check函數會報出語義錯誤。
|
||||
我们在两个组中有选择地列出有问题的输入和它们得出的错误。Parse函数（这里没有出现）会报出一个语法错误和Check函数会报出语义错误。
|
||||
|
||||
```
|
||||
x % 2 unexpected '%'
|
||||
@@ -248,11 +248,11 @@ log(10) unknown function "log"
|
||||
sqrt(1, 2) call to sqrt has 2 args, want 1
|
||||
```
|
||||
|
||||
Check方法的參數是一個Var類型的集合，這個集合聚集從表達式中找到的變量名。爲了保證成功的計算，這些變量中的每一個都必須出現在環境變量中。從邏輯上講，這個集合就是調用Check方法返迴的結果，但是因爲這個方法是遞歸調用的，所以對於Check方法填充結果到一個作爲參數傳入的集合中會更加的方便。調用方在初始調用時必須提供一個空的集合。
|
||||
Check方法的参数是一个Var类型的集合，这个集合聚集从表达式中找到的变量名。为了保证成功的计算，这些变量中的每一个都必须出现在环境变量中。从逻辑上讲，这个集合就是调用Check方法返回的结果，但是因为这个方法是递归调用的，所以对于Check方法填充结果到一个作为参数传入的集合中会更加的方便。调用方在初始调用时必须提供一个空的集合。
|
||||
|
||||
在第3.2節中，我們繪製了一個在編譯器才確定的函數f(x,y)。現在我們可以解析，檢査和計算在字符串中的表達式，我們可以構建一個在運行時從客戶端接收表達式的web應用併且它會繪製這個函數的表示的麴面。我們可以使用集合vars來檢査表達式是否是一個隻有兩個變量,x和y的函數——實際上是3個，因爲我們爲了方便會提供半徑大小r。併且我們會在計算前使用Check方法拒絶有格式問題的表達式，這樣我們就不會在下面函數的40000個計算過程（100x100個柵格，每一個有4個角）重複這些檢査。
|
||||
在第3.2节中，我们绘制了一个在编译器才确定的函数f(x,y)。现在我们可以解析，检查和计算在字符串中的表达式，我们可以构建一个在运行时从客户端接收表达式的web应用并且它会绘制这个函数的表示的曲面。我们可以使用集合vars来检查表达式是否是一个只有两个变量,x和y的函数——实际上是3个，因为我们为了方便会提供半径大小r。并且我们会在计算前使用Check方法拒绝有格式问题的表达式，这样我们就不会在下面函数的40000个计算过程（100x100个栅格，每一个有4个角）重复这些检查。
|
||||
|
||||
這個ParseAndCheck函數混合了解析和檢査步驟的過程：
|
||||
这个ParseAndCheck函数混合了解析和检查步骤的过程：
|
||||
|
||||
<u><i>gopl.io/ch7/surface</i></u>
|
||||
```go
|
||||
@@ -279,7 +279,7 @@ func parseAndCheck(s string) (eval.Expr, error) {
|
||||
}
|
||||
```
|
||||
|
||||
爲了編寫這個web應用，所有我們需要做的就是下面這個plot函數，這個函數有和http.HandlerFunc相似的籤名：
|
||||
为了编写这个web应用，所有我们需要做的就是下面这个plot函数，这个函数有和http.HandlerFunc相似的签名：
|
||||
|
||||
```go
|
||||
func plot(w http.ResponseWriter, r *http.Request) {
|
||||
@@ -299,12 +299,12 @@ func plot(w http.ResponseWriter, r *http.Request) {
|
||||
|
||||
|
||||
|
||||
這個plot函數解析和檢査在HTTP請求中指定的表達式併且用它來創建一個兩個變量的匿名函數。這個匿名函數和來自原來surface-plotting程序中的固定函數f有相同的籤名，但是它計算一個用戶提供的表達式。環境變量中定義了x，y和半徑r。最後plot調用surface函數，它就是gopl.io/ch3/surface中的主要函數，脩改後它可以接受plot中的函數和輸出io.Writer作爲參數，而不是使用固定的函數f和os.Stdout。圖7.7中顯示了通過程序産生的3個麴面。
|
||||
这个plot函数解析和检查在HTTP请求中指定的表达式并且用它来创建一个两个变量的匿名函数。这个匿名函数和来自原来surface-plotting程序中的固定函数f有相同的签名，但是它计算一个用户提供的表达式。环境变量中定义了x，y和半径r。最后plot调用surface函数，它就是gopl.io/ch3/surface中的主要函数，修改后它可以接受plot中的函数和输出io.Writer作为参数，而不是使用固定的函数f和os.Stdout。图7.7中显示了通过程序产生的3个曲面。
|
||||
|
||||
**練習 7.13：** 爲Expr增加一個String方法來打印美觀的語法樹。當再一次解析的時候，檢査它的結果是否生成相同的語法樹。
|
||||
**练习 7.13：** 为Expr增加一个String方法来打印美观的语法树。当再一次解析的时候，检查它的结果是否生成相同的语法树。
|
||||
|
||||
**練習 7.14：** 定義一個新的滿足Expr接口的具體類型併且提供一個新的操作例如對它運算單元中的最小值的計算。因爲Parse函數不會創建這個新類型的實例，爲了使用它你可能需要直接構造一個語法樹（或者繼承parser接口）。
|
||||
**练习 7.14：** 定义一个新的满足Expr接口的具体类型并且提供一个新的操作例如对它运算单元中的最小值的计算。因为Parse函数不会创建这个新类型的实例，为了使用它你可能需要直接构造一个语法树（或者继承parser接口）。
|
||||
|
||||
**練習 7.15：** 編寫一個從標準輸入中讀取一個單一表達式的程序，用戶及時地提供對於任意變量的值，然後在結果環境變量中計算表達式的值。優雅的處理所有遇到的錯誤。
|
||||
**练习 7.15：** 编写一个从标准输入中读取一个单一表达式的程序，用户及时地提供对于任意变量的值，然后在结果环境变量中计算表达式的值。优雅的处理所有遇到的错误。
|
||||
|
||||
**練習 7.16：** 編寫一個基於web的計算器程序。
|
||||
**练习 7.16：** 编写一个基于web的计算器程序。
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
## 7.10. 類型斷言
|
||||
## 7.10. 类型断言
|
||||
|
||||
類型斷言是一個使用在接口值上的操作。語法上它看起來像x.(T)被稱爲斷言類型，這里x表示一個接口的類型和T表示一個類型。一個類型斷言檢査它操作對象的動態類型是否和斷言的類型匹配。
|
||||
类型断言是一个使用在接口值上的操作。语法上它看起来像x.(T)被称为断言类型，这里x表示一个接口的类型和T表示一个类型。一个类型断言检查它操作对象的动态类型是否和断言的类型匹配。
|
||||
|
||||
這里有兩種可能。第一種，如果斷言的類型T是一個具體類型，然後類型斷言檢査x的動態類型是否和T相同。如果這個檢査成功了，類型斷言的結果是x的動態值，當然它的類型是T。換句話説，具體類型的類型斷言從它的操作對象中獲得具體的值。如果檢査失敗，接下來這個操作會拋出panic。例如：
|
||||
这里有两种可能。第一种，如果断言的类型T是一个具体类型，然后类型断言检查x的动态类型是否和T相同。如果这个检查成功了，类型断言的结果是x的动态值，当然它的类型是T。换句话说，具体类型的类型断言从它的操作对象中获得具体的值。如果检查失败，接下来这个操作会抛出panic。例如：
|
||||
|
||||
```go
|
||||
var w io.Writer
|
||||
@@ -11,9 +11,9 @@ f := w.(*os.File) // success: f == os.Stdout
|
||||
c := w.(*bytes.Buffer) // panic: interface holds *os.File, not *bytes.Buffer
|
||||
```
|
||||
|
||||
第二種，如果相反斷言的類型T是一個接口類型，然後類型斷言檢査是否x的動態類型滿足T。如果這個檢査成功了，動態值沒有獲取到；這個結果仍然是一個有相同類型和值部分的接口值，但是結果有類型T。換句話説，對一個接口類型的類型斷言改變了類型的表述方式，改變了可以獲取的方法集合（通常更大），但是它保護了接口值內部的動態類型和值的部分。
|
||||
第二种，如果相反断言的类型T是一个接口类型，然后类型断言检查是否x的动态类型满足T。如果这个检查成功了，动态值没有获取到；这个结果仍然是一个有相同类型和值部分的接口值，但是结果有类型T。换句话说，对一个接口类型的类型断言改变了类型的表述方式，改变了可以获取的方法集合（通常更大），但是它保护了接口值内部的动态类型和值的部分。
|
||||
|
||||
在下面的第一個類型斷言後，w和rw都持有os.Stdout因此它們每個有一個動態類型*os.File，但是變量w是一個io.Writer類型隻對外公開出文件的Write方法，然而rw變量也隻公開它的Read方法。
|
||||
在下面的第一个类型断言后，w和rw都持有os.Stdout因此它们每个有一个动态类型*os.File，但是变量w是一个io.Writer类型只对外公开出文件的Write方法，然而rw变量也只公开它的Read方法。
|
||||
|
||||
```go
|
||||
var w io.Writer
|
||||
@@ -23,14 +23,14 @@ w = new(ByteCounter)
|
||||
rw = w.(io.ReadWriter) // panic: *ByteCounter has no Read method
|
||||
```
|
||||
|
||||
如果斷言操作的對象是一個nil接口值，那麽不論被斷言的類型是什麽這個類型斷言都會失敗。我們幾乎不需要對一個更少限製性的接口類型（更少的方法集合）做斷言，因爲它表現的就像賦值操作一樣，除了對於nil接口值的情況。
|
||||
如果断言操作的对象是一个nil接口值，那么不论被断言的类型是什么这个类型断言都会失败。我们几乎不需要对一个更少限制性的接口类型（更少的方法集合）做断言，因为它表现的就像赋值操作一样，除了对于nil接口值的情况。
|
||||
|
||||
```go
|
||||
w = rw // io.ReadWriter is assignable to io.Writer
|
||||
w = rw.(io.Writer) // fails only if rw == nil
|
||||
```
|
||||
|
||||
經常地我們對一個接口值的動態類型是不確定的，併且我們更願意去檢驗它是否是一些特定的類型。如果類型斷言出現在一個預期有兩個結果的賦值操作中，例如如下的定義，這個操作不會在失敗的時候發生panic但是代替地返迴一個額外的第二個結果，這個結果是一個標識成功的布爾值：
|
||||
经常地我们对一个接口值的动态类型是不确定的，并且我们更愿意去检验它是否是一些特定的类型。如果类型断言出现在一个预期有两个结果的赋值操作中，例如如下的定义，这个操作不会在失败的时候发生panic但是代替地返回一个额外的第二个结果，这个结果是一个标识成功的布尔值：
|
||||
|
||||
```go
|
||||
var w io.Writer = os.Stdout
|
||||
@@ -38,9 +38,9 @@ f, ok := w.(*os.File) // success: ok, f == os.Stdout
|
||||
b, ok := w.(*bytes.Buffer) // failure: !ok, b == nil
|
||||
```
|
||||
|
||||
第二個結果常規地賦值給一個命名爲ok的變量。如果這個操作失敗了，那麽ok就是false值，第一個結果等於被斷言類型的零值，在這個例子中就是一個nil的*bytes.Buffer類型。
|
||||
第二个结果常规地赋值给一个命名为ok的变量。如果这个操作失败了，那么ok就是false值，第一个结果等于被断言类型的零值，在这个例子中就是一个nil的*bytes.Buffer类型。
|
||||
|
||||
這個ok結果經常立卽用於決定程序下面做什麽。if語句的擴展格式讓這個變的很簡潔：
|
||||
这个ok结果经常立即用于决定程序下面做什么。if语句的扩展格式让这个变的很简洁：
|
||||
|
||||
```go
|
||||
if f, ok := w.(*os.File); ok {
|
||||
@@ -48,7 +48,7 @@ if f, ok := w.(*os.File); ok {
|
||||
}
|
||||
```
|
||||
|
||||
當類型斷言的操作對象是一個變量，你有時會看見原來的變量名重用而不是聲明一個新的本地變量，這個重用的變量會覆蓋原來的值，如下面這樣：
|
||||
当类型断言的操作对象是一个变量，你有时会看见原来的变量名重用而不是声明一个新的本地变量，这个重用的变量会覆盖原来的值，如下面这样：
|
||||
|
||||
```go
|
||||
if w, ok := w.(*os.File); ok {
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
## 7.11. 基於類型斷言區别錯誤類型
|
||||
## 7.11. 基于类型断言区别错误类型
|
||||
|
||||
思考在os包中文件操作返迴的錯誤集合。I/O可以因爲任何數量的原因失敗，但是有三種經常的錯誤必須進行不同的處理：文件已經存在（對於創建操作），找不到文件（對於讀取操作），和權限拒絶。os包中提供了這三個幫助函數來對給定的錯誤值表示的失敗進行分類：
|
||||
思考在os包中文件操作返回的错误集合。I/O可以因为任何数量的原因失败，但是有三种经常的错误必须进行不同的处理：文件已经存在（对于创建操作），找不到文件（对于读取操作），和权限拒绝。os包中提供了这三个帮助函数来对给定的错误值表示的失败进行分类：
|
||||
|
||||
```go
|
||||
package os
|
||||
@@ -10,7 +10,7 @@ func IsNotExist(err error) bool
|
||||
func IsPermission(err error) bool
|
||||
```
|
||||
|
||||
對這些判斷的一個缺乏經驗的實現可能會去檢査錯誤消息是否包含了特定的子字符串，
|
||||
对这些判断的一个缺乏经验的实现可能会去检查错误消息是否包含了特定的子字符串，
|
||||
|
||||
```go
|
||||
func IsNotExist(err error) bool {
|
||||
@@ -19,9 +19,9 @@ func IsNotExist(err error) bool {
|
||||
}
|
||||
```
|
||||
|
||||
但是處理I/O錯誤的邏輯可能一個和另一個平台非常的不同，所以這種方案併不健壯併且對相同的失敗可能會報出各種不同的錯誤消息。在測試的過程中，通過檢査錯誤消息的子字符串來保證特定的函數以期望的方式失敗是非常有用的，但對於線上的代碼是不夠的。
|
||||
但是处理I/O错误的逻辑可能一个和另一个平台非常的不同，所以这种方案并不健壮并且对相同的失败可能会报出各种不同的错误消息。在测试的过程中，通过检查错误消息的子字符串来保证特定的函数以期望的方式失败是非常有用的，但对于线上的代码是不够的。
|
||||
|
||||
一個更可靠的方式是使用一個專門的類型來描述結構化的錯誤。os包中定義了一個PathError類型來描述在文件路徑操作中涉及到的失敗，像Open或者Delete操作,併且定義了一個叫LinkError的變體來描述涉及到兩個文件路徑的操作，像Symlink和Rename。這下面是os.PathError：
|
||||
一个更可靠的方式是使用一个专门的类型来描述结构化的错误。os包中定义了一个PathError类型来描述在文件路径操作中涉及到的失败，像Open或者Delete操作,并且定义了一个叫LinkError的变体来描述涉及到两个文件路径的操作，像Symlink和Rename。这下面是os.PathError：
|
||||
|
||||
```go
|
||||
package os
|
||||
@@ -38,7 +38,7 @@ func (e *PathError) Error() string {
|
||||
}
|
||||
```
|
||||
|
||||
大多數調用方都不知道PathError併且通過調用錯誤本身的Error方法來統一處理所有的錯誤。盡管PathError的Error方法簡單地把這些字段連接起來生成錯誤消息，PathError的結構保護了內部的錯誤組件。調用方需要使用類型斷言來檢測錯誤的具體類型以便將一種失敗和另一種區分開；具體的類型比字符串可以提供更多的細節。
|
||||
大多数调用方都不知道PathError并且通过调用错误本身的Error方法来统一处理所有的错误。尽管PathError的Error方法简单地把这些字段连接起来生成错误消息，PathError的结构保护了内部的错误组件。调用方需要使用类型断言来检测错误的具体类型以便将一种失败和另一种区分开；具体的类型比字符串可以提供更多的细节。
|
||||
|
||||
```go
|
||||
_, err := os.Open("/no/such/file")
|
||||
@@ -48,7 +48,7 @@ fmt.Printf("%#v\n", err)
|
||||
// &os.PathError{Op:"open", Path:"/no/such/file", Err:0x2}
|
||||
```
|
||||
|
||||
這就是三個幫助函數是怎麽工作的。例如下面展示的IsNotExist，它會報出是否一個錯誤和syscall.ENOENT(§7.8)或者和有名的錯誤os.ErrNotExist相等(可以在§5.4.2中找到io.EOF）；或者是一個*PathError，它內部的錯誤是syscall.ENOENT和os.ErrNotExist其中之一。
|
||||
这就是三个帮助函数是怎么工作的。例如下面展示的IsNotExist，它会报出是否一个错误和syscall.ENOENT(§7.8)或者和有名的错误os.ErrNotExist相等(可以在§5.4.2中找到io.EOF）；或者是一个*PathError，它内部的错误是syscall.ENOENT和os.ErrNotExist其中之一。
|
||||
|
||||
```go
|
||||
import (
|
||||
@@ -69,11 +69,11 @@ func IsNotExist(err error) bool {
|
||||
}
|
||||
```
|
||||
|
||||
下面這里是它的實際使用：
|
||||
下面这里是它的实际使用：
|
||||
|
||||
```go
|
||||
_, err := os.Open("/no/such/file")
|
||||
fmt.Println(os.IsNotExist(err)) // "true"
|
||||
```
|
||||
|
||||
如果錯誤消息結合成一個更大的字符串，當然PathError的結構就不再爲人所知，例如通過一個對fmt.Errorf函數的調用。區别錯誤通常必須在失敗操作後，錯誤傳迴調用者前進行。
|
||||
如果错误消息结合成一个更大的字符串，当然PathError的结构就不再为人所知，例如通过一个对fmt.Errorf函数的调用。区别错误通常必须在失败操作后，错误传回调用者前进行。
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
## 7.12. 通過類型斷言詢問行爲
|
||||
## 7.12. 通过类型断言询问行为
|
||||
|
||||
下面這段邏輯和net/http包中web服務器負責寫入HTTP頭字段（例如："Content-type:text/html）的部分相似。io.Writer接口類型的變量w代表HTTP響應；寫入它的字節最終被發送到某個人的web瀏覽器上。
|
||||
下面这段逻辑和net/http包中web服务器负责写入HTTP头字段（例如："Content-type:text/html）的部分相似。io.Writer接口类型的变量w代表HTTP响应；写入它的字节最终被发送到某个人的web浏览器上。
|
||||
|
||||
```go
|
||||
func writeHeader(w io.Writer, contentType string) error {
|
||||
@@ -14,11 +14,11 @@ func writeHeader(w io.Writer, contentType string) error {
|
||||
}
|
||||
```
|
||||
|
||||
因爲Write方法需要傳入一個byte切片而我們希望寫入的值是一個字符串，所以我們需要使用[]byte(...)進行轉換。這個轉換分配內存併且做一個拷貝，但是這個拷貝在轉換後幾乎立馬就被丟棄掉。讓我們假裝這是一個web服務器的核心部分併且我們的性能分析表示這個內存分配使服務器的速度變慢。這里我們可以避免掉內存分配麽？
|
||||
因为Write方法需要传入一个byte切片而我们希望写入的值是一个字符串，所以我们需要使用[]byte(...)进行转换。这个转换分配内存并且做一个拷贝，但是这个拷贝在转换后几乎立马就被丢弃掉。让我们假装这是一个web服务器的核心部分并且我们的性能分析表示这个内存分配使服务器的速度变慢。这里我们可以避免掉内存分配么？
|
||||
|
||||
這個io.Writer接口告訴我們關於w持有的具體類型的唯一東西：就是可以向它寫入字節切片。如果我們迴顧net/http包中的內幕，我們知道在這個程序中的w變量持有的動態類型也有一個允許字符串高效寫入的WriteString方法；這個方法會避免去分配一個零時的拷貝。（這可能像在黑夜中射擊一樣，但是許多滿足io.Writer接口的重要類型同時也有WriteString方法，包括\*bytes.Buffer，\*os.File和\*bufio.Writer。）
|
||||
这个io.Writer接口告诉我们关于w持有的具体类型的唯一东西：就是可以向它写入字节切片。如果我们回顾net/http包中的内幕，我们知道在这个程序中的w变量持有的动态类型也有一个允许字符串高效写入的WriteString方法；这个方法会避免去分配一个零时的拷贝。（这可能像在黑夜中射击一样，但是许多满足io.Writer接口的重要类型同时也有WriteString方法，包括\*bytes.Buffer，\*os.File和\*bufio.Writer。）
|
||||
|
||||
我們不能對任意io.Writer類型的變量w，假設它也擁有WriteString方法。但是我們可以定義一個隻有這個方法的新接口併且使用類型斷言來檢測是否w的動態類型滿足這個新接口。
|
||||
我们不能对任意io.Writer类型的变量w，假设它也拥有WriteString方法。但是我们可以定义一个只有这个方法的新接口并且使用类型断言来检测是否w的动态类型满足这个新接口。
|
||||
|
||||
```go
|
||||
// writeString writes s to w.
|
||||
@@ -44,9 +44,9 @@ func writeHeader(w io.Writer, contentType string) error {
|
||||
}
|
||||
```
|
||||
|
||||
爲了避免重複定義，我們將這個檢査移入到一個實用工具函數writeString中，但是它太有用了以致標準庫將它作爲io.WriteString函數提供。這是向一個io.Writer接口寫入字符串的推薦方法。
|
||||
为了避免重复定义，我们将这个检查移入到一个实用工具函数writeString中，但是它太有用了以致标准库将它作为io.WriteString函数提供。这是向一个io.Writer接口写入字符串的推荐方法。
|
||||
|
||||
這個例子的神奇之處在於沒有定義了WriteString方法的標準接口和沒有指定它是一個需要行爲的標準接口。而且一個具體類型隻會通過它的方法決定它是否滿足stringWriter接口，而不是任何它和這個接口類型表明的關繫。它的意思就是上面的技術依賴於一個假設；這個假設就是，如果一個類型滿足下面的這個接口，然後WriteString(s)就方法必須和Write([]byte(s))有相同的效果。
|
||||
这个例子的神奇之处在于没有定义了WriteString方法的标准接口和没有指定它是一个需要行为的标准接口。而且一个具体类型只会通过它的方法决定它是否满足stringWriter接口，而不是任何它和这个接口类型表明的关系。它的意思就是上面的技术依赖于一个假设；这个假设就是，如果一个类型满足下面的这个接口，然后WriteString(s)就方法必须和Write([]byte(s))有相同的效果。
|
||||
|
||||
```go
|
||||
interface {
|
||||
@@ -55,11 +55,11 @@ interface {
|
||||
}
|
||||
```
|
||||
|
||||
盡管io.WriteString記録了它的假設，但是調用它的函數極少有可能會去記録它們也做了同樣的假設。定義一個特定類型的方法隱式地獲取了對特定行爲的協約。對於Go語言的新手，特别是那些來自有強類型語言使用背景的新手，可能會發現它缺乏顯式的意圖令人感到混亂，但是在實戰的過程中這幾乎不是一個問題。除了空接口interface{},接口類型很少意外巧合地被實現。
|
||||
尽管io.WriteString记录了它的假设，但是调用它的函数极少有可能会去记录它们也做了同样的假设。定义一个特定类型的方法隐式地获取了对特定行为的协约。对于Go语言的新手，特别是那些来自有强类型语言使用背景的新手，可能会发现它缺乏显式的意图令人感到混乱，但是在实战的过程中这几乎不是一个问题。除了空接口interface{},接口类型很少意外巧合地被实现。
|
||||
|
||||
上面的writeString函數使用一個類型斷言來知道一個普遍接口類型的值是否滿足一個更加具體的接口類型；併且如果滿足，它會使用這個更具體接口的行爲。這個技術可以被很好的使用不論這個被詢問的接口是一個標準的如io.ReadWriter或者用戶定義的如stringWriter。
|
||||
上面的writeString函数使用一个类型断言来知道一个普遍接口类型的值是否满足一个更加具体的接口类型；并且如果满足，它会使用这个更具体接口的行为。这个技术可以被很好的使用不论这个被询问的接口是一个标准的如io.ReadWriter或者用户定义的如stringWriter。
|
||||
|
||||
這也是fmt.Fprintf函數怎麽從其它所有值中區分滿足error或者fmt.Stringer接口的值。在fmt.Fprintf內部，有一個將單個操作對象轉換成一個字符串的步驟，像下面這樣：
|
||||
这也是fmt.Fprintf函数怎么从其它所有值中区分满足error或者fmt.Stringer接口的值。在fmt.Fprintf内部，有一个将单个操作对象转换成一个字符串的步骤，像下面这样：
|
||||
|
||||
```go
|
||||
package fmt
|
||||
@@ -75,6 +75,6 @@ func formatOneValue(x interface{}) string {
|
||||
}
|
||||
```
|
||||
|
||||
如果x滿足這個兩個接口類型中的一個，具體滿足的接口決定對值的格式化方式。如果都不滿足，默認的case或多或少會統一地使用反射來處理所有的其它類型；我們可以在第12章知道具體是怎麽實現的。
|
||||
如果x满足这个两个接口类型中的一个，具体满足的接口决定对值的格式化方式。如果都不满足，默认的case或多或少会统一地使用反射来处理所有的其它类型；我们可以在第12章知道具体是怎么实现的。
|
||||
|
||||
再一次的，它假設任何有String方法的類型滿足fmt.Stringer中約定的行爲，這個行爲會返迴一個適合打印的字符串。
|
||||
再一次的，它假设任何有String方法的类型满足fmt.Stringer中约定的行为，这个行为会返回一个适合打印的字符串。
|
||||
|
||||
@@ -1,12 +1,12 @@
|
||||
## 7.13. 類型開關
|
||||
## 7.13. 类型开关
|
||||
|
||||
接口被以兩種不同的方式使用。在第一個方式中，以io.Reader，io.Writer，fmt.Stringer，sort.Interface，http.Handler，和error爲典型，一個接口的方法表達了實現這個接口的具體類型間的相思性，但是隱藏了代表的細節和這些具體類型本身的操作。重點在於方法上，而不是具體的類型上。
|
||||
接口被以两种不同的方式使用。在第一个方式中，以io.Reader，io.Writer，fmt.Stringer，sort.Interface，http.Handler，和error为典型，一个接口的方法表达了实现这个接口的具体类型间的相思性，但是隐藏了代表的细节和这些具体类型本身的操作。重点在于方法上，而不是具体的类型上。
|
||||
|
||||
第二個方式利用一個接口值可以持有各種具體類型值的能力併且將這個接口認爲是這些類型的union（聯合）。類型斷言用來動態地區别這些類型併且對每一種情況都不一樣。在這個方式中，重點在於具體的類型滿足這個接口，而不是在於接口的方法（如果它確實有一些的話），併且沒有任何的信息隱藏。我們將以這種方式使用的接口描述爲discriminated unions（可辨識聯合）。
|
||||
第二个方式利用一个接口值可以持有各种具体类型值的能力并且将这个接口认为是这些类型的union（联合）。类型断言用来动态地区别这些类型并且对每一种情况都不一样。在这个方式中，重点在于具体的类型满足这个接口，而不是在于接口的方法（如果它确实有一些的话），并且没有任何的信息隐藏。我们将以这种方式使用的接口描述为discriminated unions（可辨识联合）。
|
||||
|
||||
如果你熟悉面向對象編程，你可能會將這兩種方式當作是subtype polymorphism（子類型多態）和 ad hoc polymorphism（非參數多態），但是你不需要去記住這些術語。對於本章剩下的部分，我們將會呈現一些第二種方式的例子。
|
||||
如果你熟悉面向对象编程，你可能会将这两种方式当作是subtype polymorphism（子类型多态）和 ad hoc polymorphism（非参数多态），但是你不需要去记住这些术语。对于本章剩下的部分，我们将会呈现一些第二种方式的例子。
|
||||
|
||||
和其它那些語言一樣，Go語言査詢一個SQL數據庫的API會榦淨地將査詢中固定的部分和變化的部分分開。一個調用的例子可能看起來像這樣：
|
||||
和其它那些语言一样，Go语言查询一个SQL数据库的API会干净地将查询中固定的部分和变化的部分分开。一个调用的例子可能看起来像这样：
|
||||
|
||||
```go
|
||||
import "database/sql"
|
||||
@@ -19,7 +19,7 @@ func listTracks(db sql.DB, artist string, minYear, maxYear int) {
|
||||
}
|
||||
```
|
||||
|
||||
Exec方法使用SQL字面量替換在査詢字符串中的每個'?'；SQL字面量表示相應參數的值，它有可能是一個布爾值，一個數字，一個字符串，或者nil空值。用這種方式構造査詢可以幫助避免SQL註入攻擊；這種攻擊就是對手可以通過利用輸入內容中不正確的引文來控製査詢語句。在Exec函數內部，我們可能會找到像下面這樣的一個函數，它會將每一個參數值轉換成它的SQL字面量符號。
|
||||
Exec方法使用SQL字面量替换在查询字符串中的每个'?'；SQL字面量表示相应参数的值，它有可能是一个布尔值，一个数字，一个字符串，或者nil空值。用这种方式构造查询可以帮助避免SQL注入攻击；这种攻击就是对手可以通过利用输入内容中不正确的引文来控制查询语句。在Exec函数内部，我们可能会找到像下面这样的一个函数，它会将每一个参数值转换成它的SQL字面量符号。
|
||||
|
||||
```go
|
||||
func sqlQuote(x interface{}) string {
|
||||
@@ -42,9 +42,9 @@ func sqlQuote(x interface{}) string {
|
||||
}
|
||||
```
|
||||
|
||||
switch語句可以簡化if-else鏈，如果這個if-else鏈對一連串值做相等測試。一個相似的type switch（類型開關）可以簡化類型斷言的if-else鏈。
|
||||
switch语句可以简化if-else链，如果这个if-else链对一连串值做相等测试。一个相似的type switch（类型开关）可以简化类型断言的if-else链。
|
||||
|
||||
在它最簡單的形式中，一個類型開關像普通的switch語句一樣，它的運算對象是x.(type)－它使用了關鍵詞字面量type－併且每個case有一到多個類型。一個類型開關基於這個接口值的動態類型使一個多路分支有效。這個nil的case和if x == nil匹配，併且這個default的case和如果其它case都不匹配的情況匹配。一個對sqlQuote的類型開關可能會有這些case：
|
||||
在它最简单的形式中，一个类型开关像普通的switch语句一样，它的运算对象是x.(type)－它使用了关键词字面量type－并且每个case有一到多个类型。一个类型开关基于这个接口值的动态类型使一个多路分支有效。这个nil的case和if x == nil匹配，并且这个default的case和如果其它case都不匹配的情况匹配。一个对sqlQuote的类型开关可能会有这些case：
|
||||
|
||||
```go
|
||||
switch x.(type) {
|
||||
@@ -56,17 +56,17 @@ switch x.(type) {
|
||||
}
|
||||
```
|
||||
|
||||
和(§1.8)中的普通switch語句一樣，每一個case會被順序的進行考慮，併且當一個匹配找到時，這個case中的內容會被執行。當一個或多個case類型是接口時，case的順序就會變得很重要，因爲可能會有兩個case同時匹配的情況。default case相對其它case的位置是無所謂的。它不會允許落空發生。
|
||||
和(§1.8)中的普通switch语句一样，每一个case会被顺序的进行考虑，并且当一个匹配找到时，这个case中的内容会被执行。当一个或多个case类型是接口时，case的顺序就会变得很重要，因为可能会有两个case同时匹配的情况。default case相对其它case的位置是无所谓的。它不会允许落空发生。
|
||||
|
||||
註意到在原來的函數中，對於bool和string情況的邏輯需要通過類型斷言訪問提取的值。因爲這個做法很典型，類型開關語句有一個擴展的形式，它可以將提取的值綁定到一個在每個case范圍內的新變量。
|
||||
注意到在原来的函数中，对于bool和string情况的逻辑需要通过类型断言访问提取的值。因为这个做法很典型，类型开关语句有一个扩展的形式，它可以将提取的值绑定到一个在每个case范围内的新变量。
|
||||
|
||||
```go
|
||||
switch x := x.(type) { /* ... */ }
|
||||
```
|
||||
|
||||
這里我們已經將新的變量也命名爲x；和類型斷言一樣，重用變量名是很常見的。和一個switch語句相似地，一個類型開關隱式的創建了一個語言塊，因此新變量x的定義不會和外面塊中的x變量衝突。每一個case也會隱式的創建一個單獨的語言塊。
|
||||
这里我们已经将新的变量也命名为x；和类型断言一样，重用变量名是很常见的。和一个switch语句相似地，一个类型开关隐式的创建了一个语言块，因此新变量x的定义不会和外面块中的x变量冲突。每一个case也会隐式的创建一个单独的语言块。
|
||||
|
||||
使用類型開關的擴展形式來重寫sqlQuote函數會讓這個函數更加的清晰：
|
||||
使用类型开关的扩展形式来重写sqlQuote函数会让这个函数更加的清晰：
|
||||
|
||||
```go
|
||||
func sqlQuote(x interface{}) string {
|
||||
@@ -88,6 +88,6 @@ func sqlQuote(x interface{}) string {
|
||||
}
|
||||
```
|
||||
|
||||
在這個版本的函數中，在每個單一類型的case內部，變量x和這個case的類型相同。例如，變量x在bool的case中是bool類型和string的case中是string類型。在所有其它的情況中，變量x是switch運算對象的類型（接口）；在這個例子中運算對象是一個interface{}。當多個case需要相同的操作時，比如int和uint的情況，類型開關可以很容易的合併這些情況。
|
||||
在这个版本的函数中，在每个单一类型的case内部，变量x和这个case的类型相同。例如，变量x在bool的case中是bool类型和string的case中是string类型。在所有其它的情况中，变量x是switch运算对象的类型（接口）；在这个例子中运算对象是一个interface{}。当多个case需要相同的操作时，比如int和uint的情况，类型开关可以很容易的合并这些情况。
|
||||
|
||||
盡管sqlQuote接受一個任意類型的參數，但是這個函數隻會在它的參數匹配類型開關中的一個case時運行到結束；其它情況的它會panic出“unexpected type”消息。雖然x的類型是interface{}，但是我們把它認爲是一個int，uint，bool，string，和nil值的discriminated union（可識别聯合）
|
||||
尽管sqlQuote接受一个任意类型的参数，但是这个函数只会在它的参数匹配类型开关中的一个case时运行到结束；其它情况的它会panic出“unexpected type”消息。虽然x的类型是interface{}，但是我们把它认为是一个int，uint，bool，string，和nil值的discriminated union（可识别联合）
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
## 7.14. 示例: 基於標記的XML解碼
|
||||
## 7.14. 示例: 基于标记的XML解码
|
||||
|
||||
第4.5章節展示了如何使用encoding/json包中的Marshal和Unmarshal函數來將JSON文檔轉換成Go語言的數據結構。encoding/xml包提供了一個相似的API。當我們想構造一個文檔樹的表示時使用encoding/xml包會很方便，但是對於很多程序併不是必須的。encoding/xml包也提供了一個更低層的基於標記的API用於XML解碼。在基於標記的樣式中，解析器消費輸入和産生一個標記流；四個主要的標記類型－StartElement，EndElement，CharData，和Comment－每一個都是encoding/xml包中的具體類型。每一個對(\*xml.Decoder).Token的調用都返迴一個標記。
|
||||
第4.5章节展示了如何使用encoding/json包中的Marshal和Unmarshal函数来将JSON文档转换成Go语言的数据结构。encoding/xml包提供了一个相似的API。当我们想构造一个文档树的表示时使用encoding/xml包会很方便，但是对于很多程序并不是必须的。encoding/xml包也提供了一个更低层的基于标记的API用于XML解码。在基于标记的样式中，解析器消费输入和产生一个标记流；四个主要的标记类型－StartElement，EndElement，CharData，和Comment－每一个都是encoding/xml包中的具体类型。每一个对(\*xml.Decoder).Token的调用都返回一个标记。
|
||||
|
||||
這里顯示的是和這個API相關的部分：
|
||||
这里显示的是和这个API相关的部分：
|
||||
|
||||
<u><i>encoding/xml</i></u>
|
||||
```go
|
||||
@@ -33,9 +33,9 @@ func NewDecoder(io.Reader) *Decoder
|
||||
func (*Decoder) Token() (Token, error) // returns next Token in sequence
|
||||
```
|
||||
|
||||
這個沒有方法的Token接口也是一個可識别聯合的例子。傳統的接口如io.Reader的目的是隱藏滿足它的具體類型的細節，這樣就可以創造出新的實現；在這個實現中每個具體類型都被統一地對待。相反，滿足可識别聯合的具體類型的集合被設計確定和暴露，而不是隱藏。可識别的聯合類型幾乎沒有方法；操作它們的函數使用一個類型開關的case集合來進行表述；這個case集合中每一個case中有不同的邏輯。
|
||||
这个没有方法的Token接口也是一个可识别联合的例子。传统的接口如io.Reader的目的是隐藏满足它的具体类型的细节，这样就可以创造出新的实现；在这个实现中每个具体类型都被统一地对待。相反，满足可识别联合的具体类型的集合被设计确定和暴露，而不是隐藏。可识别的联合类型几乎没有方法；操作它们的函数使用一个类型开关的case集合来进行表述；这个case集合中每一个case中有不同的逻辑。
|
||||
|
||||
下面的xmlselect程序獲取和打印在一個XML文檔樹中確定的元素下找到的文本。使用上面的API，它可以在輸入上一次完成它的工作而從來不要具體化這個文檔樹。
|
||||
下面的xmlselect程序获取和打印在一个XML文档树中确定的元素下找到的文本。使用上面的API，它可以在输入上一次完成它的工作而从来不要具体化这个文档树。
|
||||
|
||||
<u><i>gopl.io/ch7/xmlselect</i></u>
|
||||
```go
|
||||
@@ -89,9 +89,9 @@ func containsAll(x, y []string) bool {
|
||||
}
|
||||
```
|
||||
|
||||
每次main函數中的循環遇到一個StartElement時，它把這個元素的名稱壓到一個棧里；併且每次遇到EndElement時，它將名稱從這個棧中推出。這個API保證了StartElement和EndElement的序列可以被完全的匹配，甚至在一個糟糕的文檔格式中。註釋會被忽略。當xmlselect遇到一個CharData時，隻有當棧中有序地包含所有通過命令行參數傳入的元素名稱時它才會輸出相應的文本。
|
||||
每次main函数中的循环遇到一个StartElement时，它把这个元素的名称压到一个栈里；并且每次遇到EndElement时，它将名称从这个栈中推出。这个API保证了StartElement和EndElement的序列可以被完全的匹配，甚至在一个糟糕的文档格式中。注释会被忽略。当xmlselect遇到一个CharData时，只有当栈中有序地包含所有通过命令行参数传入的元素名称时它才会输出相应的文本。
|
||||
|
||||
下面的命令打印出任意出現在兩層div元素下的h2元素的文本。它的輸入是XML的説明文檔，併且它自己就是XML文檔格式的。
|
||||
下面的命令打印出任意出现在两层div元素下的h2元素的文本。它的输入是XML的说明文档，并且它自己就是XML文档格式的。
|
||||
|
||||
```
|
||||
$ go build gopl.io/ch1/fetch
|
||||
@@ -108,11 +108,11 @@ html body div div h2: B Definitions for Character Normalization
|
||||
...
|
||||
```
|
||||
|
||||
**練習 7.17：** 擴展xmlselect程序以便讓元素不僅僅可以通過名稱選擇，也可以通過它們CSS樣式上屬性進行選擇；例如一個像這樣<div id="page" class="wide">的元素可以通過匹配id或者class同時還有它的名稱來進行選擇。
|
||||
**练习 7.17：** 扩展xmlselect程序以便让元素不仅仅可以通过名称选择，也可以通过它们CSS样式上属性进行选择；例如一个像这样<div id="page" class="wide">的元素可以通过匹配id或者class同时还有它的名称来进行选择。
|
||||
|
||||
**練習 7.18：** 使用基於標記的解碼API，編寫一個可以讀取任意XML文檔和構造這個文檔所代表的普通節點樹的程序。節點有兩種類型：CharData節點表示文本字符串，和 Element節點表示被命名的元素和它們的屬性。每一個元素節點有一個字節點的切片。
|
||||
**练习 7.18：** 使用基于标记的解码API，编写一个可以读取任意XML文档和构造这个文档所代表的普通节点树的程序。节点有两种类型：CharData节点表示文本字符串，和 Element节点表示被命名的元素和它们的属性。每一个元素节点有一个字节点的切片。
|
||||
|
||||
你可能發現下面的定義會對你有幫助。
|
||||
你可能发现下面的定义会对你有帮助。
|
||||
|
||||
```go
|
||||
import "encoding/xml"
|
||||
|
||||
@@ -1,9 +1,9 @@
|
||||
## 7.15. 一些建議
|
||||
## 7.15. 一些建议
|
||||
|
||||
當設計一個新的包時，新的Go程序員總是通過創建一個接口的集合開始和後面定義滿足它們的具體類型。這種方式的結果就是有很多的接口，它們中的每一個僅隻有一個實現。不要再這麽做了。這種接口是不必要的抽象；它們也有一個運行時損耗。你可以使用導出機製(§6.6)來限製一個類型的方法或一個結構體的字段是否在包外可見。接口隻有當有兩個或兩個以上的具體類型必須以相同的方式進行處理時才需要。
|
||||
当设计一个新的包时，新的Go程序员总是通过创建一个接口的集合开始和后面定义满足它们的具体类型。这种方式的结果就是有很多的接口，它们中的每一个仅只有一个实现。不要再这么做了。这种接口是不必要的抽象；它们也有一个运行时损耗。你可以使用导出机制(§6.6)来限制一个类型的方法或一个结构体的字段是否在包外可见。接口只有当有两个或两个以上的具体类型必须以相同的方式进行处理时才需要。
|
||||
|
||||
當一個接口隻被一個單一的具體類型實現時有一個例外，就是由於它的依賴，這個具體類型不能和這個接口存在在一個相同的包中。這種情況下，一個接口是解耦這兩個包的一個好好方式。
|
||||
当一个接口只被一个单一的具体类型实现时有一个例外，就是由于它的依赖，这个具体类型不能和这个接口存在在一个相同的包中。这种情况下，一个接口是解耦这两个包的一个好好方式。
|
||||
|
||||
因爲在Go語言中隻有當兩個或更多的類型實現一個接口時才使用接口，它們必定會從任意特定的實現細節中抽象出來。結果就是有更少和更簡單方法（經常和io.Writer或 fmt.Stringer一樣隻有一個）的更小的接口。當新的類型出現時，小的接口更容易滿足。對於接口設計的一個好的標準就是 ask only for what you need（隻考慮你需要的東西）
|
||||
因为在Go语言中只有当两个或更多的类型实现一个接口时才使用接口，它们必定会从任意特定的实现细节中抽象出来。结果就是有更少和更简单方法（经常和io.Writer或 fmt.Stringer一样只有一个）的更小的接口。当新的类型出现时，小的接口更容易满足。对于接口设计的一个好的标准就是 ask only for what you need（只考虑你需要的东西）
|
||||
|
||||
我們完成了對methods和接口的學習過程。Go語言良好的支持面向對象風格的編程，但隻不是説你僅僅隻能使用它。不是任何事物都需要被當做成一個對象；獨立的函數有它們自己的用處，未封裝的數據類型也是這樣。同時觀察到這兩個，在本書的前五章的例子中沒有調用超過兩打方法，像input.Scan，與之相反的是普遍的函數調用如fmt.Printf。
|
||||
我们完成了对methods和接口的学习过程。Go语言良好的支持面向对象风格的编程，但只不是说你仅仅只能使用它。不是任何事物都需要被当做成一个对象；独立的函数有它们自己的用处，未封装的数据类型也是这样。同时观察到这两个，在本书的前五章的例子中没有调用超过两打方法，像input.Scan，与之相反的是普遍的函数调用如fmt.Printf。
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# 第七章 接口
|
||||
|
||||
接口類型是對其它類型行爲的抽象和概括；因爲接口類型不會和特定的實現細節綁定在一起，通過這種抽象的方式我們可以讓我們的函數更加靈活和更具有適應能力。
|
||||
接口类型是对其它类型行为的抽象和概括；因为接口类型不会和特定的实现细节绑定在一起，通过这种抽象的方式我们可以让我们的函数更加灵活和更具有适应能力。
|
||||
|
||||
很多面向對象的語言都有相似的接口概念，但Go語言中接口類型的獨特之處在於它是滿足隱式實現的。也就是説，我們沒有必要對於給定的具體類型定義所有滿足的接口類型；簡單地擁有一些必需的方法就足夠了。這種設計可以讓你創建一個新的接口類型滿足已經存在的具體類型卻不會去改變這些類型的定義；當我們使用的類型來自於不受我們控製的包時這種設計尤其有用。
|
||||
很多面向对象的语言都有相似的接口概念，但Go语言中接口类型的独特之处在于它是满足隐式实现的。也就是说，我们没有必要对于给定的具体类型定义所有满足的接口类型；简单地拥有一些必需的方法就足够了。这种设计可以让你创建一个新的接口类型满足已经存在的具体类型却不会去改变这些类型的定义；当我们使用的类型来自于不受我们控制的包时这种设计尤其有用。
|
||||
|
||||
在本章，我們會開始看到接口類型和值的一些基本技巧。順着這種方式我們將學習幾個來自標準庫的重要接口。很多Go程序中都盡可能多的去使用標準庫中的接口。最後,我們會在(§7.10)看到類型斷言的知識，在(§7.13)看到類型開關的使用併且學到他們是怎樣讓不同的類型的概括成爲可能。
|
||||
在本章，我们会开始看到接口类型和值的一些基本技巧。顺着这种方式我们将学习几个来自标准库的重要接口。很多Go程序中都尽可能多的去使用标准库中的接口。最后,我们会在(§7.10)看到类型断言的知识，在(§7.13)看到类型开关的使用并且学到他们是怎样让不同的类型的概括成为可能。
|
||||
|
||||
Reference in New Issue
Block a user