.NET设计规范
2010-1
人民邮电出版社
Krzysztof Cwalina,,Brad Abrams
443
无
.NET Framework一推出，我就立即对它着了迷。这种技术让CLR（通用语言运行库）及其大量API，以及C#语言的优势立刻彰显无遗。这些技术无不体现了API的通用设计风格和始终贯彻的一系列约定。这就是.NET文化。一旦你了解了这种文化，就容易把有关知识运用到框架设计的其他领域中去。过去16年里，我一直在从事开源软件工作。由于开源的特点，开发者不仅文化背景不同，连开发时间也会跨越好几年，这时坚守一种风格和编码约定就显得特别重要。虽然我们有维护人员，其日常的工作就是重写或修改提交来的软件，保证代码遵守项目编码标准和风格，但是，如果参与软件项目的所有人一开始就使用项目的约定，当然就更为理想。通过实践和标准所传达出的信息越多，未来新加入的人员就越容易上手。这有利于项目汇聚和融合新老代码。.NET Framework在成长，其开发者社区也在成长，人们不断确定了新的实践、模式和约定。Brad和Krzysztof挺身而出，成为了这些规则的“监护人”，他们把这些新知识转变为现在这本规范。他们通常会在博客里介绍新的约定，收集社区的反馈，再记录下这些规范。在我看来，任何人若有兴趣用好.NET Framework，则必须要常看他们的博客。这本书第1版出版以后，立即成为整个：Motto社区传诵的经典，其原因大体有两个。首先，我们可以由此了解各种.NET API实现的原委和方式；其次，我们珍视其为无价的规范，也努力贯彻在自己的程序和库的设计过程中。第2版不仅建立在第1版成功的基础之上，而且还添加了不少新的知识。许多规范还增加了注解，注解者本身就是行业里首屈一指的.NET架构师和伟大的程序员，正是他们帮助确定了这些规范。最后我要说，这本书远不止是一本规范。它是我们热爱的一部经典，可以帮助我们成为一名杰出的程序员，而这样的程序员在我们行业里现在还为数不多。
本书关注直接影响框架可编程能力的设计问题，为框架设计师和广大开发人员设计高质量的软件提供了权威的指南，这一版更新至.NET 3.5。书中内容涉及框架设计的基本原则和规范，常用设计惯用法，为命名空间、类型、成员等框架各部分命名的规范，框架中常用设计模式的规范等。同时，书中添加了来自经验丰富的框架设计师、业界专家及用户给出的评注，为书中的许多规范增色不少。 本书为框架设计师必读之作，也可用作.NET开发人员的技术参考书。
作者：(美国)克瓦琳娜(Krzysztof Cwalina) (美国)艾布拉姆斯(Brad Abrams)克瓦琳娜（Krzysztof Cwalina），微软公司.NET Franmwork开发组项目经理。他为.NET Framework设计了多个API。还开发了FxCop等框架开发工具。目前，他正致力于在微软内部开发推广设计规范。将其应用到.NET Framework中。同时负责核心.NET Framework API的交付。艾布拉姆斯（Brad Abrams），微软公司CLR开发组和.NET Framework开发组的创始人之一，目前是项目经理主管。他参与制定了CLS、.NET Framework设计规范以及ECMA／ISOCLI标准中程序库标准。著有Programming in the.NET Environment、.NET Framework StandardLibrary Annotated Reference（卷1和卷2）等书。读者可以从他的博客http：//blogs.msdn.com／bradA/中了解他的最新想法。
1 Introduction 1.1 Qualities of a Well-Designed Framework 1.1.1 Well-Designed Frameworks Are Simple 1.1.2 Well-Designed Frameworks Are Expensive to Design 1.1.3 Well-Designed Frameworks Are Full of Trade-Offs 1.1.4 Well-Designed Frameworks Borrow from the Past 1.1.5 Well-Designed Frameworks Are Designed to Evolve 1.1.6 Well-Designed Frameworks Are Integrated 1.1.7 Well-Designed Frameworks Are Consistent 2 Framework Design Fundamentals 2.1 Progressive Frameworks 2.2 Fundamental Principles of Framework Design 2.2.1 The Principle of Scenario-Driven Design 2.2.2 The Principle of Low Barrier to Entry 2.2.3 The Principle of Self-Documenting Object Models 2.2.4 The Principle of Layered Architecture 3 Naming Guidelines 3.1 Capitalization Conventions 3.1.1 Capitalization Rules for Identifiers 3.1.2 Capitalizing Acronyms 3.1.3 Capitalizing Compound Words and Common Terms 3.1.4 Case Sensitivity 3.2 General Naming Conventions 3.2.1 WordChoice 3.2.2 Using Abbreviations and Acronyms 3.2.3 Avoiding Language-Specific Names 3.2.4 Naming New Versions of Existing APIs 3.3 Names of Assemblies and DLLs 3.4 Names of Namespaces 3.4.1 Namespaces and Type Name Conflicts 3.5 Names of Classes, Structs, and Interfaces 3.5.1 Names of Generic Type Parameters 3.5.2 Names of Common Types 3.5.3 Naming Enumerations 3.6 Names of Type Members 3.6.1 Names of Methods 3.6.2 Names of Properties 3.6.3 Names of Events 3.6.4 Naming Fields 3.7 Naming Parameters 3.7.1 Naming Operator Overload Parameters 3.8 Naming Resources 4 Type Design Guidelines 4.1 Types and Namespaces 4.1.1 Standard Subnamespace Names 4.2 Choosing Between Class and Struct 4.3 Choosing Between Class and Interface 4.4 Abstract Class Design 4.5 Static Class Design 4.6 Interface Design 4.7 Struct Design 4.8 EnumDesign 4.8.1 Designing Flag Enums 4.8.2 Adding Values to Enums 4.9 Nested Types 4.10 Types and Assembly Metadata 5 MemberDesign 5.1 General Member Design Guidelines 5.1.1 Member Overloading 5.1.2 Implementing Interface Members Explicitly 5.1.3 Choosing Between Properties and Methods 5.2 Property Design 5.2.1 Indexed Property Design 5.2.2 Property Change Notification Events 5.3 Constructor Design 5.3.1 Type Constructor Guidelines 5.4 Event Design 5.4.1 Custom Event Handler Design 5.5 Field Design 5.6 Extension Methods 5.7 Operator Overloads 5.7.1 Overloading Operator == 5.7.2 Conversion Operators 5.8 Parameter Design 5.8.1 Choosing Between Enum and Boolean Parameters 5.8.2 Validating Arguments 5.8.3 Parameter Passing 5.8.4 Members with Variable Number of Parameters 5.8.5 Pointer Parameters 6 Designing for Extensibility 6.1 Extensibility Mechanisms 6.1.1 Unsealed Classes 6.1.2 Protected Members 6.1.3 Events and Callbacks 6.1.4 Virtual Members 6.1.5 Abstractions (Abstract Types and Interfaces) 6.2 Base Classes 6.3 Sealing 7 Exceptions 7.1 Exception Throwing 7.2 Choosing the Right Type of Exception to Throw 7.2.1 Error Message Design 7.2.2 Exception Handling 7.2.3 Wrapping Exceptions 7.3 Using Standard Exception Types 7.3.1 ExceptCon and SystemExcept~on 7.3.2 AppL ~cat~onExcept~on 7.3.3 InvaL ~dOperat~onExceptCon 7.3.4 ArgumentExcept~on, ArgumentNuL LExcept~on, and ArgumentOutOfRangeExcept~on 7.3.5 NuL LReferenceExcept~on, IndexOutOfRangeExcept~on, and AccessVCoLatConExcept~on 7.3.6 StackOverfLowExcept~on 7.3.7 utOfMemoryExcept~on 7.3.8 ComExcept~on, SEHExceptCon, and Execut~onEng~ne-Exception 7.4 Designing Custom Exceptions 7.5 Exceptions and Performance 7.5.1 Tester-Doer Pattern 7.5.2 Try-Parse Pattern 8 Usage Guidelines 8.1 Arrays 8.2 Attributes 8.3 Collections 8.3.1 Collection Parameters 8.3.2 Collection Properties and Return Values 8.3.3 Choosing Between Arrays and Collections 8.3.4 Implementing Custom Collections 8.4 DateTime and DateTimeOffset 8.5 ICloneable 8.6 IComparable and IEquatable 8.7 IDisposable 8.8 Nuiiable 8.9 Object 8.9.1 Object. EquaLs 8.9.2 Object. GetHashCode 8.9.3 Object. ToStrlng271 8.10 Serialization 8.10.1 Choosing the Right Serialization Technology to Support 8.10.2 Supporting Data Contract Serialization 8.10.3 Supporting XML Serialization 8.10.4 Supporting Runtime Serialization 8.11 UrL 283 8.11.1 System. Urn. Implementation Guidelines 8.12 System.Xml Usage 8.13 Equality Operators 8.13.1 Equality Operators on Value Types 8.13.2 Equality Operators on Reference Types 9 Common Design Patterns 9.1 Aggregate Components 9.1.1 Component-Oriented Design 9.1.2 FactoredTypes 9.1.3 Aggregate Component Guidelines 9.2 The Async Patterns 9.2.1 Choosing Between the Async Patterns 9.2.2 Classic Async Pattern 9.2.3 Classic Async Pattern Basic Implementation Example 9.2.4 Event-Based Async Pattern 9.2.5 Supporting Out and Ref Parameters 9.2.6 Supporting Cancellation 9.2.7 Supporting Progress Reporting 9.2.8 Supporting Incremental Results 9.3 Dependency Properties 9.3.1 Dependency Property Design 9.3.2 Attached Dependency Property Design 9.3.3 Dependency Property Validation 9.3.4 Dependency Property Change Notifications 9.3.5 Dependency Property Value Coercion 9.4 Dispose Pattern 9.4.1 Basic Dispose Pattern 9.4.2 Finalizable Types 9.5 Factories 9.6 LINQ Support 9.6.1 Overview of LINQ 9.6.2 Ways of Implementing LINQ Support 9.6.3 Supporting LINQ through IEnumerabLe 9.6.4 Supporting LINQ through IOueryabLe~T~ 9.6.5 Supporting LINQ through the Query Pattern 9.7 Optional Feature Pattern 9.8 Simulating Covariance 9.9 Template Method 9.10 Timeouts 9.11 XAML Readable Types 9.12 And in the End... A C# Coding Style Conventions A.1 General Style Conventions A.1.1 Brace Usage A.1.2 Space Usage A.1.3 Indent Usage A.1.4 Other 367 A.2 Naming Conventions A.3 Comments A.4 File Organization B Using FxCop to Enforce the Framework Design Guidelines B.1 What Is FxCop? B.2 The Evolution of FxCop B.3 How Does It Work? B.4 FxCop Guideline Coverage B.4.1 FxCop Rules for the Naming Guidelines B.4.2 FxCop Rules for the Type Design Guidelines B.4.3 FxCop Rules for Member Design B.4.4 FxCop Rules for Designing for Extensibility B.4.5 FxCop Rules for Exceptions B.4.6 FxCop Rules for Usage Guidelines B.4.7 FxCop Rules for Design Patterns C Sample API Specification Glossary Suggested Reading List Index
插图：F YOU COULD STAND over the shoulder of every developer who is using your framework to write code and explain how it is supposea tobe used, guidelines would not be necessary. The guidelines presented inthis book give you, as the framework author, a palette o{ tools that allowyou to create a common language between framework authors and thedevelopers who will use the frameworks. For example, exposing an opera-tion as a property instead of exposing it as a method conveys vital infor-mation about how that operation is to be used.In the early days of the PC era, the main tools for developing applica-tions were a programming language compiler, a very small set of standardlibraries, and the raw operating system application programming inter-faces （APIs）-a very basic set of low-level programming tools.Even as developers were building applications using such basic tools,they were discovering an increasing amount of code that was repetitiveand could be abstracted away through higher-level APIs. Operating sys-tem vendors noticed that they could make it cheaper for developers tocreate applications for their systems if they provided them with suchhigher-level APIs. The number of applications that could run on the sys-tem would increase, which would then make the system more appealingto end users who demanded a variety of applications. Also, independenttool and component vendors quickly recognized the business opportuni-ties offered by raising the API abstraction level.
“本书第1版出版以后.立即成为整个Mono社区传诵的经典……这一版弥补了上一版的很多不足。而众多参与规范制定的核心.NET架构师及顶尖程序员所做的评注也极大地丰富了本书的内涵。” ——Miguel de Icaza.GNOME和Mono项目创建者“本书绝对是所有.NET开发人员的必读之作。它总结了.NET本身设计和开发过程中获得的经验和教训。不仅使你对.NET能够知其所以然。还能极大地帮助你更高效地使用.NET类库。” ——Jeffrey Richter，微软技术大师，名著《Windows核心编程》作者
《.NET设计规范:约定、惯用法与模式(第2版·英文版)》：数千名微软精锐开发人员的经验和智慧。最终浓缩在这本设计规范之中。与上一版相比。书中新增了许多评注。解释了相应规范的背景和历史，从中你能聆听到微软技术大师Andem Hejlsberg、Jeffrey Richter和Paul Vick等的声音。读来令人兴趣盎然.欲罢不能。《.NET设计规范:约定、惯用法与模式(第2版·英文版)》虽然是针对.NET平台上的框架设计的。但对其他平台的框架设计同样具有借鉴意义。新版根据.NET Framework 3.0和3.5的新特性做了全面更新，主要关注的是直接影响框架可编程能力的设计问题。遵守这些规范对于使用.NET Framework创建高质量的应用程序至关重要。微软.N ET Framework设计组的智慧结晶洞悉.NET技术内幕.N ET开发者的必备图书《.NET设计规范:约定、惯用法与模式(第2版·英文版)》提供配套光盘。内含Designing.NET Class Librarides等13个演讲视频（时长近13小时）。此外.光盘还包括.NETFramework类和组件设计指南、API规范样例以及其他有用的资源和工具。
无
从换行、缩写、大小写这些编码约定讲到异常、异步、非托管这些设计约定。
还没看，但原版书比较经典，还能锻炼英文
这本书讲的很好，如果再多一点代码示例就更好了
书写的不错，还没来得及看。
如题目，英文的，还没看，还准备买中文
对了解.net的设计规范、提高查找库函数的效率有帮助，对自己设计供他人调用的模块也有指导意义。
内容很棒，印刷一般，像是影印……
用最普通的语言总结了.NET Framework 设计过程中点滴经验，集合了众多大师的精髓。无论是对于.NET Framework 编程，还是对于类似的框架设计都有非常好的借鉴意义！值得推荐！
结果几乎是考着对比原文看完的,什么"内部受保护的列表",把几乎所有大家都知道的英文关键字都翻译成中文,这就已经够难读的了,而且很多句子都部通顺.怪不得这么快就绝版买不到了.
书是好书,建议所有的.NET程序员都读一下
对于框架来说，最关键的品质应该是一致性。一旦用户理解了框架的一部分，那么就应该能立即理解框架的其他部分
框 架设计基本原则
场景驱动设计原则 在设计框架时，必须从一组使用场景以及实现这些场景的样例代码开始
低 门槛原则 框架必须以易于实验的方式来为普通用户提供一个低门槛
不要提供抽象，除非为改抽象开发 出具体实现并用到改抽象的api对其进行过实际的测试
由于一些开发人员只是想完成工作，（通常很简单） 而不是想学习特性域提供的所有功能，因此为他们提供进过简化的高层操作就显得至关重要
It-Just-Works
一 条重要的api设计原则就是，要么完全隐藏复杂性（或几乎完全隐藏），要么根本就不隐藏。最糟糕的就是设计一个看上去简单的api，但当开发人员开始使用 时，却（通常艰难地）发现事实并非如此。
Create-Set-Call使用模式
api 的用户数量与简单场景中new语句的数目成反比
粗读了一遍，感觉收获很大。
侯捷先生曾在他的《深入浅出MFC第二版》中有云“99.99999%的programmer终其一生不会设计一个application framework”，尽管如此，这本书更多地让我看到了从设计者的角度来观察如何更好地设计和使用框架来进行日常的开发活动。
今年年初时，人民邮电出版了该书的第二版影印版，非常期待，我想我会很快重读一次~
书是以 "要...", "不要..." 组织的, 但精华在于, 关于为什么会这样, 以及达成这个规范经历过什么, 做了详尽的介绍, 这点在 MSDN 上是没有的, 或者限于篇幅, 写得很简略
另外有收获的地方是, 读完全书, 对于 C# 的使用规范, 有了个系统的认识, 心里大体有谱了.
关于设计, 很多书在讲, 编码规范, 也司空见惯, 但是针对语言讲常用法的书不多.
而当一位有经验的程序员, 接触一门新的语言时, 最需要的就是这方面的知识, 结果很多时候, 只能凭自己慢慢摸索, 或依靠其他语言上积累的经验, 或者看语言教程中的示例, 或者看开源项目中的用法, 但都容易显得零碎, 不够系统, 总有点踹踹然的感觉.
很高兴, 这本书我认为能够承担起 C# 上的这个职责, 就好比 <<Effective ...>> 在 C++ 上一样.
整本书的大部分内容都在讲.Net Framework中是如何考虑变量命名和一些编码相关的决策，设计的东西太少了，或者说我看此书时是希望该书可以讨论.Net Framework类是如何设计，又如何一起协作，以及实现这些协作做了那些权衡，备选的方案为什么不是最优的东西，这些信息太少了！
程序和画画一样，无非就是各种元素的控制和充填，只是把画画中的线条，点什么的变成了程序中的类，接口，函数，然后在统一构成一幅完整的画卷（程序），如此而已。
首先，本书好就好在，它告诉了你程序中的这些元素在.Net中应该如何使用，如何选择。
当你还在为选择是用接口还是抽象类、使用值类型还是引用类型而困惑的时候，为如何更好的使用异常而迷惑的时候，大可以看看这本书，相信它会给你亮起一个小小的明灯的。
其次，困扰软件开发的一个重要问题，就是没有办法形成一套完整的工业化标准，100个人写出来的代码有100种风格，如果，你不想和其它99个人写出来的代码风格相差太远的话，看看本书也还是有些益处的。
再次，本书的一大特色就是加入了几个.Net开发中绝对的牛人的评论，看着他们精辟的言论，相信你的眼界会开阔不少。他们中偶最偏爱的是Jeffrey，向Jeffrey老大致敬!
最后，这本书真的很薄，在这大砖头流行的年代里，看一本薄书本身也是一种幸福吧！
ps：我才买的第一版，据说第二版就出来了，如果可以的话，还是直接买第二版的好。。。
在书店浏览下这本书后就耗不犹豫的买了下来，在我看来这本书最大的好处并不紧紧是在告诉你
“要...”“不要...”规范，有关于这些规范的内容也可以在MSDN上找到。书中精彩的部分在于Jeffrey Richter等人的注释，你可以明白如：
1）Dispose模式中GC.SuppressFinalize方法放在哪里，此处Jeffrey Richter给出了不同于《 Applied Microsoft .NET Framework programming 》中的方案；
2）使用工厂方法和构造函数来需要的思考的地方；
......
规范的考虑并不在于技术很detail的地方，要想设计一个高效的，合理的，别人易于使用的类库，那么请不要错过这本书！
囧。。。原来你说的是.net。。。
1）Dispose模式中GC.SuppressFinalize方法放在哪里，此处Jeffrey Richter给出了不同于《 Applied Microsoft .NET Framework programming 》中的方案；
2）使用工厂方法和构造函数来需要的思考的地方；
这种。。。 岂不是多入毛。。。
还好图灵