域
域(Field)又称成员变量(Member Variable),是C#中类不可缺少的一部分。域的类型可以是C#中任何数据类型。但对于除去string类型的其他引用类型由于在初始化时涉及到一些类的构造器的操作,我们这里将不提及,我们把这一部分内容作为“类的嵌套”放在“接口,继承,多态与类”一讲内来阐述。
域分为实例域和静态域。实例域属于具体的对象,为特定的对象所专有。静态域属于类,为所有对象所共用。C#严格规定实例域只能通过对象来获取,静态域只能通过类来获取。例如我们有一个类型为MyClass的对象MyObject,MyClass内的实例域instanceField(存取限制为public)只能这样获取:MyObject. instanceField。而MyClass的静态域staticField(存取限制为public)只能这样获取:MyClass.staticField。注意静态域不能像传统C++那样通过对象获取,也就是说MyObject.staticField的用法是错误的,不能通过编译器编译。
域的存取限制集中体现了面向对象编程的封装原则,根据其保护级C#中类的域有五种不同的存取限制:
public可以被任意存取;
protected只可以被本类和其继承子类存取;
internal只可以被本组合体(Assembly)内所有的类存取,组合体是C#语言中类被组合后的逻辑单位和物理单位,其编译后的文件扩展名往往是“.DLL”或“.EXE”。
protected internal唯一的一种组合限制修饰符,它只可以被本组合体内所有的类和这些类的继承子类所存取。
private只可以被本类所存取。
可以看出,C#只是用internal扩展了C++原来的friend修饰符。在有必要使两个类的某些域互相可见时,我们将这些类的域声明为internal,然后将它们放在一个组合体内编译即可。如果需要对它们的继承子类也可见的话,声明为protected internal即可。实际上这也是组合体的本来意思--将逻辑相关的类组合封装在一起。
C#引入了readonly修饰符来表示只读域,const来表示不变常量。顾名思义对只读域不能进行写操作,不变常量不能被修改,这两者到底有什么区别呢?只读域只能在初始化--声明初始化或构造器初始化--的过程中赋值,其他地方不能进行对只读域的赋值操作,否则编译器会报错。只读域可以是实例域也可以是静态域。只读域的类型可以是C#语言的任何类型。但const修饰的常量必须在声明的同时赋值,而且要求编译器能够在编译时期计算出这个确定的值。const修饰的常量为静态变量,不能够为对象所获取。const修饰的值的类型也有限制,它只能为下列类型之一(或能够转换为下列类型的):sbyte, byte, short, ushort, int, uint, long, ulong, char, float, double, decimal, bool, string, enum类型, 或引用类型。值得注意的是这里的引用类型,由于除去string类型外,所有的类型出去null值以外在编译时期都不能由编译器计算出他们的确切的值,所以我们能够声明为const的引用类型只能为string或值为null的其他引用类型。显然当我们声明一个null的常量时,我们已经失去了声明的意义--这也可以说是C#设计的尴尬之处!
转贴:(一部分)深度探索C#语言的面向对象机制
时间: 2024-11-03 04:07:31
转贴:(一部分)深度探索C#语言的面向对象机制的相关文章
深度探索C++对象模型(4)
雷神跌跌撞撞的读完了<深度探索C++对象模型>的第一章,虽然还是有些疑惑,但是已经感到收获很大.按照朋友的说法,第一章是一个概括的介绍,具体的细节会在以后的章节阐述,如果没有通读本书,第一章还是比较不容易理解的.雷神听过之后信心倍增,也不在有初看此书时的"世界末日"的感觉了(在第2篇雷神感到学了近一年的C++,居然水平如此之差),并且通过自己的努力,还是摸到了些门道,所以让我们继续快乐的出发,踏上深度探索C++对象模型的旅程.记住我们在第一篇的小文<坚持不懈,直到成功
《深度探索C++对象模型》读书笔记 最后一记
第6章主要讲述了执行期语意学,主要内容是关于数组的在构建和析构是如何进行的. 第7章主要讲述了有关Template的相关内容. 这两章内容散见于<Effective C++>.<More Effective C++>.<C++Primer><C++Templates中 文版>等书籍,如果感兴趣请阅读对应的书籍. 本读书笔记主要想谈一下对语意的理解. 本人认为C++程序设计可以简单分为三个层次:语法层.语言语意层(就像<深度探索C++对象模型>所讲
《Android深度探索(卷1):HAL与驱动开发》——1.1节Android系统架构
1.1 Android系统架构 Android深度探索(卷1):HAL与驱动开发 Android是一个非常优秀的嵌入式操作系统.经过几年的发展和演进,Android已经形成了非常完善的系统架构,如图1-1所示. 从图1-1可以看出,Android的系统架构分为4层.这4层所包含的内容如下. 第1层:Linux内核 由于Android是基于Linux内核的,因此,Android和其他Linux系统(如Ubuntu Linux.Fedora Linux等)的核心部分差异非常小.这一层主要包括Linu
《Android深度探索(卷1):HAL与驱动开发》——6.4节使用多种方式测试Linux驱动
6.4 使用多种方式测试Linux驱动 Android深度探索(卷1):HAL与驱动开发 在上一节已经实现了一个简单的Linux驱动程序,该驱动的功能是统计给定字符串中的单词数,并且在最后已经将该Linux驱动的源代码成功编译成动态Linux驱动模块word_count.ko.下一步就是测试该模块.测试的方法很多,最常用的就是直接在Ubuntu Linux中测试.当然,这对于本章实现的Linux驱动是没问题的,但是对于需要直接访问硬件的驱动在Ubuntu Linux上测试就不太方便.在这种情况下
《Android深度探索(卷1):HAL与驱动开发》——6.5节使用Eclipse开发和测试Linux驱动程序
6.5 使用Eclipse开发和测试Linux驱动程序 Android深度探索(卷1):HAL与驱动开发 在前面几节开发的word_count驱动和测试程序大多都需要在Linux终端进行编译(Android应用程序除外)和运行,而且也无法跟踪到Linux内核函数.变量.宏的内部(除非自己到Linux内核源代码中就寻找这些源代码文件),这并不利于深入了解Linux内核技术.在本节将为读者展示如何在Eclipse中开发Linux驱动程序,并且可以像跟踪Java代码一样直接跟踪到Linux内核源代码.
《Android深度探索(卷1):HAL与驱动开发》——1.5节如何学习Linux驱动开发
1.5 如何学习Linux驱动开发 Android深度探索(卷1):HAL与驱动开发 由于Linux的内核版本更新较快(稳定版本1至3月更新一次,升级版本1至2周更新一次),每一次内核的变化就意味着Linux驱动的变化(就算不需要修改驱动代码,至少也得在新的Linux内核版本下重新编译),所以Linux内核的不断变化对从事Linux驱动开发的程序员影响比较大.不过这对于学习Linux驱动开发来说影响相对较小.因为不管是哪个版本的Linux内核,开发Linux驱动的方法和步骤基本相同,只要掌握了一
《Android深度探索(卷1):HAL与驱动开发》——1.7节见识一下什么叫Linux驱动:LED
1.7 见识一下什么叫Linux驱动:LEDAndroid深度探索(卷1):HAL与驱动开发Linux驱动这个家伙到现在为止仍然是只见其声,未见其人,不过在本节会向读者展示一下Linux驱动到底是个什么东西.如果读者看到Linux驱动的代码感到头晕,这属于正常现象.因为如果一看就明白的话,那就没有阅读本书的必要了.本节的目的只为向读者展示Linux驱动程序的结构,以及使读者对Linux驱动有一个大致的印象,读者无须理解其中的细节.当读者阅读完本书时,自然会对这些细节部分了如指掌. 下面给出一个简
《Android深度探索(卷1):HAL与驱动开发》——6.2节编写Linux驱动程序的步骤
6.2 编写Linux驱动程序的步骤Android深度探索(卷1):HAL与驱动开发Linux驱动程序与其他类型的Linux程序一样,也有自己的规则.对于刚开始接触Linux驱动开发的读者可能对如何开发一个Linux驱动程序还不是太了解.为了解决这部分读者的困惑,本节给出了编写一个基本的Linux驱动的一般步骤.读者可以按照这些步骤循序渐进地学习Linux驱动开发. 第1步:建立Linux驱动骨架(装载和卸载Linux驱动) 任何类型的程序都有一个基本的结构,例如,C语言需要有一个入口函数mai
《Android深度探索(卷1):HAL与驱动开发》——6.3节第一个Linux驱动:统计单词个数
6.3 第一个Linux驱动:统计单词个数Android深度探索(卷1):HAL与驱动开发源程序目录:<光盘根目录>/sources/word_count本节将给出我们的第1个Linux驱动的例子.这个驱动程序并没有访问硬件,而是利用设备文件作为介质与应用程序进行交互.应用程序通过向设备文件传递一个由空格分隔的字符串(每一个被空格隔开的子字符串称为一个单词),然后从设备文件读出来的是该字符串包含的单词数.本例的驱动程序使用C语言实现,源代码文件路径如下. 6.3.1 编写Linux驱动程序前的