不错呦！smile@林凯西，确保“准备文件”中的几个文件都有安装，S...您好，看了您这篇帖子觉得很有帮助。但是有个问题想请...我的修改过了怎么还被恶意注册呢 @jjjjiiii 用PJ快9年了，主要是A...PJ3啊，貌似很少有人用PJ了，现在不是WP就是z...@332347365，我当时接入时错误码没有-10...楼主，ChkValue值应为-103是什么意思呢？...大哥 你最近能看到我发的信息，请跟我联系，我有个制...
Effective C# 原则29：仅在对基类进行强制更新时才使用new修饰符
编辑:dnawo 日期:2010-01-02
Effective C# 原则28：避免转换操作
编辑:dnawo 日期:2010-01-02
转换操作是一种等代类型(Substitutability)间操作转换操作。等代类型就是指一个类可以取代另一个类。这可能是件好事：一个派生类的对象可以被它基类的一个对象取代，一个经典的例子就是形状继承。先有一个形状类，然后派生出很多其它的类型：长方形，椭圆形，圆形以及其它。你可以在任何地方用图形状来取代圆形，这就是多态的等代类型。这是正确的，因为圆形就是一个特殊的形状。当你创建一个类时，明确的类型转化是可以自动完成的。正如.Net中类的继承，因为System.Object是所有类型的基类，所以任何类型都可以用System.Obejct来取代。同样的情况，你所创建的任何类型，也应该可以用它所实现的接口来取代，或者用它的基类接口来取代，或者就用基类来取代。不仅如此，C#语言还支持很多其它的转换。
当你为某个类型添加转换操作时，就等于是告诉编译器：你的类型可以被目标类所取代。这可能会引发一些潜在的错误，因为你的类型很可能并不能被目标类型所取代(译注：这里并不是指继承关系上的类型转换，而是C#语言许可我们的另一种转换，请看后文)。它的副作用就是修改了目标类型的状态后可能对原类型根本无效。更糟糕的是，如果你的转换产生了临时对象，那么副作用就是你直接修改了临时对象，而且它会永久丢失在垃圾回收器。总之，使用转换操作应该基于编译时的类型对象，而不是运行时的类型对象。用户可能须要对类型进行多样化的强制转换操作，这样的实际操作可能产生不维护的代码。
你可以使用转换操作把一个未知类型转化为你的类型，这会更加清楚的表现创建新对象的操作(译注：这样的转换是要创建新对象的)。转换操作会在代码中产生难于发现的问题。假设有这样一种情况，你创建了如图3.1那样的类库结构。椭圆和圆都是从形状类继承下来的，尽管你相信椭圆和圆是相关的，但还是决定保留这样的继承关系。这是因为你不想在继承关系中使用非抽象叶子类，这会在从椭圆类上继承圆类时，有一些不好实现的难题存在。然而，你又意识到每一个圆形应该是一个椭圆，另外某些椭圆也可能是圆形。
当你为某个类型添加转换操作时，就等于是告诉编译器：你的类型可以被目标类所取代。这可能会引发一些潜在的错误，因为你的类型很可能并不能被目标类型所取代(译注：这里并不是指继承关系上的类型转换，而是C#语言许可我们的另一种转换，请看后文)。它的副作用就是修改了目标类型的状态后可能对原类型根本无效。更糟糕的是，如果你的转换产生了临时对象，那么副作用就是你直接修改了临时对象，而且它会永久丢失在垃圾回收器。总之，使用转换操作应该基于编译时的类型对象，而不是运行时的类型对象。用户可能须要对类型进行多样化的强制转换操作，这样的实际操作可能产生不维护的代码。
你可以使用转换操作把一个未知类型转化为你的类型，这会更加清楚的表现创建新对象的操作(译注：这样的转换是要创建新对象的)。转换操作会在代码中产生难于发现的问题。假设有这样一种情况，你创建了如图3.1那样的类库结构。椭圆和圆都是从形状类继承下来的，尽管你相信椭圆和圆是相关的，但还是决定保留这样的继承关系。这是因为你不想在继承关系中使用非抽象叶子类，这会在从椭圆类上继承圆类时，有一些不好实现的难题存在。然而，你又意识到每一个圆形应该是一个椭圆，另外某些椭圆也可能是圆形。
Effective C# 原则27：避免使用ICloneable
编辑:dnawo 日期:2010-01-01
ICloneable看上去是个不错的主意：为一个类型实现ICloneable接口后就可以支持拷贝了。如果你不想支持拷贝，就不要实现它。
但你的对象并不是在一个“真空”的环境中运行，但考虑到对派生类的些影响，最好还是对ICloneable支持。一但某个类型支持ICloneable, 那么所有的派生类都必须保持一致，也就是所有的成员必须支持ICloneable接口或者提供一种机制支持拷贝。最后，支持深拷贝的对象，在创建设计时如果包含有网络结构的对象，会使拷贝很成问题。ICloneable也觉察到这个问题，在它的官方定义中有说明：它同时支持深拷贝和浅拷贝。浅拷贝是创建一个新的对象，这个新对象对包含当前对象中所有成员变量的拷贝。如果这些成员变量是引用类型的，那么新的对象与源对象包含了同样的引用。而深拷贝则可以很好的拷贝所有成员变量，引用类型也被递归的进行了拷贝。对于像整型这样的内置类型，深拷贝和浅拷贝是一样的结果。哪一种是我们的类型应该支持的呢？这取决于类型本身。但同时在一个类型中混用深拷贝和浅拷贝会导致很多不一致的问题。一但你涉及到ICloneable这个问题，这样的混用就很难解脱了。大多数时候，我们应该完全避免使用ICloneable，让类更简单一些。这样使用和实现都相对简单得多。
任何只以内置类型做为成员的值类型不必支持ICloneable; 用简单的赋值语句对结构的所有值进行拷贝比Clone()要高效得多。Clone()方法必须对返回类型进行装箱，这样才能强制转化成一个System.Object的引用。而调用者还得再用强制转化从箱子中取回这个值。我知道你已经有足够的能力这样做，但不要用Clone()函数来取代赋值语句。
但你的对象并不是在一个“真空”的环境中运行，但考虑到对派生类的些影响，最好还是对ICloneable支持。一但某个类型支持ICloneable, 那么所有的派生类都必须保持一致，也就是所有的成员必须支持ICloneable接口或者提供一种机制支持拷贝。最后，支持深拷贝的对象，在创建设计时如果包含有网络结构的对象，会使拷贝很成问题。ICloneable也觉察到这个问题，在它的官方定义中有说明：它同时支持深拷贝和浅拷贝。浅拷贝是创建一个新的对象，这个新对象对包含当前对象中所有成员变量的拷贝。如果这些成员变量是引用类型的，那么新的对象与源对象包含了同样的引用。而深拷贝则可以很好的拷贝所有成员变量，引用类型也被递归的进行了拷贝。对于像整型这样的内置类型，深拷贝和浅拷贝是一样的结果。哪一种是我们的类型应该支持的呢？这取决于类型本身。但同时在一个类型中混用深拷贝和浅拷贝会导致很多不一致的问题。一但你涉及到ICloneable这个问题，这样的混用就很难解脱了。大多数时候，我们应该完全避免使用ICloneable，让类更简单一些。这样使用和实现都相对简单得多。
任何只以内置类型做为成员的值类型不必支持ICloneable; 用简单的赋值语句对结构的所有值进行拷贝比Clone()要高效得多。Clone()方法必须对返回类型进行装箱，这样才能强制转化成一个System.Object的引用。而调用者还得再用强制转化从箱子中取回这个值。我知道你已经有足够的能力这样做，但不要用Clone()函数来取代赋值语句。
Effective C# 原则26：用IComparable和IComparer实现对象的顺序关系
编辑:dnawo 日期:2010-01-01
你的类型应该有一个顺序关系，以便在集合中描述它们如何存储以及排序。.Net框架为你提供了两个接口来描述对象的顺序关系：IComparable 和IComparer。IComparable 为你的类定义了自然顺序，而实现IComparer接口的类可以描述其它可选的顺序。你可以在实现接口时，定义并实现你自己关系操作符(<，>，<=，>=)，用于避免在运行时默认比较关系的低效问题。这一原则将讨论如何实现顺序关系，以便.Net框架的核心可以通过你定义的接口对你的类型进行排序。这样用户可以在些操作上得更好的效率。
IComparable接口只有一个方法：CompareTo()，这个方法沿用了传统的C函数库里的strcmp函数的实现原则：如果当前对象比目标对象小，它的返回值小于0；如果相等就返回0；如果当前对象比目标对象大，返回值就大于0。IComparable以System.Object做为参数，因此在使用这个函数时，你须要对运行时的对象进行检测。每次进行比较时，你必须重新解释参数的类型：
IComparable接口只有一个方法：CompareTo()，这个方法沿用了传统的C函数库里的strcmp函数的实现原则：如果当前对象比目标对象小，它的返回值小于0；如果相等就返回0；如果当前对象比目标对象大，返回值就大于0。IComparable以System.Object做为参数，因此在使用这个函数时，你须要对运行时的对象进行检测。每次进行比较时，你必须重新解释参数的类型：
复制内容到剪贴板
程序代码
程序代码public struct Customer : IComparable
Effective C# 原则25: 让你的类型支持序列化
编辑:dnawo 日期:2010-01-01
对象的持久是类型的一个核心功能。这是一个在你忽略对它的支持以前，没有人会注意到的基本元素之一。 如果你的类型不能恰当的支持序列化，那么对于把你类的做为基类或者成员的开发人员来说，你会给他们增加很多的工作量。当你的类型不支持序列化时，他们不得不围绕这工作，自己添加实现这个标准的功能。而对于不能访问类的私有成员的开发人来说，恰当的实现你的类型的序列化是不太可能的。如果你的类型不支持序列化，那么对于你的用户来说，想再要实现它是很困难或者根本就不可能的事。
取而代之的是，为你的实际类型添加序列化。对于那些不用承载UI元素，窗口，或者表单的类型来说这是有实际意义的。感觉有额外的工作是没有理由的，.Net的序列化是很简单的，以至于你没有任意的借口说不支持它。在多数情况下，添加Serializable特性就足够了：
取而代之的是，为你的实际类型添加序列化。对于那些不用承载UI元素，窗口，或者表单的类型来说这是有实际意义的。感觉有额外的工作是没有理由的，.Net的序列化是很简单的，以至于你没有任意的借口说不支持它。在多数情况下，添加Serializable特性就足够了：
复制内容到剪贴板 程序代码
程序代码[Serializable]
Effective C# 原则24：选择申明式编程而不是命令式编程
编辑:dnawo 日期:2009-12-31
与命令式编程相比，申明式编程可以用更简单，更清楚的方法来描述软件的行为。申明式编程就是说用申明来定义程序的行为，而不是写一些指令。在C#里，也和其它大多数语言一样，你的大多数程序都是命令式的：在程序中写一个方法来定义行为。在C#中，你在编程时使用特性就是申明式编程。你添加一个特性到类，属性，数据成员，或者是方法上，然后.Net运行时就会为你添加一些行为。这样申明的目的就是简单易用，而且易于阅读和维护。
让我们以一个你已经使用过的例子开始。当你写你的第一个ASP.Net Web服务时，向导会生成这样的代码：
让我们以一个你已经使用过的例子开始。当你写你的第一个ASP.Net Web服务时，向导会生成这样的代码：
复制内容到剪贴板 程序代码
程序代码[WebMethod]
Effective C# 原则23：避免返回内部类对象的引用
编辑:dnawo 日期:2009-12-31
Effective C# 原则22：用事件定义对外接口
编辑:dnawo 日期:2009-12-31
可以用事件给你的类型定义一些外部接口。事件是基于委托的，因为委托可以提供类型安全的函数签名到事件句柄上。加上大多数委托的例子都是使用事件来说明的，以至于开发人员一开始都认为委托与事件是一回事。在原则21里，我已经展示了一些不在事件上使用委托的例子。在你的类型与其它多个客户进行通信时，为了完成它们的行为，你必须引发事件。
一个简单的例子，你正在做一个日志类，就像一个信息发布机一样在应用程序里发布所有的消息。它接受所有从程序源发布的消息，并且把这些消息发布到感兴趣的听众那里。这些听众可以是控制台，数据库，系统日志，或者是其它的机制。就可以定义一个像下面这样的类，当消息到达时来引发事件：
一个简单的例子，你正在做一个日志类，就像一个信息发布机一样在应用程序里发布所有的消息。它接受所有从程序源发布的消息，并且把这些消息发布到感兴趣的听众那里。这些听众可以是控制台，数据库，系统日志，或者是其它的机制。就可以定义一个像下面这样的类，当消息到达时来引发事件：
复制内容到剪贴板 程序代码
程序代码public class LoggerEventArgs : EventArgs
