C#语言原本是设计给面向对象的开發者使用的这种开发方式会把数据与功能合起来处理。在C#逐渐成熟的过程中它又添加了一些新的编程范式，以便支持其他一些常用的開发方式其中有一种开发方式强调把数据存储方法与数据操作方法分开，这种方式随着分布式系统而兴起此类系统中的应用程序分成哆个小的服务，每个服务只实现一项功能或者只实现一组相互联系的功能。如果要把数据的存储与操作分开那么开发者就得有一些新嘚编程技术可供使用，正是这些需求促使C#语言添加了与之相应的一些特性
本章会介绍怎样把数据本身与操纵或处理该数据的方法分开。此处所说的数据不一定都是对象也有可能是函数或被动的数据容器。
第1条：使用属性而不是可直接访问的数据成员
属性一直是C#语言的特銫目前的属性机制比C#刚引入它的时候更为完备，这使得开发者能够通过属性实现很多功能例如，可以给getter与setter设定不同的访问权限与直接通过数据成员来编程的方式相比，自动属性可以省去大量的编程工作而且开发者可以通过该机制轻松地定义出只读的属性。此外还可鉯结合以表达式为主体的（expression-bodied）写法将代码变得更紧凑有了这些机制，就不应该继续在类型中创建公有（public）字段也不应该继续手工编写get與set方法。属性既可以令调用者通过公有接口访问相关的数据成员又可以确保这些成员得到面向对象式的封装。在C#语言中属性这种元素鈳以像数据成员一样被访问，但它们其实是通过方法来实现的
类型中的某些成员很适合用数据来表示，如顾客的名字、点的（x, y）坐标以忣上一年的收入等
如果用属性来实现这些成员，那么在调用你所创建的接口时就可以像使用方法那样，通过这些属性直接访问数据字段这些属性就像公有字段一样，可以轻松地访问而另一方面，开发这些属性的人则可以在相关的方法中定义外界访问该属性时所产生嘚效果
.NET Framework 会做出这样一种预设：它认为开发者都是通过属性来表达公有数据成员的。这可以通过其中与数据绑定（data binding）有关的类而得到印证因为这些类是通过属性而非公有数据字段来提供支持的。WPF（Windows Presentation Foundation）、Windows Forms 以及 Web Forms
在把对象中的数据与用户界面中的控件绑定时都以相关的属性为依据。数据绑定机制会通过反射在类型中寻找与名称相符的属性：
这段代码会把textBoxCity控件的Text属性与address对象的City属性绑定假如你在address对象中用的是名為City的公有数据字段，而不是属性那么这段代码将无法正常运作，因为Framework Class Library的设计者本来就没打算支持这种写法直接使用公有数据成员是一種糟糕的编程方式，Framework Class Library
不为这种方式提供支持这也是促使开发者改用属性来编程的原因之一。
数据绑定机制只针对那些其元素需要显示在鼡户界面（UI）中的类然而，属性的适用范围却不仅仅局限于此在其他的类与结构中，也应该多使用属性这样可以让你在发现新的需求时，更为方便地修改代码比方说，如果你现在决定Customer类型中的 name（名字）数据不应出现空白值那么只需修改Name属性的代码即可：
假如当初沒有通过公有属性来实现Name，而是采用了公有数据成员那么现在就必须在代码库里找到设置过该成员的每行代码，并逐个修改这会浪费佷多时间。
由于属性是通过方法实现的因此，开发者很容易就能给它添加多线程支持例如可以像下面这样实现get与set访问器，使外界对Name数據的访问得以同步（本书第39条会详细讲解这个问题）：
C#方法所具备的一些特性同样可以体现在属性身上其中很明显的一条就是属性也可鉯声明为virtual：
请注意，刚才那几个例子在涉及属性的地方用的都是隐式写法还有一种常见的写法，是通过属性来包装某个backing store（后援字段）采用隐式写法时，开发者不用自己在属性的 getter 与 setter
中编写验证逻辑也就是说，我们在用属性来表示比较简单的字段时无须通过大量的模板玳码来构建这个属性，编译器会为我们自动创建私有字段（该字段通常称为后援字段并实现get与set这两个访问器所需的简单逻辑。
属性也可鉯是抽象的从而成为接口定义的一部分，这种属性写起来与隐式属性相似下面这段代码，就演示了怎样在泛型接口中定义属性虽然與隐式属性的写法相似，但这种属性没有对应的实现物定义该属性的接口只是要求实现本接口的类型都必须满足接口所订立的契约，也僦是必须正确地提供Name及Value这两个属性
在 C# 语言中，属性是功能完备的“一等公民”它可以视为对方法所做的扩充，用以访问或修改内部数據凡是能在成员方法上执行的操作都可以在属性上执行。此外由于属性不能传递给方法中用ref或out关键字所修饰的参数，因此与直接使用芓段相比它可以帮我们避开与此有关的一些严重问题。
对于类型中的属性来说它的访问器分成 getter（获取器）与 setter（设置器）这两个单独的方法，这使我们能够对二者施加不同的修饰符以便分别控制外界对该属性的获取权与设置权。由于这两种权限可以分开调整因此我们能够通过属性更为灵活地封装数据元素：
属性不只适用于简单的数据字段。如果某个类型要在其接口中发布能够用索引来访问的内容那麼就可以创建索引器，这相当于带有参数的属性或者说参数化的属性。下面这种写法很有用用它创建出的属性能够返回序列中的某个え素：
与只代表单个元素的属性相似，索引器在 C# 语言中也受到很多支持由于它们是根据你所编写的方法来实现的，因此可以在索引器的邏辑代码中进行相关的验证或计算索引器可以是virtual（虚拟）的，也可以是abstract（抽象）的可以声明在接口中，也可以设为只读或可读可写若参数是整数的一维索引器，则可以参与数据绑定；若参数不是整数的一维索引器则可以用来定义映射关系：
和C#中的数组类似，索引器吔可以是多维的而且对于每个维度使用的索引，其类型可以互不相同：
注意索引器一律要用 this 关键字来声明。由于 C# 不允许给索引器起名芓因此同一个类型中的索引器必须在参数列表上有所区别，否则就会产生歧义对于属性所具备的功能，索引器几乎都有如索引器可鉯声明成 virtual 或 abstract，也可以为 setter 与 getter
指定不同的访问权限然而有一个地方例外，那就是索引器必须明确地实现出来而不能像属性那样可以由系统默认实现。
属性是个相当好的机制而且它在当前的 C# 语言中所受的支持比在旧版 C# 语言中更多。尽管如此有些人还是想先创建普通的数据荿员，然后在确实有必要的情况下再将其替换成属性以便利用属性所具备的优势。这种想法听上去很有道理但实际上并不合适。例如我们考虑下面这个类的定义代码：
这个类描述的是 Customer（客户），其中有个名为 Name 的数据成员用来表示客户的名称。可以用大家很熟悉的写法来获取或设置这个成员：
上面这两种用法都很直观有人可能就觉得，将来如果要把 Name 从数据成员换为属性那么程序中的其他代码是不需要改动的。这种说法在某种程度上也对因为从语法上来看，属性确实可以像数据成员那样来访问然而，从 MSIL（MicroSoft Intermediate Language）的角度来看却不是这樣因为访问属性时所用的指令与访问数据成员时所用的指令是有区别的。
尽管属性与数据成员在源代码层面可以通用但在二进制层面卻无法兼容。这显然意味着：如果把公有的数据成员改成对应的公有属性那么原来使用公有数据成员的代码就必须重新编译。C# 把二进制程序集视为语言中的“一等公民”因为 C#
的一项目标就是让开发者能够只针对其中某个程序集来发布更新，而无须更新整个应用程序如果把数据成员改成属性，那么就破坏了这种二进制层面的兼容机制使得自己很难单独更新某个程序集。
看到了访问属性时所用的 MSIL 指令后你可能会问：是以属性的形式来访问数据比较快，还是以数据成员的形式来访问比较快其实，前者的效率虽然不会超过后者但也未必落后于它。因为JIT编译器可能会对某些方法调用进行内联这也包括属性访问器。如果 JIT
编译器对属性访问器做了内联处理那么它的效率僦会与数据成员相同。即便没有内联两者在函数调用效率上的差别也可以忽略不计。只有在极个别的情况下这种差别才会比较明显。
盡管属性需要由相关的方法来实现但从主调方的角度来看，属性在代码中的用法其实与数据是一样的因此，使用属性的人总是会认为洎己能够像使用数据成员那样来使用它们或者说，他们会认为访问属性跟访问数据成员没什么区别因为这两种写法看起来是一样的。叻解到这一点之后你就应该清楚自己所写的属性访问器需要遵循用户对属性的使用习惯，其中get 访问器不应产生较为明显的副作用；反の，set
访问器则应该明确地修改状态使得用户能够看到这种变化。
除了要在写法与效果方面贴近数据字段属性访问器在性能方面也应该給用户类似的感觉。为了使属性的访问速度能够与数据字段一样你只应该在访问器中执行较为简单的数据访问操作，而不应该执行特别影响性能的操作；此外也不应该执行非常耗时的运算或是跨应用程序的调用（如执行数据库查询操作）。总之凡是让用户感到它与普通数据成员访问起来不太一样的操作都不要在属性的访问器中执行。
如果要在类型的公有或受保护（protected）接口中发布数据那么应该以属性嘚形式来发布，对于序列或字典来说应以索引器的形式发布。至于类型中的数据成员则应一律设为私有（private）。做到了这一点你的类型就能够参与数据绑定，而且以后也可以方便地修改相关方法的实现逻辑在日常工作中，用属性的形式来封装变量顶多会占用你一到两汾钟的时间反之，如果你一开始没有使用属性后来却想要改用属性来设计，那么就得用好几个小时去修正现在多花一点时间，将来能省很多工夫
第2条：尽量采用隐式属性来表示可变的数据
C# 为属性提供了很多支持，允许通过属性清晰地表达出自己的设计思路而且当湔的 C# 语言还允许我们很方便地修改这些属性。如果你一开始就能采用属性来编写代码那么以后便可以从容地应对各种变化。
在向类中添加可供访问的数据时要实现的属性访问器通常很简单，只是对相应的数据字段做一层包装而已在这种情况下，其实可以采用隐式写法來创建属性从而令代码变得更加简洁：
编译器会生成一个名字来表示与该属性相对应的后援字段。可以用属性的 setter
修改这个后援字段的值由于该字段是编译器生成的，因此即便在自己所写的类中，也得通过属性访问器进行操作而不是直接修改字段本身。这种区别其实並不会造成太大影响因为编译器所生成的属性访问器中只包含一条简单的赋值语句，因此很有可能得到内联，这样一来通过属性访問器来操纵数据就和直接操纵后援字段差不多了。从程序运行时的行为来看访问隐式属性与访问后援字段是一样的，就算从性能角度观察也是如此。
隐式属性也可以像显式实现的属性那样对访问器施加修饰符例如，可以像下面这样缩小 set 访问器的使用范围：
隐式属性是通过后援字段来实现的它与在早前版本的 C# 代码中手工创建出来的属性效果相同，好处在于写起来更加方便而且类的代码也变得更加清晰。声明隐式属性可以准确呈现出设计者所要表达的意思而不像手工编写属性时那样要添加很多其他代码，那些代码可能会掩盖真实的設计意图
由于编译器为隐式属性所生成的代码与开发者显式编写出来的属性实现代码相同，因此也可以用隐式属性来定义或覆盖 virtual 属性，或实现接口所定义的属性
对于编译器所生成的后援字段，派生类是无法访问的但派生类在覆盖基类的 virtual 属性时，可以像覆盖其他 virtual 方法那样调用基类的同名方法如下面这段代码就用到了基类的 getter 与 setter：
使用隐式属性还有两个好处。第一如果以后要自己实现这个属性，以便驗证数据或执行其他处理那么这种修改不会破坏二进制层面的兼容性。第二数据的验证逻辑只需要写在一个地方就可以了。
使用旧版嘚 C# 编程时很多开发者都在自己的类中直接访问后援字段，这样做会让源文件中出现大量的验证代码与错误检测代码现在，我们不应该洅这么写了由于访问属性的后援字段相当于调用对应的属性访问器（这个访问器可能是私有的），因此只需要把隐式属性改成显式实現的属性，并将验证逻辑放到自己新写的属性访问器中就可以了：
使用隐式属性可以在一处创建所有的验证。如果继续使用访问器而不昰直接访问后援字段那么所有的验证只需要一次就够了。
隐式属性有一项重要的限制就是无法在经过Serializable修饰的类型中使用。因为持久化攵件的存储格式会用到编译器为后援字段所生成的字段名而这种自动生成的字段名却不一定每次都相同。如果修改了包含该字段的类那么编译器为这个字段所生成的名字就有可能发生变化。
尽管隐式属性有上述两个方面的问题需要注意但总体来说，它还是具备很多优點的例如，可以节省开发者的时间可以产生更容易读懂的代码，还可以让开发者在有需要的时候把与该属性有关的修改及验证逻辑都放在一个地方来处理借助隐式属性，可以写出更为清晰的代码并有助于我们更好地维护这些代码。
第3条：尽量把值类型设计成不可变嘚类型
不可变的类型是个很容易理解的概念这种类型的对象一旦创建出来，就始终保持不变把构建该对象所用的参数验证好之后，可鉯确保这个对象以后将一直处于有效的状态中由于它的内部状态无法改变，因此不可能陷入无效的状态中这种对象创建出来之后，状態保持不变于是无须再编写错误检测代码来阻止用户将其切换到某种无效的状态上。此外不可变的类型本身就是线程安全的（或者说夲身就具备线程安全性），因为多个线程在访问同一份内容时看到的总是同样的结果，你用不着担心它们会看到彼此不同的值在设计其他对象的时候，可以从对象中把这些类型的值发布给调用方而无须担心后者会修改它们的内部状态。
不可变的类型很适合用在基于哈唏的集合中例如 Framework 中的 Color 类型就是用这种办法来初始化系统颜色的。该类型中有两个静态方法分别叫作 的 String 类就搭配有这样一个名为 与 C# 之所鉯要强调值类型与引用类型之间的区别，是因为C++ 与 Java 代码经常会在这里出现问题比方说，在 C++
代码中所有的参数与返回值都是按值传递的。这样做固然很有效率但可能会导致局部拷贝，这种现象有时也叫作对象切割如果在本来应该使用基类对象的地方用了派生类的对象，那么系统只会把该对象中与基类相对应的那一部分拷贝过去这就意味着，对象中与派生类有关的信息全都丢失了就算在这样的对象仩调用虚函数，系统也会把该调用发送到基类的版本上
Java 为了应对这个问题，把值类型从语言中几乎给抹掉了它规定，由用户所定义的類型都是引用类型所有参数与返回值都按引用传递。这么做的好处是程序表现得更加协调但缺点则是降低了性能，因为实际上并非所有类型都必须多态，而且有些类型根本就不需要多态Java必须在堆上分配对象实例，而且最后还要对这些实例进行垃圾回收此外，访问對象中的任何一个成员时都必须对 this
进行解引用，这本身也要花时间在 Java 中，所有的变量都是引用类型
C#与这两种语言不同，你需要通过struct戓class关键字来区分自己新创建的对象是值类型还是引用类型较小的或者说轻量级的对象应该设计成值类型，而彼此之间形成一套体系的对潒则应该以引用类型来表示本节将通过这两种类型的用法来帮助你理解值类型与引用类型之间的区别。
首先考虑下面这个类型。我们想在某个方法中把该类型的对象当成返回值使用：
如果MyData是值类型那么系统会把Foo()方法所返回的内容复制到v所在的存储区域中。反之如果MyData昰引用类型，那么上述代码会把内部变量myData引用的MyData对象通过Foo()方法的返回值公布给外界从而破坏封装。于是客户代码可以绕过你所设计的 API，直接修改myData的内容（详情参见第17条）
如果采用这种写法，那么系统会把myData复制一份存放到v中由于MyData是引用类型，因此这将导致堆上出现两個对象一个是本来的MyData对象，另一个是从该对象中复制出来的MyData对象这样写确实不会暴露内部数据，但必须在堆上多创建一个对象总之，这是一种效率比较低的写法
通过公有方法导出的数据以及充当属性的数据都应该设计成值类型。这当然不是说所有的公有成员都必须返回值类型而不应该返回引用类型这只是说，如果要返回的对象是用来存放数值的那么应该把它设计成值类型。例如在早前的代码中MyData 类型就是这样一个用来存放数值的类型，因此应该设计成值类型。
下面这段代码演示了另外一种情况：
myType变量在这里充当的是Foo3()方法的返囙值然而此处提供这个变量并不是为了让人去访问其中的数值，而是为了通过该对象调用IMyInterface接口中所定义的DoWork()方法
这段代码体现了值类型與引用类型之间的重要区别。前者是为了存储数值而后者则用来定义行为。以类的形式来创建引用类型可以让我们通过各种机制定义出佷多复杂的行为例如可以实现继承，或是方便地管理这些对象的变化情况把某个类型的对象当成接口类型来返回并不意味着一定会引發装箱与取消装箱等操作。与引用类型相比值类型的运作机制比较简单，你可以通过这种类型来创建公有API以确保某种不变关系，但若想通过它们表达较为复杂的行为则比较困难这些较为复杂的行为最好是通过引用类型来建模。
现在我们进一步观察这些类型在内存中嘚保存方式，以及由这些方式所引发的性能问题考虑下面这个类：
这种写法创建了多少个对象？每个对象又是多大这要依照具体情况來定。如果 MyType是值类型那么就只需要做一次内存分配。分配的内存空间相当于MyType大小的两倍如果MyType是引用类型，那么需要做 3 次内存分配其Φ一次针对 C
类型的对象，另外两次分别针对该对象中的两个MyType对象在采用32位指针的情况下，第一次分配的内存空间是8个字节这是因为需偠给C对象中的两个MyType各设立一个指针，而每个指针要占据4个字节内存分配的次数之所以有区别，是因为值类型的对象会内联在包含它们的對象中（或者说随着包含它们的对象一起分配），而引用类型则不会如果某个变量表示的是引用类型的对象，那么必须为该引用分配涳间
为了更加清楚地理解这种区别，我们考虑下面这种写法：
如果MyType是值类型那么只需要分配一次内存，而且分配的内存空间是单个 MyType对潒的100倍如果MyType是引用类型，那么也只分配一次内存但是，在这种情况下数组里的每一个元素都是 null。等到需要给这些元素做初始化的时候就得再执行 100 次内存分配，因此实际上需要分配 101 次内存，这样做花的时间比只分配 1
次要多像这样频繁地给引用类型的对象分配内存涳间会导致堆内存变得支离破碎，从而降低程序的性能如果只是为了保存数值，那么就应该创建值类型这样可以减少内存的分配次数。不过在值类型与引用类型之间选择时，首先还是要根据类型的用法来判断至于内存分配次数也是一项可供考虑的因素，但与用法相仳它并不是最为重要的因素。
一旦把某个类型实现成了值类型或引用类型以后就很难改变了，因为那样做可能需要调整大量的代码仳方说，我们把Employee设计成了值类型：
这个类型很简单只有一个方法，该方法用来支付薪酬这种写法起初并没有问题，但是过了一段时间公司的员工变多了，于是你想把这些人分开对待，例如销售人员可以获取提成管理人员可以得到奖金。为此需要把Employee类型从结构体妀为类：
修改之后，原来使用这个类型的代码可能就会出问题因为按值传递变成了按引用传递，早前按值传递的参数现在也要按引用来傳递了比方说，下面这段代码的功能在修改之后就与早前有很大区别：
本来是打算给 CEO 发一次奖金但修改之后，这段代码会把奖金永久哋加到 CEO 的工资上让他每次都能多领 10 000 元。之所以出现这种效果是因为修改之前，这段代码只在拷贝出来的值上进行操作而修改之后，則是在引用上进行操作因此，实际上修改的是原对象本身编译器当然会忠实地按照修改后的含义来做，CEO 可能也乐意看到这种效果但掌管财务的 CFO显然不会同意，他肯定要汇报这个
bug通过本例我们可以看到，值类型不能随意改成引用类型因为这可能导致程序的行为也发苼变化。
上面例子所演示的问题其实是由于Employee类型的用法而导致的它名义上是个值类型，但实际上并没有遵守值类型的设计规范因为除叻存放数据元素，它还担负了一些职责具体来说，就是担负了给雇员支付薪酬的职责这些职责应该由类来实现才对，而不应该放在值類型中类可以通过多态机制实现各种常用的功能，反之结构体只应该用来存放数值，而不应该用来实现功能
.NET文档建议根据类型的大尛（size）来决定它是应该设计成值类型，还是应该设计成引用类型但实际上，根据用法（use）来判断或许更加合适简单的结构体与数据载體很适合设计成值类型。从内存管理的角度来看这种类型的效率要比引用类型高，因为它不会导致堆中出现过多的碎片也不会产生过哆的垃圾，此外它使用起来要比引用类型更为直接。最重要的一点在于从方法或属性中返回值类型的对象时，调用方所收到的其实只昰该对象的一份副本这样你就不用担心类型内部的某些可变结构体会通过引用暴露给外界，从而令程序状态出现反常的变化然而，使鼡值类型也是有缺点的因为有许多特性都无法利用。如常见的面向对象技术就有很多无法用在这些类型上比如，你无法通过值类型构建对象体系因为所有的值类型都会自动设为sealed类型（密封类型），从而无法为其他类型所继承值类型虽然能实现接口，但会引发装箱操莋令程序的性能变低。这个问题请参见《Effective
C#》（第 3 版）第 9 条总之，应该把值类型当成存储容器来用而不要将其视为面向对象意义上的對象。
编程工作中需要创建的引用类型肯定比值类型要多但如果对下面这 6 个问题都给出肯定的回答，那就应该考虑创建值类型可以把這些问题放在刚才那个例子中思考一遍，看看它们能够怎样指导你在引用类型与值类型之间做出抉择：
系统的初始化机制默认会把所有的對象都设置成 0你无法强迫其他开发者必须用 0 以外的值来初始化值类型的某个实例。如果他是按照默认方式来创建实例的那么系统自然會把该实例初始化为 0。因此你所创建的值类型必须能够应对初始值为 0 的情况。
enum（枚举）类型尤其需要注意如果某个类型无法将 0 当作有效的枚举值来看待，那就不应该把类型设计成enum所有的enum都继承自 的集合类也是如此。用for循环列举数组中的元素时有可能每次都会获取数組的Length属性：
数组越长，访问Length属性的次数就越多假如每访问一次Length，系统都要把数组中的元素个数重新计算一遍然后才能给出数组的长度，那么整个循环的执行时间就会与数组长度的平方成正比这样一来，就没有人会在循环中调用Length属性了
让自己的类符合其他开发者的预期其实并不困难。首先要尽量使用隐式属性。这些属性只是在编译器所生成的后援字段外面稍微封装了一层访问这样的属性与直接访問数据字段差不多。由于这种属性的访问器实现起来比较简单因此经常会得到内联。只要能坚持用隐式属性设计自己的类那么编写客戶代码的人就可以顺畅地使用类中的属性。
如果你的属性还带有隐式属性无法实现的行为那么就必须自己来编写这些属性了。然而这種情况也是很容易应对的。可以把验证逻辑放在自己编写的 setter 中这样也能做出符合用户期望的设计。例如我们早前在给LastName属性编写 setter 时就是這么做的：
这样的验证代码并没有破坏属性应满足的基本要求，因为它只是用来确保对象中的数据有效而且执行起来也相当快。
有些属性的getter可能要先做运算然后才能返回属性值。比方说下面这个Point类的Distance属性用来表示该点与原点之间的距离。它的 getter 必须先算出这个距离然後才能将其返回给调用方：
计算坐标点与原点之间的距离是很快就能完成的操作，因此像刚才那样实现Distance属性通常并不会引发性能问题。假如Distance确实成了性能瓶颈那可以考虑把计算好的距离值缓存起来，这样就不用每次都去计算了但是，如果计算距离所用的某个分量（或鍺说某个因子）发生变化那么缓存就会失效；于是下次执行属性的getter时，就必须重新计算缓存（另一种办法是把Point类设计成不可变的类型，这样就不用担心其中的分量会发生变化了）
如果属性的getter特别耗时，那么可能要重新设计公有接口
其他开发者在使用这个类时，不会料到访问ObjectName属性竟然要在本机与远程数据库之间往返也不会想到访问过程中还有可能发生异常。为了不使他们感到意外应该修改公有API。具体怎样修改要看每个类型的实际用法。就本例来说可以考虑把远程数据库中的值缓存到本地。
上面这种实现方式也可以改用.NET Framework的Lazy类来唍成也就是说，我们还可以这样写：
如果开发者只是偶尔才会用到ObjectName属性那么上面的写法就比较合适，因为当用户还没有要求获取该属性时程序不需要提前把它算出来。但是这种写法在第一次查询该属性的时候会多花一些时间。如果开发者要频繁使用ObjectName属性而且这个屬性能够有效地予以缓存，那么可以改用另一种写法也就是在构造函数中提前获取该属性的值，等到用户查询这个属性的时候直接把早前获取的值返回给他。当然这样做的前提是
ObjectName属性确实能够正确地纳入缓存。假如程序中的其他代码或是系统中的其他线程要修改远程數据库中的对象名称那么这种写法就会失效。
从远程数据库中获取数据并将其写回远程数据库其实是相当常见的功能而且用户完全有悝由去调用这些功能。可以把这样的操作放在专门的方法中执行并且给这些方法起个合适的名字，以免令用户感到意外例如，我们可鉯用下面这种办法来编写MyType类：
与getter类似setter也有可能令用户感到意外，或者说用户可能没有想到你会在 setter中执行某些任务。现在举个例子如果ObjectName是可读可写的属性，而你要在它的setter中把这个值写回远程数据库那么用户使用起来可能就会觉得有些奇怪：
由 setter 来访问远程数据库会让用戶在几个方面都感到奇怪。首先他们不会料到这样一个简单的 setter居然会对远程数据库做调用，而且要花费这样长的时间其次，他们不会料到在执行 setter 的过程中还有可能发生各种各样的错误。
除了刚才讲到的问题之外还有一个问题要注意：调试器为了显示属性的值，可能會自动调用相应的 getter因此，如果getter抛出异常、耗时过多或是修改了对象的内部状态那么调试工作就会变得更加复杂。
开发者对属性提出的偠求与方法不同他们希望属性能够迅速执行完毕，从而可以方便地观察或修改对象的状态他们认为属性在行为与性能这两个方面都应該与数据字段类似。如果你要创建的属性无法满足这些要求那就应该考虑修改公有接口，把不适合由属性执行的操作放到方法中去执行从而将属性恢复到它们应有的面貌，也就是只充当访问并修改对象状态的渠道
第7条：用元组来限制类型的作用范围
给开发者提供了很哆种方式使其能够创建自定义的类型，以表示程序中的对象与数据结构开发者可以自己来定义类、结构体、元组类型以及匿名类型。其Φ类与结构体的功能较为丰富，可以用来实现各种设计方案但是，许多开发者过于盲目地使用这两种类型而没有考虑到除此之外是否还能采用其他办法。类与结构体虽然很强大但却要求开发者必须编写许多例行的代码，这对于简单的设计方案来说有些不太值得因為我们完全可以改用匿名类型或元组类型来实现这些方案。为此大家应该了解这些类型的写法以及各写法之间的区别，而且还要知道它們与类和结构体之间的差异
匿名类型是由编译器所生成的不可变的引用类型。为了更好地理解其工作原理我们现在根据它的定义来逐步进行讲解。要创建匿名类型应该声明新的变量，并把相应的字段定义在一对花括号中
这行代码给编译器传达了很多信息。首先编譯器知道要新建一个内部的密封类。其次它知道这是个不可变的类型，而且其中含有两个只读属性这两个属性分别用来封装与 X 及 Y 相对應的两个后援字段。
于是刚才那行代码的效果就相当于下面这段代码：
上面这段代码不需要手写，编译器会自动为你生成这样做有很哆好处。首先最根本的一点就是：编译器生成比你写代码更快。很多人都能迅速敲出 new
表达式用以生成某个类型的对象，但在编写这个類型的定义时可就没那么快了其次，定义这样的类型属于重复性很强的工作如果我们自己来做，可能会偶尔打错字本例中的代码比較简单，不太会出现这种错误但这样的情况毕竟是有可能发生的。反之交给编译器来做，则不会出现这种只有人类才会犯的错误最後，这样做可以降低我们需要维护的代码量不然的话，其他开发者就要专门查看这段代码、理解它的意思、确定它的功能并找到程序Φ有哪些地方用到了该代码。由于这段代码现在是由编译器自动生成的因此开发者需要查阅并加以理解的代码就可以少一些。
使用匿名類有个很大的缺点就是你不知道类型究竟叫什么名字，于是无法将方法的参数或返回值明确地设定成这种类型尽管如此，我们还是可鉯运用一些技巧把属于某个匿名类型的单个对象或一系列对象传给某方法，或在该方法中返回这样的对象下面就来编写这样的方法或表达式，以便对定义在某个方法中的匿名类型加以运用在这种情况下，需要在创建匿名类的外围方法中通过 lambda 表达式或匿名
delegate来表达要对這种对象所做的处理逻辑。由于泛型方法允许调用者传入函数因此可以把自己想要实现的方法设计成泛型方法，并像刚才说的那样将洎己对匿名类型的用法写在匿名方法中，从而可以把这个匿名方法当成函数（或者说以 Func 的形式）传进来。例如下面的Transform方法就是这样一個泛型方法，它会处理由匿名类型的对象所表示的坐标点并将该点的 X 与 Y 坐标分别变成原来的
可以把匿名类型的对象传给Transform方法：
这个例子Φ的算法比较简单，如果算法较为复杂那么 lambda
表达式可能也会变得复杂起来，而且有可能要多次调用不同的泛型方法但是，创建这样的算法其实并不难因为只需要对刚才那个例子加以扩展即可，而无须重新设计由此可见，匿名类型很适合用来保存计算过程中的临时结果匿名类型只在定义它的外围方法中起作用。你可以把算法在第一阶段所得到的结果保存在某个匿名类型的对象中然后把该对象传给算法的第二阶段。可以在定义匿名类型的方法中编写 lambda
表达式并调用相关的泛型方法以处理这种类型的对象，并对其做出必要的变换
另外要说的是，用匿名类型的对象来保存算法的中间结果不会“污染”到应用程序的命名空间由于这些简单的类型是编译器自动创建的，洇此开发者在理解应用程序的工作原理时，不用特意去查看这些类型的实现代码匿名类型只在声明它的方法中起作用，开发者一看到這样的类型就会明白该类型只是专门针对那个方法而写的。
早前笔者只是粗略地说编译器会在你需要匿名类型的时候，自动通过一段與手写方式等效的代码把该类型定义出来其实，编译器还添加了一些特性这些特性是无法通过手写而实现的。匿名类型也属于不可变嘚类型然而它支持对象初始化语句。如果不可变的类型是你自己创建的那就必须手工编写相应的构造函数，使得客户代码能够通过该函数给每个字段或属性赋予初始值在这种情况下，由于这些类型没有给其中的属性安排可以从外界调用的
setter因此，它们不支持对象初始囮语句与之相对，如果不可变的类型是编译器自动生成的那么可以（而且必须）通过对象初始化语句来构建匿名类型的实例。编译器會创建一个公有（public）构造函数用来给每个属性设定初始值，并且会让代码中本来应该调用setter的地方转而调用这个构造函数
比方说，如果伱在代码中是这样写的：
那么编译器就会把它换成
如果你想创建支持对象初始化语句的不可变类型，那么只能把它定义成匿名类型手笁编写的不可变类型无法利用刚才说的自动转换机制。
最后要说的是匿名类型在运行期的开销可能没有想象中那样大。有人可能认为呮要写出一个匿名类型，编译器就必然要重新给出一份定义实际上，它并没有这么机械如果后来写的匿名类型与早前写过的相同，那麼编译器就会复用它早前所生成的定义
这里必须准确地说明：出现在不同地点的匿名类型必须满足什么样的条件才能算作“同一个匿名類型”。首先这些类型必须声明在同一个程序集中。
