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时，多态机制依然有效。因为方法的实例实现（就是在类中定义的实现）的优先级是高于具有相同静态签名的扩展方法的实现的。
感觉原文作者是这个意思吧：当你以实例方法的形式重写与接口方法静态签名相同的扩展方法后，由于实例方法优先级高，所以在使用过程中，实例方法会被优先调用，这也就实现了多态。因此，采用接口扩展方法实现多继承的方案是可行的。因为，当采用多基类继承方式的时候，是完美支持多态的，如果以接口扩展方法的方式实现多继承功能时不能完美支持多态，则该方式是不可行的。
相关文章
