Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries / Edition 1

Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries / Edition 1

Pub. Date:

Other Format

Current price is , Original price is $49.99. You
Select a Purchase Option (Older Edition)
  • purchase options


Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries / Edition 1

A new edition of this title is available, ISBN-10: 0321545613 ISBN-13: 9780321545619

"This book is an absolute must-read for all .NET developers. It gives clear do and don't guidance on how to design class libraries for .NET. It also offers insight into the design and creation of .NET that really helps developers understand the reasons why things are the way they are. This information will aid developers designing their own class libraries and will also allow them to take advantage of the .NET class library more effectively."

—Jeffrey Richter, author/trainer/consultant, Wintellect

"Framework Design Guidelines will help you in two important ways. First, any .NET developer will benefit from a greater understanding of the design principles that govern the .NET Base Class Library. Second, a deeper understanding of these principles will help you to create software that integrates well with the .NET environment. Quite frankly, this book should be on every .NET developer's bookshelf."

—Bill Wagner, founder and consultant, SRT Solutions, author of Effective C#

"Not since Brooks' The Mythical Man Month has the major software maker of its time produced a book so full of relevant advice for the modern software developer. This book has a permanent place on my bookshelf and I consult it frequently."

—George Byrkit, senior software engineer, Genomic Solutions

"This book is a must-read for all architects and software developers thinking about frameworks. The book offers insight into some driving factors behind the design of the .NET Framework. It should be considered mandatory reading for anybody tasked with creating application frameworks."

—Peter Winkler, senior software engineer, Balance Technology Inc.

"Frameworks are valuable but notoriously difficult to construct: Your every decision must be geared towards making them easy to be used correctly and difficult to be used incorrectly. This book takes you through a progression of recommendations that will eliminate many of those downstream 'I wish I'd known that earlier' moments. I wish I'd read it earlier."

—Paul Besly, principal technologist, QA

"Filled with information useful to developers and architects of all levels, this book provides practical guidelines and expert background information to get behind the rules. Framework Design Guidelines takes the already published guidelines to a higher level, and it is needed to write applications that integrate well in the .NET area."

—Cristof Falk, software engineer

Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries teaches developers the best practices for designing system frameworks and reusable libraries for use with the Microsoft .NET Framework and WinFX. This book focuses on the design issues that directly affect the programmability of a framework, specifically its publicly accessible APIs.

This book can improve the work of any .NET developer producing code that other developers will use. An added benefit is a collection of annotations to the guidelines by various members of the Microsoft .NET Framework and WinFX teams, which provide a lively discussion of the motives behind the guidelines, along with examples of good reasons for breaking the guidelines.

Microsoft architects Krzysztof Cwalina and Brad Abrams offer guidelines for framework design from the top down. From their long experience and deep insight, you will learn

  • The general philosophy of framework design
  • Principles and guidelines that are fundamental to overall framework design
  • Naming guidelines for the various parts of a framework, such as namespaces, types, and members
  • Guidelines for the design of types and members of types
  • Issues and guidelines that are important to ensure appropriate extensibilityin your framework
  • Guidelines for working with exceptions, the preferred error reporting mechanism in the .NET Framework and WinFX
  • Guidelines for extending and using types that commonly appear in frameworks
  • Guidelines for and examples of common framework design patterns

Guidelines in this book come in four major forms: Do, Consider, Avoid, and Do not. In general, a Do guideline should almost always be followed, a Consider guideline should generally be followed, an Avoid guideline indicates that something is generally not a good idea, and a Do not guideline indicates something you should almost never do. Every guideline includes a discussion of its applicability, and most guidelines include a code example.

A companion DVD includes the Designing .NET Class Libraries video series, instructional presentations by the authors on design guidelines for developing classes and components that extend the .NET Framework. A sample API specification and other useful resources are also included.

Product Details

ISBN-13: 9780321246752
Publisher: Addison-Wesley
Publication date: 09/19/2005
Series: Microsoft .NET Development Series
Edition description: Older Edition
Pages: 384
Product dimensions: 7.24(w) x 9.43(h) x 1.17(d)

About the Author

Krzysztof Cwalina is a Program Manager on the Common Language Runtime team at Microsoft Corporation. He began his career at Microsoft designing APIs for the first release of the .NET Framework. He has been responsible for several namespaces in the Framework, including System.Collections, System.Diagnostics, System.Messaging, and others. He was also one of the original members of the FxCop team. Currently, he is leading a companywide effort to develop, promote, and apply the design guidelines to the .NET Framework and WinFX. Krzysztof graduated with a B.S. and an M.S. in computer science from the University of Iowa.

