Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries (Microsoft.net Development Series) / Edition 2

Other Format (Print)
Used and New from Other Sellers
Used and New from Other Sellers
from $40.01
Usually ships in 1-2 business days
(Save 38%)
Other sellers (Other Format)
  • All (12) from $40.01   
  • New (9) from $40.01   
  • Used (3) from $42.95   

Overview

Framework Design Guidelines, Second Edition, teaches developers the best practices for designing reusable libraries for the Microsoft .NET Framework. Expanded and updated for .NET 3.5, this new edition focuses on the design issues that directly affect the programmability of a class library, specifically its publicly accessible APIs.

This book can improve the work of any .NET developer producing code that other developers will use. It includes copious annotations to the guidelines by thirty-five prominent architects and practitioners of the .NET Framework, providing a lively discussion of the reasons for the guidelines as well as examples of when to break those guidelines.

Microsoft architects Krzysztof Cwalina and Brad Abrams teach framework design from the top down. From their significant combined experience and deep insight, you will learn

  • The general philosophy and fundamental principles of framework design
  • Naming guidelines for the various parts of a framework
  • Guidelines for the design and extending of types and members of types
  • Issues affecting–and guidelines for ensuring–extensibility
  • How (and how not) to design exceptions
  • Guidelines for–and examples of–common framework design patterns

Guidelines in this book are presented in four major forms: Do, Consider, Avoid, and Do not. These directives help focus attention on practices that should always be used, those that should generally be used, those that should rarely be used, and those that should never be used. Every guideline includes a discussion of its applicability, and most include a code example to help illuminate the dialogue.

Framework Design Guidelines, Second Edition, is the only definitive source of best practices for managed code API development, direct from the architects themselves.

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 and tools are also included.

Read More Show Less

Editorial Reviews

From the Publisher

Framework Design Guidelines is one of those rare books that can be read at different reading levels and can be useful to different kinds of developers. Regardless of whether you want to design an effective object model, improve your understanding of the .NET Framework, borrow from the experience of software gurus, stay clear of the most common programming mistakes, or just get an idea of the huge effort that led to the .NET initiative, this book is a must-read.”

—Francesco Balena, The VB Migration Partner Team (www.vbmigration.com), Code Architect, Author, and Microsoft Regional Director, Italy

“Frameworks are valuable but notoriously difficult to construct: your every decision must be geared toward 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

“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

“Updated for the new language features of the .NET Framework 3.0 and 3.5, this book continues to be the definitive resource for .NET developers and architects who are designing class library frameworks. Some of the existing guidelines have been expanded with new annotations and more detail, and new guidance covering such features as extension methods and nullable types has also been included. The guidance will help any developer write clearer and more understandable code, while the annotations provide invaluable insight into some of the design decisions that made the .NET Framework what it is today.”

—Scott Dorman, Microsoft MVP and President, Tampa Bay International Association of Software Architects

“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

“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

“The second edition of Framework Design Guidelines gives you new, important insight into designing your own class libraries: Abrams and Cwalina frankly discuss the challenges of adding new features to shipping versions of their products with minimal impact on existing code. You’ll find great examples of how to create version N+1 of your software by learning how the .NET class library team

created versions 2.0, 3.0, and 3.5 of the .NET library. They were able to add generics, WCF, WPF, WF, and LINQ with minimal impact on the existing APIs, even providing capabilities for customers wanting to use only some of the new features, while still maintaining compatibility with the original library.”

—Bill Wagner, Founder and Consultant, SRT Solutions, author of Effective C# and More Effective C#

“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, Sr. Software Engineer, Balance Technology Inc.

“An instant classic.”

—From the Foreword by Miguel de Icaza

Read More Show Less

Product Details

  • ISBN-13: 9780321545619
  • Publisher: Addison-Wesley
  • Publication date: 11/5/2008
  • Series: Microsoft .NET Development Series
  • Edition description: New Edition
  • Edition number: 2
  • Pages: 438
  • Product dimensions: 7.20 (w) x 9.30 (h) x 1.40 (d)

Meet the Author

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.

Read More Show Less

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 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 in monospace font.

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 Do guideline is one that should always2 be followed. 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. Similarly, Do not guidelines indicate something you should almost never do. Less strong, Avoid guidelines 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.

Read More Show Less

Table of Contents

Figures xvii

Tables xix

Foreword xxi

Foreword to the First Edition xxiii

Preface xxv

Acknowledgments xxxi

About the Authors xxxiii

About the Annotators xxxv

Chapter 1: Introduction 1

1.1: Qualities of a Well-Designed Framework 3

Chapter 2: Framework Design Fundamentals 9

2.1: Progressive Frameworks 11

2.2: Fundamental Principles of Framework Design 14

Chapter 3: Naming Guidelines 37

3.1: Capitalization Conventions 38

3.2: General Naming Conventions 46

3.3: Names of Assemblies and DLLs 54

3.4: Names of Namespaces 56

3.5: Names of Classes, Structs, and Interfaces 60

3.6: Names of Type Members 68

3.7: Naming Parameters 73

3.8: Naming Resources 74

Chapter 4: Type Design Guidelines 77

4.1: Types and Namespaces 79

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: Enum Design 103

4.9: Nested Types 115

4.10: Types and Assembly Metadata 118

Chapter 5: Member Design 121

5.1: General Member Design Guidelines 121

5.2: Property Design 138

5.3: Constructor Design 144

5.4: Event Design 153

5.5: Field Design 159

5.6: Extension Methods 162

5.7: Operator Overloads 168

5.8: Parameter Design 175

Chapter 6: Designing for Extensibility 193

6.1: Extensibility Mechanisms 193

6.2: Base Classes 206

6.3: Sealing 207

Chapter 7: Exceptions 211

7.1: Exception Throwing 216

7.2: Choosing the Right Type of Exception to Throw 221

7.3: Using Standard Exception Types 234

7.4: Designing Custom Exceptions 239

7.5: Exceptions and Performance 240

Chapter 8: Usage Guidelines 245

8.1: Arrays 245

8.2: Attributes 247

8.3: Collections 250

8.4: DateTime and DateTimeOffset 261

8.5: ICloneable 263

8.6: IComparable and IEquatable 264

8.7: IDisposable 266

8.8: Nullable 266

8.9: Object 268

8.10: Serialization 274

8.11: Uri 283

8.12: System.Xml Usage 284

8.13: Equality Operators 286

Chapter 9: Common Design Patterns 289

9.1: Aggregate Components 289

9.2: The Async Patterns 298

9.3: Dependency Properties 312

9.4: Dispose Pattern 319

9.5: Factories 332

9.6: LINQ Support 337

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

Appendix A: C# Coding Style Conventions 363

A.1: General Style Conventions 364

A.2: Naming Conventions 367

A.3: Comments 368

A.4: File Organization 369

Appendix 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

Appendix C: Sample API Specification 405

Glossary 413

Suggested Reading List 419

Index 423

Read More Show Less

Preface

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 in monospace font.

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 Do guideline is one that should always2 be followed. 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. Similarly, Do not guidelines indicate something you should almost never do. Less strong, Avoid guidelines 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.

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously
Sort by: Showing 1 – 2 of 1 Customer Reviews
  • Anonymous

    Posted August 4, 2011

    No text was provided for this review.

  • Anonymous

    Posted January 14, 2010

    No text was provided for this review.

Sort by: Showing 1 – 2 of 1 Customer Reviews

If you find inappropriate content, please report it to Barnes & Noble
Why is this product inappropriate?
Comments (optional)