回到简体

ch7/ch7-15.md

@@ -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。