Brad Abrams was a founding member of both the Common Language Runtime and .NET Framework teams at Microsoft, where he is currently a Lead Program Manager. Brad has been involved with WinFX and Windows Vista efforts from the beginning. His primary role is to ensure consistency and developer productivity of the .NET Framework through Vista and beyond. His popular blog can be found at

Read an Excerpt

This book, Framework Design Guidelines, presents best practices for designing frameworks, which are reusable object-oriented libraries. The guidelines are applicable to frameworks ranging in size and in their scale of reuse:

  • Large system frameworks, such as the .NET Framework, usually consisting of thousands of types and used by millions of developers.
  • Medium-size reusable layers of large distributed applications
  • or extensions to system frameworks, such as the Web Services
  • Enhancements.
  • Small components shared among several applications; for example, a grid control library.

It is worth noting that this book focuses on design issues that directly affect the programmability of a framework (publicly accessible APIs). As a result, we generally do not cover much in terms of implementation details. Just like a user interface design book doesn't cover the details of how to implement hit testing, this book does not describe how to implement a binary sort, for example. This scope allows us to provide a definitive guide for framework designers instead of being yet another book about programming.

These guidelines were created in the early days of .NET Framework development. They started as a small set of naming and design conventions but have been enhanced, scrutinized, and refined to a point where they are generally considered the canonical way to design frameworks at Microsoft. They carry the experience and cumulative wisdom of thousands of developer hours over three versions of the .NET Framework. We tried to avoid basing the text purely on some idealistic design philosophies, and we think its day-to-day use by development teams at Microsoft has made it an intensely pragmatic book.

The book contains many annotations that explain trade-offs, explain history, amplify, or provide critiquing views on the guidelines. These annotations are written by experienced framework designers, industry experts, and users. They are the stories from the trenches that add color and setting for many of the guidelines presented.

To make them more easily distinguished in text, namespace names, classes, interfaces, methods, properties, and types are set in monospace font. The book assumes basic familiarity with .NET Framework programming. A few guidelines assume familiarity with features introduced in version 2.0 of the Framework. If you are looking for a good introduction to Framework programming, there are some excellent suggestions in the Suggested Reading List at the end of the book.

Guideline Presentation

The guidelines are organized as simple recommendations using Do, Consider, Avoid, and Do not. Each guideline describes either a good or bad practice and all have a consistent presentation. Good practices have a check mark in front of them, and bad practices have an X in front of them. The wording of each guideline also indicates how strong the recommendation is. For example, a Do guideline is one that should always1 be followed (all examples are from this book):

DO name custom attribute classes with the suffix "Attribute."

public class ObsoleteAttribute : Attribute { ... }

On the other hand, Consider guidelines should generally be followed, but if you fully understand the reasoning behind a guideline and have a good reason to not follow it anyway, you should not feel bad about breaking the rules:

CONSIDER defining a struct instead of a class if instances of the type are small and commonly short-lived or are commonly embedded in other objects.

Similarly, Do not guidelines indicate something you should almost never do:

DO NOT assign instances of mutable types to read-only fields.

Less strong, Avoid guidelines indicate that something is generally not a good idea, but there are known cases where breaking the rule makes sense:

AVOID using

ICollection<T> or

ICollection as a parameter just to access the Count property.

Some more complex guidelines are followed with additional background information, illustrative code samples, and rationale:

DO implement

IEquatable<T> on value types. The

Object.Equals method on value types causes boxing and its default implementation is not very efficient because it uses reflection.

IEquatable<T>.Equals can offer much better performance and can be implemented so it does not cause boxing.

