These are short descriptions of each chapter in this book.
Some parts may just be outlining headlines. This is because most parts of this
book are discrete guidelines.
Introduction
The introductory chapter is short, and it introduces
frameworks and their definitions. Most of this chapter focuses on giving seven
qualities of a well-designed framework. This allows readers to get a correct
idea what is entailed in well-designed frameworks.
Framework Design Fundamentals
The second chapter is where guidelines first appear in this
book. The main goal of this chapter, as its title suggests, is to provide
several fundamental framework concepts and guidelines. In this chapter you
will learn how to design a powerful framework to meet all framework design
requirements. To learn this, you need to know how a framework should be
designed to achieve a powerful and popular framework. First this book teaches
how to write an easy to use framework. Then it describes how to write a
progressive framework, which is a framework that can be used by broad range of
developers with different skills and experiences. This section contains some
notes from .NET framework designers about what they have done to make it a
progressive framework. One can also explore some comparisons between .NET
framework and other frameworks.
The remainder of this chapter is about framework design
principles such as Scenario-Driven design, low barrier to entry,
self-documenting object models and layered architecture.
Naming Guidelines
The third chapter is about naming. One might ask how this
can be important when many developers have personal or company naming
conventions in place. But when it comes to designing a library or framework
which will be used by many users beyond a single team or company this can be
very important.
In this chapter you'll be introduced to two capitalization
conventions in the .NET framework, Pascal Casing and Camel Casing, and will see
some general guidelines about naming.
After this the book will explain many cases in designing a
framework and suitable conventions for each case. Some of these guidelines can
be grouped in these topics: choosing correct words, using abbreviations and
acronyms, language specific names, how to name new APIs when current APIs
already exist, how to name assemblies and how to name namespaces.
The last part of this chapter will talk about some
guidelines to name classes, interfaces, structures, enumerations, methods,
events and parameters. You will see short sections about choosing correct names
and namespace structures for resources. This chapter will help developers to
maintain consistent naming conventions in libraries and frameworks and allow
other developers to use them easily.
Type Design Guidelines
The fourth chapter delves into the topic of types. It
starts with a short introduction to different types such as reference and value
types and their differences. It then gives some guidelines about namespaces and
subnamespaces.
At this point the chapter follows with some guides for two
common developer questions: "Where and when should I use classes or Structs?"
and "Where and when should I use a class or an interface?" Most of
the remaining pages in this chapter are dedicated to designing several types
such as abstract classes, static classes, interfaces, Structs, and Enums. The
chapter ends with nested types, which is a type defined inside another type.
Member Design
Members of a type are one of the common parts of an application's
code. This chapter talks about constructors, methods, properties, events and
fields. The beginning pages of this chapter discuss some general guidelines for
all of these members. As a part of this discussion, authors have written about
implementing interfaces explicitly (there are two ways two implement an
interface: explicitly and implicitly and Visual Studio helps you to do them by
auto-generating the code) and when and how to choose properties or methods.
After these general guidelines you see some guides about designing
properties, events, fields, parameter design, and operator overloading to finish
this chapter.
Designing for Extensibility
Extensibility is an important part of a framework to let all
developers of that framework extend its functionality or customize its default
behavior in some parts and get something for their needs. There are some ways
to enable extensibility for a framework. In chapter 6 you see all these ways
as well as pros and cons of their usage and some guidelines about them.
This chapter has a short introduction and list of guidelines
about extensibility mechanisms then follows with two short topics about base
classes and sealing.
Exceptions
Exceptions are important enough to have a separate chapter.
Exception handling is base part of every framework and its power has a direct
impact on the power of framework.
Some general guidelines about exceptions make the first
topic of this chapter. After that, you learn how and when to throw
exceptions. This may seem an unimportant thing, but it has a huge impact on
your framework or library. Another thing that helps you to build a powerful
framework is to help your framework users in choosing the right type of
exception to throw. Some .NET developers don't have good knowledge about all
default exception types in .NET, so the next section of this chapter talks
about available exception types and gives some advices on their usage.
The last 4 pages of the 6th chapter give some guidelines
about designing custom exceptions and the relationship between exceptions and
performance.
Usage Guidelines
Some common types are frequently used in public APIs. An
example of one of most common groups is collections.
Do you know how and when to use arrays in public APIs? The
first two pages discuss this.
Attributes are a common way to make custom configurations in
types. A topic of the next few chapters is attributes.
Now it's time to talk about a common and important topic:
collections. You commonly use different types of collections as type for
properties, parameters or return types. This part of the 8th chapter has a
great discussion about collections in good details. It also explains how to
write custom collections and when to use arrays or collections.
A one page of discussion of the IClonable interface is
included in the next part of chapter 8. ICompareable and IEquatable are two other
interfaces that should be implemented in some cases. You will learn when and
where to implement these. IDisposable is another common interface and has a
very short discussion in the book.
Object! Yes, Object! This simple type comes with an
excellent discussion in this chapter. Two methods of this type, GetHashCode
and ToString, always should be considered when you're dealing with this type
and they have some important guides.
And the last parts of this chapter talk about System.Xml as
a common type and equality operators.
Common Design Patterns
This book finishes with some common patterns for designing a
framework. These patterns may help you somewhere during the development of a
library or framework.
Aggregate components, component oriented design and their
guidelines are the first topic. Aggregate component is a component that uses a
set of existing components and APIs to provide simpler APIs for common scenarios.
The Async pattern lets you implement asynchronous operations
for your types. This means you can use this pattern to provide appropriate
methods to let developers work with your type methods asynchronously. This
pattern is a common pattern in ADO.NET APIs.
Releasing system resources is a very sensitive part of all
programming. Programs should release system resources after using them. GC
does this for you automatically but sometimes you have to do it yourself. On
the other hand you should consider the dispose pattern in your framework
because frameworks are sensitive from a resource usage point of view.
Factories are a way to simplify the process of using a
type. Usually you create an instance of an object, set it, and call its
methods, but factories make this process shorter and easier and usually make it
as short as one line of code.
The Optional Feature pattern is a way to allow developers to
add their custom features based on what you have in mind for your framework.
Using this pattern you can manage the way that they can extend and customize
your framework.
The Template Method is a way to keep the default structure
of an algorithm for subclasses but redefine its steps. Lastly the chapter ends
by discussing this pattern.
Timeouts are the last topic of this chapter and book. Some
operations use timeouts and there are some guidelines that should be considered
in designing a type with timeouts.
