Framework Design Guidelines Conventions, Idioms, and Patterns for Reusable .NET Libraries

by Cwalina, Krzysztof; Abrams, Brad

• ISBN13: 9780321545619
• ISBN10: 0321545613
• Edition: 2nd
• Format: Hardcover
• Copyright: 2008-10-22
• Publisher: Addison-Wesley Professional

Summary

Lead developers on the .NET team teach best practices for designing system frameworks and reusable libraries for use with .NET.

Author Biography

Brad Abrams was a founding member of the Common Language Runtime and .NET Framework teams at Microsoft Corporation. He has been designing parts of the .NET Framework since 1998 and is currently Group Program Manager of the .NET Framework team. Brad started his framework design career building the Base Class Library (BCL) that ships as a core part of the .NET Framework. Brad was also the lead editor on the Common Language Specification (CLS), the .NET Framework Design Guidelines, and the libraries in the ECMA\ISO CLI Standard. Brad has authored and coauthored multiple publications, including Programming in the .NET Environment and .NET Framework Standard Library Annotated Reference, Volumes 1 and 2. Brad graduated from North Carolina State University with a B.S. in computer science. You can find his most recent musings on his blog at http://blogs.msdn.com/BradA.

 

Krzysztof Cwalina is a program manager on the .NET Framework team at Microsoft. He was a founding member of the .NET Framework team and throughout his career has designed many .NET Framework APIs and framework development tools, such as FxCop. He is currently leading a companywide effort to develop, promote, and apply framework design and architectural guidelines to the .NET Framework. He is also leading the team responsible for delivering core .NET Framework APIs. Krzysztof graduated with a B.S. and an M.S. in computer science from the University of Iowa. You can find his blog at http://blogs.msdn.com/kcwalina.

Table of Contents

Figures	p. xvii
Tables	p. xix
Foreword	p. xxi
Foreword to the First Edition	p. xxiii
Preface	p. xxv
Acknowledgments	p. xxxi
About the Authors	p. xxxiii
About the Annotators	p. xxxv
Introduction	p. 1
Qualities of a Well-Designed Framework	p. 3
Framework Design Fundamentals	p. 9
Progressive Frameworks	p. 11
Fundamental Principles of Framework Design	p. 14
Naming Guidelines	p. 37
Capitalization Conventions	p. 38
General Naming Conventions	p. 46
Names of Assemblies and DLLs	p. 54
Names of Namespaces	p. 56
Names of Classes, Structs, and Interfaces	p. 60
Names of Type Members	p. 68
Naming Parameters	p. 73
Naming Resources	p. 74
Type Design Guidelines	p. 77
Types and Namespaces	p. 79
Choosing Between Class and Struct	p. 84
Choosing Between Class and Interface	p. 88
Abstract Class Design	p. 95
Static Class Design	p. 97
Interface Design	p. 98
Struct Design	p. 101
Enum Design	p. 103
Nested Types	p. 115
Types and Assembly Metadata	p. 118
Member Design	p. 121
General Member Design Guidelines	p. 121
Property Design	p. 138
Constructor Design	p. 144
Event Design	p. 153
Field Design	p. 159
Extension Methods	p. 162
Operator Overloads	p. 168
Parameter Design	p. 175
Designing for Extensibility	p. 193
Extensibility Mechanisms	p. 193
Base Classes	p. 206
Sealing	p. 207
Exceptions	p. 211
Exception Throwing	p. 216
Choosing the Right Type of Exception to Throw	p. 221
Using Standard Exception Types	p. 234
Designing Custom Exceptions	p. 239
Exceptions and Performance	p. 240
Usage Guidelines	p. 245
Arrays	p. 245
Attributes	p. 247
Collections	p. 250
DateTime and DateTimeOffset	p. 261
ICloneable	p. 263
IComparable and IEquatable	p. 264
IDisposable	p. 266
Nullable	p. 266
Object	p. 268
Serialization	p. 274
Uri	p. 283
System.Xml Usage	p. 284
Equality Operators	p. 286
Common Design Patterns	p. 289
Aggregate Components	p. 289
Table of Contents provided by Publisher. All Rights Reserved.

Excerpts

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 APIs1). 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 inmonospacefont. The book assumes basic familiarity with .NET Framework programming. A few guidelines assume familiarity with features introduced in version 3.5 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 ex. The wording of each guideline also indicates how strong the recommendation is. For example, a Doguideline is one that should always2be followed. On the other hand, Considerguidelines 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. Similarly, Do notguidelines indicate something you should almost never do. Less strong, Avoidguidelines indicate that something is generally not a good idea, but there are known cases where breaking the rule makes sense. Some more complex guidelines are followed with additional background information, illustrative code samples, and rationale. Language Choice and Code Examples One of the goals of the Common Language Runtime is to support a variety of programming languages: those with implementations provided by Microsoft, such as C++, VB, C#, F#, Python, and Ruby, as well as third-party languages such as Eiffel, COBOL, Fortran, 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. This includes public types, and their public, protected and explicitly implemented members of these types. 2. 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.