关于接口多态性一点说明
在讲述接口多态性时我们常看到类似的例子: 这边Anmial类的Move方法是孤立的,和其他成员没有关系,如果Anmial类还有一个Name属性,Move方法如下: 现在的问题是,Name不是IAction的成员,我们不能使用多态性对它进行赋值,那怎么给这个Name赋值呢?看下边方法: 这样接口多态性优势根本就无法显示出来了,解决方法是必须给Anmial添加一个非默认构造函数,在构造函数中必须可以给Name赋值!代码改后如下:
在讲述接口多态性时我们常看到类似的例子: 这边Anmial类的Move方法是孤立的,和其他成员没有关系,如果Anmial类还有一个Name属性,Move方法如下: 现在的问题是,Name不是IAction的成员,我们不能使用多态性对它进行赋值,那怎么给这个Name赋值呢?看下边方法: 这样接口多态性优势根本就无法显示出来了,解决方法是必须给Anmial添加一个非默认构造函数,在构造函数中必须可以给Name赋值!代码改后如下:
先来定义一个类MyFormat,它实现了ICustomFormatter和IFormatProvider接口,作用是将字符串转化为大写: 使用下看: 为什么下边一句没有发生作用?我们用Reflector来查看下String类的ToString(IFormatProvider provider)和Format(IFormatProvider provider, string format, params object args)两个方法代码: String.ToString(IFormatProvider provider)代码: String.Format(IFormatProvider provider, string format, params object args)代码:…
曾经一度为格式化输出而困惑,看着满天遍野的结构,都不敢去轻易触动。只能使用最安全,但是 低能的object.ToString()方法。终于忍受不了这种窘困的处境,下力气研究一番,也算是有点心得,希望和大家交流一下。 鉴于该格式化输出的结构过于繁琐,我不希望文章陷入条款的解释,于是,我从一个实际问题入手,一步一步地介绍格式化输出的概念,三个接口的意义,以及使用接口的一种模式(Pattern)。 1. PhoneNumber 类 假设我们有如下的一个类,用于存储我们的手机号码。该类提供了简单的ToString()实现,即直接返回含有短线(-)的电话号码。 2. 提供去掉短线的输出格式 (IFormattable)…
方法1:在SQL查询语句中拼接字段 方法2:在DataTable中新增一字段
VS2008默认生成类库项目时除了生成dll文件外,还会生成一个同名的pdb文件,它是一个程序数据库文件,保存着调试和项目状态信息,使用这些信息可以对程序的调试配置进行增量链接。通过设置,我们可以让VS2008不生成pdb文件。设置步骤:打开类库项目属性页面→切换到生成选项卡→点击高级按钮→将调试信息一项设置为none。
在.Net世界里,用得最多的方法之一就是System.Object.ToStrying()了。你应该为你所有的客户写一个"通情达理"的类(译注:这里是指这个类应该对用户友好)。要么,你就迫使所用类的用户,去使用类的属性并添加一些合理的易读的说明。这个以字符串形式存在,关于你设计的类的说明,可以很容易的向你的用户显示一些关于对象的信息到:Windows Form里,Web Form里,控制台输出。这些字符说明可以用于调试。你写的任何一种类型,都应该合理的重写这个方法。当你设计更多的复杂的类型时,你应该实现应变能力更强的IFormattable.ToString(). 承认这个:如果你不重写(override)这个常规的方法,或者只是写一个很糟糕的,你的客户将不得不为你修正它。 System.Object版的ToString()方法只返回类型的名字。这并没有太多有用的信息:"Rect","Point","Size"并不会如你所想的那样显示给你的用户。但那只是在你没有为你的类重写ToString()方法时得到的。你只用为你的类写一次,但你的客户却会使用很多次。当你设计一个类时,多添加一点小小的工作,就可以在你或者是其他人每次使用时得到回报。 让我们来考虑一个简单的需求:重写System.Object.ToString()方法。你所设计的每一个类型都应该重写ToString()方法,用来为你的类型提供一些最常用的文字说明。考虑这个Customer类以及它的三个成员(fields)(译注:一般情况,类里的fields译为成员,这是面向对象设计时的概念,而在与数据库相关的地方,则是指字段):…
原理:使用DataTable实例的Load方法将原有的DataTable实例中的数据加载到新的DataTable实例中完成合并。 说明:即使原有DataTable实例中数据结构不一样,使用上边方法仍能正常合并,最终的列数是所有DataTable实例列数的并集!
使用#if/#endif 块可以在同样源码上生成不同的编译(结果),大多数debug和release两个版本。但它们决不是我们喜欢用的工具。由于#if/#endif很容易被滥用,使得编写的代码难于理解且更难于调试。程序语言设计者有责任提供更好的工具,用于生成在不同运行环境下的机器代码。C#就提供了条件属性(Conditional attribute)来识别哪些方法可以根据环境设置来判断是否应该被调用。 (译注:属性在C#里有两个单词,一个是property另一个是attribute,它们有不是的意思,但译为中文时一般都是译为了属性。property是指一个对象的性质,也就是Item1里说的属性。而这里的attribute指的是.net为特殊的类,方法或者property附加的属性。可以在MSDN里查找attribute取得更多的帮助,总之要注意:attribute与property的意思是完全不一样的。) 这个方法比条件编译#if/#endif更加清晰明白。编译器可以识别Conditional属性,所以当条件属性被应用时,编译器可以很出色的完成工作。条件属性是在方法上使用的,所以这就使用你必须把不同条件下使用的代码要写到不同的方法里去。当你要为不同的条件生成不同的代码时,请使用条件属性而不是#if/#endif块。…
C#是一个强数据类型语言。好的编程实践意味着当可以避免从一种数据类型强制转化为另种数据类型时,我们应该尽我们的所能来避免它。但在某些时候,运行时类型检测是不可避免的。在C#里,大多数时候你要为调用函数的参数使用System.Object类型,因为Framwork已经为我们定义了函数的原型。你很可能要试图把那些类型进行向下转化为其它类型的接口或者类。你有两个选择:用as运算符,或者,采用旧式的C风格,强制转换。(不管是哪一种,)你还必须对变量进行保护:你可以试着用is进行转换,然而再用as进行转换或者强制转换。 无论何时,正确的选择是用as运算符进行类型转换。因为比起盲目的强制转换它更安全,而且在运行时效率更高。用as和is运算符进行转换时,并不是对所有的用户定义的类型都能完成的。它们只在运行时类型和目标类型匹配的时候,转换才能成功。它们决不会构造一个新的对象来满足(转化)要求。 看一个例子。你写了一段代码,要转换一个任意类型的对象实例到一个MyType类型的实例。你是这样写代码的:…
对于常量,C#里有两个不同的版本:运行时常量和编译时常量。 因为他们有不同的表现行为,所以当你使用不当时,将会损伤程序性能或者出现错误。 两害相权取其轻,当我们不得不选择一个的时候,我们宁可选择一个运行慢一点但正确的那一个,而不是运行快一点但有错误的那个。基于这个理由,你应该选择运行时常量而不是编译时常量(译注:这里隐藏的说明了编译时常量效率更高,但可能会有错误)。 编译时常量更快更直接,但在可维护性上远不及运行时常量。保留编译时常量是为了满足那些对性能要求克刻,且随着程序运行时间的过去,其值永远不发生改变的常量使用的(译注:这说明编译时常量是可以不被C#采用的,但考虑到性能问题,还是做了保留)。…