C#本質論和CLR via C#兩本好書，周老師可能是俗務纏身，太忙了吧，翻譯得只能讓人呵呵了。
你要是忙，別接那麼多活好不啦。
現在都在說供給側改革，都在大力提倡工匠精神，我們做技術的，還是踏實點好，對不啦？
對照一下李建忠老師翻譯的那一版CLR via C#，差距啊。
這裡，僅把隨手發現的幾個問題記錄一下，作為例子。
其實，在這兩本中譯本中，類似下面的翻譯失當的例子隨處可見。如果你不深究，也就無所謂了，但如果你是認認真真地在學習這兩本書，這種無處不在的瑕疵，極度影響閱讀感受，甚至影響對原作者思想的理解。
周老師這兩本譯作出版之前可能沒有通讀一遍進行校核，否則，這些不合邏輯的話怎麼會沒有發現並修正呢？
當我們學習李建忠老師翻譯的那一版，就好像是同時在和兩大高手學習技藝。讀者不止從原作者那裡學習到了知識，還從譯者身上汲取很多營養。
而拜讀周老師的譯作，咋說呢？反正只讀中譯本是看不懂，需要隨時參照原版去解讀中譯本。一本好書，從頭到尾一口氣讀完的酣暢淋漓的感覺完全找不到。對譯者失去了信任，讀起來總是要加著小心，很不爽。
當然， 必須說，從周老師的譯作中，我學習到了很多很多的知識。這裡，只是希望周老師能把工作做得更好，貢獻出更好的精品，以給我們這些C#的學習者更大的幫助。
C#本質論第四版
7.3.3 顯式接口實現與隱式接口實現的比較
原文：
The key difference between implicit and explicit member interface implementation
lies not in the syntax of the method declaration, but rather in
the ability to access the method by name through an instance of the type
rather than via the interface.
原書中的譯文：
對於隱式和顯式實現的接口成員，關鍵區別不在於成員聲明的語法，而在於通過類型的實例而不是接口訪問成員的能力。
應該的意思是：
采用顯式方式或者隱式方式來實現接口成員，其關鍵區別，並不在於聲明接口成員所采用的語法的不同，而是：隱式方式實現的接口成員可由類的實例對象直接調用，而顯式方式實現的接口，則必須首先將類的實例對象轉換為接口類型後方可調用。
7.5 節，224頁
原文：
In contrast, implementing ISettingsProvider assumes that there is
never a reason to have a class that can write settings without reading them.
The inheritance relationship between ISettingsProvider and IReadableSettingsProvider, therefore, forces the combined total of both interfaces on the ISettingsProvider class.
原書中的譯文：
相反，實現ISettingsProvider是基於這樣一個前提:任何類都不可能只能寫入而不能讀取設置。因此， ISettingsProvider、和IReadableSettingsProvider之間的繼承關系強迫在FileSettingsProvider類上合並這兩個接口。
合並兩個接口，呵呵，請問周老師，如何合並呢？
應該是：ISettingsProvider的設計者之所以采用繼承於IReadableSettingProvider，而不是將兩個接口相互獨立，並列提供給使用者，是基於這樣一個考慮：任何類都不可能只能寫入而不能
讀取設置。采用繼承的方式，則迫使使用者必須同時實現這兩個接口（一個寫入設置，一個讀出設置）。而如果采用兩接口相互獨立地並列提供給用戶的方式，則可能會導致用戶只實現寫入接口，而不實現讀取接口。這是不符合常規的。
227頁，關於利用接口實現多繼承
原文：
One possible improvement that works if the implemented members are methods (not properties) is to define interface extension methods for the additional functionality “derived” from the second base class. An extension method on IPerson could provide a method called VerifyCredentials(), for example, and all classes that implement IPerson—even an IPerson interface that had no members but just extension methods—would have a default implementation of VerifyCredentials(). What makes this approach viable is the fact that polymorphism is still available, as is overriding. Overriding is supported because any instance implementation of a method will take priority over an extension method with the equivalent static signature.
原書譯文：
如果被實現的成員是方法( 而非屬性) ，那麼有一個辦法可對此進行改進。具體就是 為從第二個基類"派生"的附加功能定義接口擴展方法。例如， 可為IPe內on定義擴展方法 Veri句Credentials() 。這樣，實現IPerson ( 即使IPerson接口沒有成員，只有擴展方法) 的 所有類都會再lerifyC陀dentials()的默認實現。這之所以可行，完全是多態性和重寫的功勞。之所以支持重寫， 是因為方法的任何實例實現都要優先於具有相同靜態簽名的擴展方法。
我不是很清楚原書中論述的關於多態的思想和技術，但是，我感覺後面加黑體的這句話應該這麼翻譯才對：
這之所以可行，是因為這樣的事實：當overriding時，多態機制依然有效。因為方法的實例實現（就是在類中定義的實現）的優先級是高於具有相同靜態簽名的擴展方法的實現的。
感覺原文作者是這個意思吧：當你以實例方法的形式重寫與接口方法靜態簽名相同的擴展方法後，由於實例方法優先級高，所以在使用過程中，實例方法會被優先調用，這也就實現了多態。因此，采用接口擴展方法實現多繼承的方案是可行的。因為，當采用多基類繼承方式的時候，是完美支持多態的，如果以接口擴展方法的方式實現多繼承功能時不能完美支持多態，則該方式是不可行的。
