转换操作是一种等代类型(Substitutability)间操作转换操作。等代类型就是指一个类可以取代另一个类。这可能是件好事：一个派生类的对象可以被它基类的一个对象取代，一个经典的例子就是形状继承。先有一个形状类，然后派生出很多其它的类型：长方形，椭圆形，圆形以及其它。你可以在任何地方用图形状来取代圆形，这就是多态的等代类型。这是正确的，因为圆形就是一个特殊的形状。当你创建一个类时，明确的类型转化是可以自动完成的。正如.Net中类的继承，因为System.Object是所有类型的基类，所以任何类型都可以用System.Obejct来取代。同样的情况，你所创建的任何类型，也应该可以用它所实现的接口来取代，或者用它的基类接口来取代，或者就用基类来取代。不仅如此，C#语言还支持很多其它的转换。 当你为某个类型添加转换操作时，就等于是告诉编译器：你的类型可以被目标类所取代。这可能会引发一些潜在的错误，因为你的类型很可能并不能被目标类型所取代(译注：这里并不是指继承关系上的类型转换，而是C#语言许可我们的另一种转换，请看后文)。它的副作用就是修改了目标类型的状态后可能对原类型根本无效。更糟糕的是，如果你的转换产生了临时对象，那么副作用就是你直接修改了临时对象，而且它会永久丢失在垃圾回收器。总之，使用转换操作应该基于编译时的类型对象，而不是运行时的类型对象。用户可能须要对类型进行多样化的强制转换操作，这样的实际操作可能产生不维护的代码。 你可以使用转换操作把一个未知类型转化为你的类型，这会更加清楚的表现创建新对象的操作(译注：这样的转换是要创建新对象的)。转换操作会在代码中产生难于发现的问题。假设有这样一种情况，你创建了如图3.1那样的类库结构。椭圆和圆都是从形状类继承下来的，尽管你相信椭圆和圆是相关的，但还是决定保留这样的继承关系。这是因为你不想在继承关系中使用非抽象叶子类，这会在从椭圆类上继承圆类时，有一些不好实现的难题存在。然而，你又意识到每一个圆形应该是一个椭圆，另外某些椭圆也可能是圆形。…
📂 Web编程
👤 博主
📅 2010-01-02
👁 4581
👍 0
阅读全文 →
ICloneable看上去是个不错的主意：为一个类型实现ICloneable接口后就可以支持拷贝了。如果你不想支持拷贝，就不要实现它。 但你的对象并不是在一个“真空”的环境中运行，但考虑到对派生类的些影响，最好还是对ICloneable支持。一但某个类型支持ICloneable, 那么所有的派生类都必须保持一致，也就是所有的成员必须支持ICloneable接口或者提供一种机制支持拷贝。最后，支持深拷贝的对象，在创建设计时如果包含有网络结构的对象，会使拷贝很成问题。ICloneable也觉察到这个问题，在它的官方定义中有说明：它同时支持深拷贝和浅拷贝。浅拷贝是创建一个新的对象，这个新对象对包含当前对象中所有成员变量的拷贝。如果这些成员变量是引用类型的，那么新的对象与源对象包含了同样的引用。而深拷贝则可以很好的拷贝所有成员变量，引用类型也被递归的进行了拷贝。对于像整型这样的内置类型，深拷贝和浅拷贝是一样的结果。哪一种是我们的类型应该支持的呢？这取决于类型本身。但同时在一个类型中混用深拷贝和浅拷贝会导致很多不一致的问题。一但你涉及到ICloneable这个问题，这样的混用就很难解脱了。大多数时候，我们应该完全避免使用ICloneable，让类更简单一些。这样使用和实现都相对简单得多。 任何只以内置类型做为成员的值类型不必支持ICloneable; 用简单的赋值语句对结构的所有值进行拷贝比Clone()要高效得多。Clone()方法必须对返回类型进行装箱，这样才能强制转化成一个System.Object的引用。而调用者还得再用强制转化从箱子中取回这个值。我知道你已经有足够的能力这样做，但不要用Clone()函数来取代赋值语句。…
📂 Web编程
👤 博主
📅 2010-01-01
👁 4599
👍 0
阅读全文 →
你的类型应该有一个顺序关系，以便在集合中描述它们如何存储以及排序。.Net框架为你提供了两个接口来描述对象的顺序关系：IComparable 和IComparer。IComparable 为你的类定义了自然顺序，而实现IComparer接口的类可以描述其它可选的顺序。你可以在实现接口时，定义并实现你自己关系操作符(，=)，用于避免在运行时默认比较关系的低效问题。这一原则将讨论如何实现顺序关系，以便.Net框架的核心可以通过你定义的接口对你的类型进行排序。这样用户可以在些操作上得更好的效率。 IComparable接口只有一个方法：CompareTo()，这个方法沿用了传统的C函数库里的strcmp函数的实现原则：如果当前对象比目标对象小，它的返回值小于0；如果相等就返回0；如果当前对象比目标对象大，返回值就大于0。IComparable以System.Object做为参数，因此在使用这个函数时，你须要对运行时的对象进行检测。每次进行比较时，你必须重新解释参数的类型： 关于实现比较与IComparable接口的一致性有很多不太喜欢的地方，首先就是你要检测参数的运行时类型。不正确的代码可以用任何类型做为参数来调用CompareTo方法。还有，正确的参数还必须进行装箱与拆箱后才能提供实际的比较。每次比较都要进行这样额外的开销。在对集合进行排序时，在对象上进行的平均比较次数为N x log(N)，而每次都会产生三次装箱与拆箱。对于一个有1000个点的数组来说，这将会产生大概20000次的装箱与拆箱操作，平均计算：N x log(n) 有7000次，每次比较有3次装箱与拆箱。因此，你必须自己找个可选的比较方法。你无法改变IComparable.CompareTo()的定义，但这并不意味着你要被迫让你的用户在一个弱类型的实现上也要忍受性能的损失。你可以重载CompareTo()方法，让它只对Customer 对象操作：…
📂 Web编程
👤 博主
📅 2010-01-01
👁 4589
👍 0
阅读全文 →
对象的持久是类型的一个核心功能。这是一个在你忽略对它的支持以前，没有人会注意到的基本元素之一。 如果你的类型不能恰当的支持序列化，那么对于把你类的做为基类或者成员的开发人员来说，你会给他们增加很多的工作量。当你的类型不支持序列化时，他们不得不围绕这工作，自己添加实现这个标准的功能。而对于不能访问类的私有成员的开发人来说，恰当的实现你的类型的序列化是不太可能的。如果你的类型不支持序列化，那么对于你的用户来说，想再要实现它是很困难或者根本就不可能的事。 取而代之的是，为你的实际类型添加序列化。对于那些不用承载UI元素，窗口，或者表单的类型来说这是有实际意义的。感觉有额外的工作是没有理由的，.Net的序列化是很简单的，以至于你没有任意的借口说不支持它。在多数情况下，添加Serializable特性就足够了： 只添加一个Serializable特性就足以让它可以序列化，是因为这它的成员都是可序列化的：string和int都是.Net序列化支持的。无论是否可能，都要给类型添加序列化支持是很重要的，原因在你添加另一个类做为新类的成员时就很明显了：…
📂 Web编程
👤 博主
📅 2010-01-01
👁 6809
👍 0
阅读全文 →