基本信息·出版社：人民邮电出版社 ·页码：443 页 ·出版日期：2010年01月 ·ISBN：9787115214454 ·条形码：9787115214454 ·版本：第1版 ·装帧：平装 ...
| 商家名称 |
信用等级 |
购买信息 |
订购本书 |
|
|
 |
.NET设计规范:约定、惯用法与模式(第2版·英文版)(附光盘) |
 |
|
|
.NET设计规范:约定、惯用法与模式(第2版·英文版)(附光盘) |
|
基本信息·出版社：人民邮电出版社
·页码：443 页
·出版日期：2010年01月
·ISBN：9787115214454
·条形码：9787115214454
·版本：第1版
·装帧：平装
·开本：16
·正文语种：英语
·丛书名：图灵程序设计丛书·微软技术系列
·外文书名：Framework Design Guidelines:Conventions,Idioms,and Patterns for Reusable .NET Libraries, Second E
内容简介 《.NET设计规范:约定、惯用法与模式(第2版·英文版)》关注直接影响框架可编程能力的设计问题，为框架设计师和广大开发人员设计高质量的软件提供了权威的指南，这一版更新至.NET 3.5。书中内容涉及框架设计的基本原则和规范，常用设计惯用法，为命名空间、类型、成员等框架各部分命名的规范，框架中常用设计模式的规范等。同时，书中添加了来自经验丰富的框架设计师、业界专家及用户给出的评注，为书中的许多规范增色不少。
《.NET设计规范:约定、惯用法与模式(第2版·英文版)》为框架设计师必读之作，也可用作.NET开发人员的技术参考书。
作者简介 克瓦琳娜（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版出版以后.立即成为整个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规范样例以及其他有用的资源和工具。
目录 1 Introduction 1
1.1 Qualities of a Well-Designed Framework 3
1.1.1 Well-Designed Frameworks Are Simple 3
1.1.2 Well-Designed Frameworks Are Expensive to Design 4
1.1.3 Well-Designed Frameworks Are Full of Trade-Offs 5
1.1.4 Well-Designed Frameworks Borrow from the Past 5
1.1.5 Well-Designed Frameworks Are Designed to Evolve 5
1.1.6 Well-Designed Frameworks Are Integrated 6
1.1.7 Well-Designed Frameworks Are Consistent 6
2 Framework Design Fundamentals 9
2.1 Progressive Frameworks 11
2.2 Fundamental Principles of Framework Design 14
2.2.1 The Principle of Scenario-Driven Design 15
2.2.2 The Principle of Low Barrier to Entry 21
2.2.3 The Principle of Self-Documenting Object Models 26
2.2.4 The Principle of Layered Architecture 33
3 Naming Guidelines 37
3.1 Capitalization Conventions 38
3.1.1 Capitalization Rules for Identifiers 38
3.1.2 Capitalizing Acronyms 40
3.1.3 Capitalizing Compound Words and Common Terms 43
3.1.4 Case Sensitivity 45
3.2 General Naming Conventions 46
3.2.1 WordChoice 46
3.2.2 Using Abbreviations and Acronyms 48
3.2.3 Avoiding Language-Specific Names 49
3.2.4 Naming New Versions of Existing APIs 51
3.3 Names of Assemblies and DLLs 54
3.4 Names of Namespaces 56
3.4.1 Namespaces and Type Name Conflicts 58
3.5 Names of Classes. Structs. and Interfaces 60
3.5.1 Names of Generic Type Parameters 64
3.5.2 Names of Common Types 64
3.5.3 Naming Enumerations 66
3.6 Names of Type Members 68
3.6.1 Names of Methods 68
3.6.2 Names of Properties 68
3.6.3 Names of Events 70
3.6.4 Naming Fields 72
3.7 Naming Parameters 73
3.7.1 Naming Operator Overload Parameters 74
3.8 Naming Resources 74
4 Type Design Guidelines 77
4.1 Types and Namespaces 79
4.1.1 Standard Subnamespace Names 83
4.2 Choosing Between Class and Struct 84
4.3 Choosing Between Class and Interface 88
4.4 Abstract Class Design 95
4.5 Static Class Design 97
4.6 Interface Design 98
4.7 Struct Design 101
4.8 EnumDesign 103
4.8.1 Designing Flag Enums 110
4.8.2 Adding Values to Enums 114
4.9 Nested Types 115
4.10 Types and Assembly Metadata 118
5 MemberDesign 121
5.1 General Member Design Guidelines 121
5.1.1 Member Overloading 121
5.1.2 Implementing Interface Members Explicitly 128
5.1.3 Choosing Between Properties and Methods 132
5.2 Property Design 138
5.2.1 Indexed Property Design 140
5.2.2 Property Change Notification Events 142
5.3 Constructor Design 144
5.3.1 Type Constructor Guidelines 151
5.4 Event Design 153
5.4.1 Custom Event Handler Design 159
5.5 Field Design 159
5.6 Extension Methods 162
5.7 Operator Overloads 168
5.7.1 Overloading Operator == 173
5.7.2 Conversion Operators 173
5.8 Parameter Design 175
5.8.1 Choosing Between Enum and Boolean Parameters 177
5.8.2 Validating Arguments 179
5.8.3 Parameter Passing 183
5.8.4 Members with Variable Number of Parameters 186
5.8.5 Pointer Parameters 190
6 Designing for Extensibility 193
6.1 Extensibility Mechanisms 193
6.1.1 Unsealed Classes 194
6.1.2 Protected Members 196
6.1.3 Events and Callbacks 197
6.1.4 Virtual Members 201
6.1.5 Abstractions (Abstract Types and Interfaces) 203
6.2 Base Classes 206
6.3 Sealing 207
7 Exceptions 211
7.1 Exception Throwing 216
7.2 Choosing the Right Type of Exception to Throw 221
7.2.1 Error Message Design 225
7.2.2 Exception Handling 227
7.2.3 Wrapping Exceptions 232
7.3 Using Standard Exception Types 234
7.3.1 Except Con and System Exception 234
7.3.2 Application Exception 234
7.3.3 Invalid Operation Except Con 235
7.3.4 Argument Exception. Argument Null Exception. and Argument Out Of Range Exception 235
7.3.5 Null Reference Exception. IndexOut OfRange Exception. and Access Violation Exception 237
7.3.6 StackOverflowException 237
7.3.7 0utOfMemoryException 238
7.3.8 ComException. SEHException. and ExecutionEngineException 239
7.4 Designing Custom Exceptions 239
7.5 Exceptions and Performance 240
7.5.1 Tester-Doer Pattern 241
7.5.2 Try-Parse Pattern 242
8 Usage Guidelines 245
8.1 Arrays 245
8.2 Attributes 247
8.3 Collections 250
8.3.1 Collection Parameters 252
8.3.2 Collection Properties and Return Values 253
8.3.3 Choosing Between Arrays and Collections 258
8.3.4 Implementing Custom Collections 259
8.4 DateTime and DateTimeOffset 261
8.5 ICloneable 263
8.6 IComparable and IEquatable 264
8.7 IDisposable 266
8.8 Nuiiable 266
8.9 Object 268
8.9.1 Object.EquaLs 268
8.9.2 Object.GetHashCode 270
8.9.3 Object.ToStrlng271
8.10 Serialization 274
8.10.1 Choosing the Right Serialization Technology to Support 275
8.10.2 Supporting Data Contract Serialization 276
8.10.3 Supporting XML Serialization 280
8.10.4 Supporting Runtime Serialization 281
8.11 UrL 283
8.11.1 System. Uri Implementation Guidelines 284
8.12 System.Xml Usage 284
8.13 Equality Operators 286
8.13.1 Equality Operators on Value Types 287
8.13.2 Equality Operators on Reference Types 287
9 Common Design Patterns 289
9.1 Aggregate Components 289
9.1.1 Component-Oriented Design 291
9.1.2 FactoredTypes 294
9.1.3 Aggregate Component Guidelines 295
9.2 The Async Patterns 298
9.2.1 Choosing Between the Async Patterns 298
9.2.2 Classic Async Pattern 300
9.2.3 Classic Async Pattern Basic Implementation Example 304
9.2.4 Event-Based Async Pattern 305
9.2.5 Supporting Out and Ref Parameters 307
9.2.6 Supporting Cancellation 308
9.2.7 Supporting Progress Reporting 309
9.2.8 Supporting Incremental Results 311
9.3 Dependency Properties 312
9.3.1 Dependency Property Design 313
9.3.2 Attached Dependency Property Design 315
9.3.3 Dependency Property Validation 316
9.3.4 Dependency Property Change Notifications 317
9.3.5 Dependency Property Value Coercion 318
9.4 Dispose Pattern 319
9.4.1 Basic Dispose Pattern 322
9.4.2 Finalizable Types 328
9.5 Factories 332
9.6 LINQ Support 337
9.6.1 Overview of LINQ 337
9.6.2 Ways of Implementing LINQ Support 339
9.6.3 Supporting LINQ through IEnumerabLe 339
9.6.4 Supporting LINQ through IOueryabLe 340
9.6.5 Supporting LINQ through the Query Pattern 341
9.7 Optional Feature Pattern 344
9.8 Simulating Covariance 348
9.9 Template Method 354
9.10 Timeouts 356
9.11 XAML Readable Types 358
9.12 And in the End... 361
A C# Coding Style Conventions 363
A.1 General Style Conventions 364
A.1.1 Brace Usage 364
A.1.2 Space Usage 365
A.1.3 Indent Usage 367
A.1.4 Other 367
A.2 Naming Conventions 367
A.3 Comments 368
A.4 File Organization 369
B Using FxCop to Enforce the Framework Design Guidelines 371
B.1 What Is FxCop? 371
B.2 The Evolution of FxCop 372
B.3 How Does It Work? 373
B.4 FxCop Guideline Coverage 374
B.4.1 FxCop Rules for the Naming Guidelines 374
B.4.2 FxCop Rules for the Type Design Guidelines 384
B.4.3 FxCop Rules for Member Design 387
B.4.4 FxCop Rules for Designing for Extensibility 394
B.4.5 FxCop Rules for Exceptions 395
B.4.6 FxCop Rules for Usage Guidelines 397
B.4.7 FxCop Rules for Design Patterns 402
C Sample API Specification 405
Glossary 413
Suggested Reading List 419
Index 423
About the Annotators 437
……
序言 .NET Framework一推出，我就立即对它着了迷。这种技术让CLR（通用语言运行库）及其大量API，以及C#语言的优势立刻彰显无遗。这些技术无不体现了API的通用设计风格和始终贯彻的一系列约定。这就是.NET文化。一旦你了解了这种文化，就容易把有关知识运用到框架设计的其他领域中去。
过去16年里，我一直在从事开源软件工作。由于开源的特点，开发者不仅文化背景不同，连开发时间也会跨越好几年，这时坚守一种风格和编码约定就显得特别重要。虽然我们有维护人员，其日常的工作就是重写或修改提交来的软件，保证代码遵守项目编码标准和风格，但是，如果参与软件项目的所有人一开始就使用项目的约定，当然就更为理想。通过实践和标准所传达出的信息越多，未来新加入的人员就越容易上手。这有利于项目汇聚和融合新老代码。
.NET Framework在成长，其开发者社区也在成长，人们不断确定了新的实践、模式和约定。Brad和Krzysztof挺身而出，成为了这些规则的“监护人”，他们把这些新知识转变为现在这本规范。他们通常会在博客里介绍新的约定，收集社区的反馈，再记录下这些规范。在我看来，任何人若有兴趣用好.NET Framework，则必须要常看他们的博客。
这本书第1版出版以后，立即成为整个：Motto社区传诵的经典，其原因大体有两个。首先，我们可以由此了解各种.NET API实现的原委和方式；其次，我们珍视其为无价的规范，也努力贯彻在自己的程序和库的设计过程中。第2版不仅建立在第1版成功的基础之上，而且还添加了不少新的知识。许多规范还增加了注解，注解者本身就是行业里首屈一指的.NET架构师和伟大的程序员，正是他们帮助确定了这些规范。
最后我要说，这本书远不止是一本规范。它是我们热爱的一部经典，可以帮助我们成为一名杰出的程序员，而这样的程序员在我们行业里现在还为数不多。
文摘 插图：
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.