public struct Int32 : IEquatable{
public bool Equals(Int32 other){ ... }

Language Choice and Code Examples

One of the goals of the Common Language Runtime is to support a variety of programming languages: those provided by Microsoft, such as C++, VB, and C#, as well as third-party languages such as Eiffel, COBOL, Python, and others. Therefore, this book was written to be applicable to a broad set of languages that can be used to develop and consume modern frameworks. To reinforce the message of multilanguage framework design, we considered writing code examples using several different programming languages. However, we decided against this. We felt that using different languages would help to carry the philosophical message, but it could force readers to learn several new languages, which is not the objective of this book.

We decided to choose a single language that is most likely to be readable to the broadest range of developers. We picked C#, because it is a simple language from the C family of languages (C, C++, Java, and C#), a family with a rich history in framework development.

Choice of language is close to the hearts of many developers, and we offer apologies to those who are uncomfortable with our choice.

About This Book This book offers guidelines for framework design from the top down.

Chapter 1 is a brief introduction to the book, describing the general philosophy of framework design. This is the only chapter without guidelines.

Chapter 2, "Framework Design Fundamentals," offers principles and guidelines that are fundamental to overall framework design.

Chapter 3, "Naming Guidelines," contains naming guidelines for various parts of a framework, such as namespaces, types, members, and common design idioms.

Chapter 4, "Type Design Guidelines," provides guidelines for the general design of types.

Chapter 5,"Member Design," takes it a step further and presents guidelines for the design of members of types. Chapter 6, "Designing for Extensibility," presents issues and guidelines that are important to ensure appropriate extensibility in your framework.

Chapter 7, "Exceptions," presents guidelines for working with exceptions, the preferred error reporting mechanisms.

Chapter 8, "Usage Guidelines," contains guidelines for extending and using types that commonly appear in frameworks.

Chapter 9, "Common Design Patterns," offers guidelines and examples of common framework design patterns.

Appendix A contains a short description of coding conventions used in this book. Appendix B describes a tool called FxCop. The tool can be used to analyze framework binaries for compliance with the guidelines described in this book. A link to the tool is included on the DVD that accompanies this book.

Appendix C is an example of an API specification that framework designers within Microsoft create when designing APIs.

Included with the book is a DVD that contains several hours of video presentations covering topics presented in this book by the authors, a sample API specification, and other useful resources.

1.Always might be a bit too strong a word. There are guidelines that should literally be always followed, but they are extremely rare. On the other hand, you probably need to have a really unusual case for breaking a "Do" guideline and still have it be beneficial to the users of the framework.

Table of Contents

Figures xiii Acknowledgments xxv

About the Authors xxvii

Tables xv Foreword xvii

Preface xix

Chapter 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 3

1.1.3 Well-Designed Frameworks Are Full of Trade-Offs 4

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 5

1.1.7 Well-Designed Frameworks Are Consistent 6

Chapter 2: Framework Design Fundamentals 7

2.1 Progressive Frameworks 9

2.2 Fundamental Principles of Framework Design 12

2.2.1 The Principle of Scenario-Driven Design 13

2.2.2 The Principle of Low Barrier to Entry 19

2.2.3 The Principle of Self-Documenting Object Models 23

2.2.4 The Principle of Layered Architecture 29

2.3 Summary 31

Chapter 3: Naming Guidelines 33

3.1 Capitalization Conventions 34

3.1.1 Capitalization Rules for Identifiers 34

3.1.2 Capitalizing Acronyms 36

3.1.3 Capitalizing Compound Words and Common Terms 39

3.1.4 Case Sensitivity 41

3.2 General Naming Conventions 41

3.2.1 Word Choice 42

3.2.2 Using Abbreviations and Acronyms 43

3.2.3 Avoiding Language-Specific Names 44

3.2.4 Naming New Versions of Existing APIs 46

3.3 Names of Assemblies and DLLs 48

3.4 Names of Namespaces 49

3.4.1 Namespaces and Type Name Conflicts 51

3.5 Names of Classes, Structs, and Interfaces 54

3.5.1 Names of Generic Type Parameters 56

3.5.2 Names of Common Types 57

3.5.3 Naming Enumerations 59

3.6 Names of Type Members 60

3.6.1 Names of Methods 60

3.6.2 Names of Properties 61

3.6.3 Names of Events 63

3.6.4 Naming Fields 64

3.7 Naming Parameters 64

3.8 Naming Resources 65

3.9 Summary 66

Chapter 4: Type Design Guidelines 67

4.1 Types and Namespaces 69

4.1.1 Standard Subnamespace Names 73

4.2 Choosing Between Class and Struct 74

4.3 Choosing Between Class and Interface 77

4.4 Abstract Class Design 83

4.5 Static Class Design 85

4.6 Interface Design 86

4.7 Struct Design 89

4.8 Enum Design 91

4.8.1 Designing Flag Enums 97

4.8.2 Adding Values to Enums 100

4.9 Nested Types 101

4.10 Summary 104

Chapter 5: Member Design 105

5.1 General Member Design Guidelines 105

5.1.1 Member Overloading 105

5.1.2 Implementing Interface Members Explicitly 111

5.1.3 Choosing Between Properties and Methods 115

5.2 Property Design 120

5.2.1 Indexed Property Design 122

5.2.2 Property Change Notification Events 124

5.3 Constructor Design 125

5.3.1 Type Constructor Guidelines 131

5.4 Event Design 132

5.4.1 Custom Event Handler Design 138

5.5 Field Design 139

5.6 Operator Overloads 141

5.6.1 Overloading Operator == 146

5.6.2 Conversion Operators 146

5.7 Parameter Design 148

5.7.1 Choosing Between Enum and Boolean Parameters 150

5.7.2 Validating Arguments 152

5.7.3 Parameter Passing 155

5.7.4 Members with Variable Number of Parameters 157

5.7.5 Pointer Parameters 161

5.8 Summary 162

Chapter 6: Designing for Extensibility 163

6.1 Extensibility Mechanisms 163

6.1.1 Unsealed Classes 164

6.1.2 Protected Members 165

6.1.3 Events and Callbacks 166

6.1.4 Virtual Members 168

6.1.5 Abstractions (Abstract Types and Interfaces) 170

6.2 Base Classes 172

6.3 Sealing 174

6.4 Summary 177

Chapter 7: Exceptions 179

7.1 Exception Throwing 183

7.2 Choosing the Right Type of Exception to Throw 189

7.2.1 Error Message Design 189

7.2.2 Exception Handling 191

7.2.3 Wrapping Exceptions 195

7.3 Using Standard Exception Types 197

7.3.1 Exception and SystemException 197

7.3.2 ApplicationException 197

7.3.3 InvalidOperationException 198

7.3.4 ArgumentException, ArgumentNullException, and ArgumentOutOfRangeException 198

7.3.5 NullReferenceException, IndexOutOfRangeException, and AccessViolationException 199

7.3.6 StackOverflowException 200

7.3.7 OutOfMemoryException 200

7.3.8 ComException, SEHException, and other CLR Exceptions 201

7.3.9 ExecutionEngineException 201

7.4 Designing Custom Exceptions 202

7.5 Exceptions and Performance 203

7.5.1 Tester-Doer Pattern 203

7.5.2 Try-Parse Pattern 204

7.6 Summary 205

Chapter 8: Usage Guidelines 207

8.1 Arrays 207

8.2 Attributes 209

8.3 Collections 211

8.3.1 Collection Parameters 213

8.3.2 Collection Properties and Return Values 214

8.3.3 Choosing Between Arrays and Collections 218

8.3.4 Implementing Custom Collections 219

8.4 ICloneable 221

8.5 IComparable<T> and IEquatable<T> 222

8.6 IDisposable 223

8.7 Object 224

8.7.1 Object.Equals 224

8.7.2 Object.GetHashCode 225

8.7.3 Object.ToString 227

8.8 Uri 228

8.8.1 System.Uri Implementation Guidelines 229

8.9 System.

8.10 Equality Operators 231

8.10.1 Equality Operators on Value Types 232

8.10.2 Equality Operators on Reference Types 232

Chapter 9: Common Design Patterns 235

9.1 Aggregate Components 235

9.1.1 Component-Oriented Design 237

9.1.2 Factored Types 240

9.1.3 Aggregate Component Guidelines 240

9.2 The Async Pattern 243

9.2.1 Async Pattern Basic Implementation Example 247

9.3 Dispose Pattern 248

9.3.1 Basic Dispose Pattern 251

9.3.2 Finalizable Types 256

9.4 Factories 260

9.5 Optional Feature Pattern 264

9.6 Template Method 267

9.7 Timeouts 269

9.8 And in the End ... 271

Appendix A: C# Coding Style Conventions 273

A.1 General Style Conventions 274

A.1.1 Brace Usage 274

A.1.2 Space Usage 275

A.1.3 Indent Usage 276

A.2 Naming Conventions 277

A.3 Comments 277

A.4 File Organization 278

Appendix B: Using FxCop to Enforce the Design Guidelines 281

B.1 What Is FxCop? 281

B.2 The Evolution of FxCop 282

B.3 How Does It Work? 283

B.4 FxCop Guideline Coverage 284

B.4.1 FxCop Rules for the Naming Guidelines 284

B.4.2 FxCop Rules for the Type Design Guidelines 293

B.4.3 FxCop Rules for Member Design 296

B.4.4 FxCop Rules for Designing for Extensibility 302

B.4.5 FxCop Rules for Exceptions 303

B.4.6 FxCop Rules for Usage Guidelines 305

B.4.7 FxCop Rules for Design Patterns 309

Appendix C: Sample API Specification 311 Glossary 319 Suggested Reading List 323 Index 327

Customer Reviews

Most Helpful Customer Reviews

See All Customer Reviews