现代C++设计：泛型编程与设计模式精华

需积分: 9 75 浏览量更新于2024-07-23 收藏 2.14MB PDF 举报

"《现代C++设计：泛型编程与设计模式应用》是一本由Andrei Alexandrescu编著的计算机科学经典著作，于2001年2月由Addison Wesley出版社发行，ISBN号为0-201-70431-5，共352页。该书在C++设计领域具有重要意义，它革新性地展示了"通用模式"或"模式模板"，这是一种在C++中创建可扩展设计的强大新方法，将模板和模式结合得超越了人们的想象，使得设计和编码更为灵活和可复用。书中深入探讨了"泛型组件"的概念，即可重用的设计模板，这些模板能够自动生成编译器所需的样板代码，从而大大提高开发效率和代码的可维护性。通过这些"通用编程"技术，作者展现了如何将设计模式（如工厂模式、策略模式等）与C++语言特性相结合，创造出既表达力强又适应性强的代码设计。 Herb Sutter给出了高度推荐，他指出这本书对于所有涉及C++设计和编码的程序员来说都是必读之作，因为它揭示了即使在C++这样一个广泛研究过的领域，仍有许多新的设计理念和实践值得探索。前言部分由John Vlissides撰写，他认为Andrei Alexandrescu在这本书中开辟了全新的视角，展现了一种创新且富有前瞻性的设计方法。阅读《现代C++设计：泛型编程与设计模式应用》，读者将不仅学习到C++语言的高级技巧，还将了解到如何利用这些技术来构建更加模块化、可扩展和高效的软件系统。这不仅适用于初级C++开发者，对于经验丰富的程序员来说，也是一次提升设计能力和编程实践的宝贵机会。这本书是每个C++专业人员的案头必备，是理解和掌握现代C++设计原则和最佳实践的重要参考书。"

Chapter 1. Policy-Based Class Design

This chapter describes policies and policy classes, important class design techniques that enable the

creation of flexible, highly reusable libraries—as Loki aims to be. In brief, policy-based class design

fosters assembling a class with complex behavior out of many little classes (called policies), each of which

takes care of only one behavioral or structural aspect. As the name suggests, a policy establishes an

interface pertaining to a specific issue. You can implement policies in various ways as long as you respect

the policy interface.

Because you can mix and match policies, you can achieve a combinatorial set of behaviors by using a

small core of elementary components.

Policies are used in many chapters of this book. The generic

SingletonHolder class template (Chapter

6) uses policies for managing lifetime and thread safety. SmartPtr (Chapter 7) is built almost entirely

from policies. The double-dispatch engine in Chapter 11

uses policies for selecting various trade-offs. The

generic Abstract Factory (Gamma et al. 1995

) implementation in Chapter 9 uses a policy for choosing a

creation method.

This chapter explains the problem that policies are intended to solve, provides details of policy-based class

design, and gives advice on decomposing a class into policies.

1.1 The Multiplicity of Software Design

Software engineering, maybe more than any other engineering discipline, exhibits a rich multiplicity: You

can do the same thing in many correct ways, and there are infinite nuances between right and wrong. Each

path opens up a new world. Once you choose a solution, a host of possible variants appears, on and on at

all levels—from the system architecture level down to the smallest coding detail. The design of a software

system is a choice of solutions out of a combinatorial solution space.

Let's think of a simple, low-level design artifact: a smart pointer (Chapter 7

). A smart pointer class can be

single threaded or multithreaded, can use various ownership strategies, can make various trade-offs

between safety and speed, and may or may not support automatic conversions to the underlying raw

pointer type. All these features can be combined freely, and usually exactly one solution is best suited for a

given area of your application.

The multiplicity of the design space constantly confuses apprentice designers. Given a software design

problem, what's a good solution to it? Events? Objects? Observers? Callbacks? Virtuals? Templates? Up to

a certain scale and level of detail, many different solutions seem to work equally well.

The most important difference between an expert software architect and a beginner is the knowledge of

what works and what doesn't. For any given architectural problem, there are many competing ways of

solving it. However, they scale differently and have distinct sets of advantages and disadvantages, which

may or may not be suitable for the problem at hand. A solution that appears to be acceptable on the

whiteboard might be unusable in practice.

Designing software systems is hard because it constantly asks you to choose. And in program design, just

as in life, choice is hard.

Good, seasoned designers know what choices will lead to a good design. For a beginner, each design

choice opens a door to the unknown. The experienced designer is like a good chess player: She can see

more moves ahead. This takes time to learn. Maybe this is the reason why programming genius may show

at an early age, whereas software design genius tends to take more time to ripen.

In addition to being a puzzle for beginners, the combinatorial nature of design decisions is a major source

of trouble for library writers. To implement a useful library of designs, the library designer must classify

and accommodate many typical situations, yet still leave the library open-ended so that the application

programmer can tailor it to the specific needs of a particular situation.

Indeed, how can one package flexible, sound design components in libraries? How can one let the user

configure these components? How does one fight the "evil multiplicity" of design with a reasonably sized

army of code? These are the questions that the remainder of this chapter, and ultimately this whole book,

tries to answer.

1.2 The Failure of the Do-It-All Interface

Implementing everything under the umbrella of a do-it-all interface is not a good solution, for several

reasons.

Some important negative consequences are intellectual overhead, sheer size, and inefficiency. Mammoth

classes are unsuccessful because they incur a big learning overhead, tend to be unnecessarily large, and

lead to code that's much slower than the equivalent handcrafted version.

But maybe the most important problem of an overly rich interface is loss of static type safety. One essential

purpose of the architecture of a system is to enforce certain axioms "by design"—for example, you cannot

create two Singleton objects (see Chapter 6

) or create objects of disjoint families (see Chapter 9). Ideally, a

design should enforce most constraints at compile time.

In a large, all-encompassing interface, it is very hard to enforce such constraints. Typically, once you have

chosen a certain set of design constraints, only certain subsets of the large interface remain semantically

valid. A gap grows between syntactically valid and semantically valid uses of the library. The programmer

can write an increasing number of constructs that are syntactically valid, but semantically illegal.

For example, consider the thread-safety aspect of implementing a Singleton object. If the library fully

encapsulates threading, then the user of a particular, nonportable threading system cannot use the Singleton

library. If the library gives access to the unprotected primitive functions, there is the risk that the

programmer will break the design by writing code that's syntactically—but not semantically—valid.

What if the library implements different design choices as different, smaller classes? Each class would

represent a specific canned design solution. In the smart pointer case, for example, you would expect a

battery of implementations:

SingleThreadedSmartPtr, MultiThreadedSmartPtr,

RefCountedSmartPtr, RefLinkedSmartPtr, and so on.

The problem that emerges with this second approach is the combinatorial explosion of the various design

choices. The four classes just mentioned lead necessarily to combinations such as

SingleThreadedRefCountedSmartPtr. Adding a third design option such as conversion support

leads to exponentially more combinations, which will eventually overwhelm both the implementer and the

user of the library. Clearly this is not the way to go. Never use brute force in fighting an exponential.

Not only does such a library incur an immense intellectual overhead, but it also is extremely rigid. The

slightest unpredicted customization—such as trying to initialize default-constructed smart pointers with a

particular value—renders all the carefully crafted library classes useless.

Designs enforce constraints; consequently, design-targeted libraries must help user-crafted designs to

enforce their own constraints, instead of enforcing predefined constraints. Canned design choices would be

as uncomfortable in design-targeted libraries as magic constants would be in regular code. Of course,

batteries of "most popular" or "recommended" canned solutions are welcome, as long as the client

programmer can change them if needed.

These issues have led to an unfortunate state of the art in the library space: Low-level general-purpose and

specialized libraries abound, while libraries that directly assist the design of an application—the higher-

level structures—are practically nonexistent. This situation is paradoxical because any nontrivial

application has a design, so a design-targeted library would apply to most applications.

Frameworks try to fill the gap here, but they tend to lock an application into a specific design rather than

help the user to choose and customize a design. If programmers need to implement an original design, they

have to start from first principles—classes, functions, and so on.

1.3 Multiple Inheritance to the Rescue?

A TemporarySecretary class inherits both the Secretary and the Temporary classes.

[1]

TemporarySecretary has the features of both a secretary and a temporary employee, and possibly

some more features of its own. This leads to the idea that multiple inheritance might help with handling the

combinatorial explosion of design choices through a small number of cleverly chosen base classes. In such

a setting, the user would build a multi-threaded, reference-counted smart pointer class by inheriting some

BaseSmartPtr class and two classes: MultiThreaded and RefCounted. Any experienced class

designer knows that such a naïve design does not work.

[1]

This example is drawn from an old argument that Bjarne Stroustrup made in favor of multiple inheritance,

in the first edition of The C++ Programming Language. At that time, multiple inheritance had not yet been

introduced in C++.

Analyzing the reasons why multiple inheritance fails to allow the creation of flexible designs provides

interesting ideas for reaching a sound solution. The problems with assembling separate features by using

multiple inheritance are as follows:

1. Mechanics. There is no boilerplate code to assemble the inherited components in a controlled

manner. The only tool that combines

BaseSmartPtr, MultiThreaded, and RefCounted is a

language mechanism called multiple inheritance. The language applies simple superposition in

combining the base classes and establishes a set of simple rules for accessing their members. This

is unacceptable except for the simplest cases. Most of the time, you need to carefully orchestrate

the workings of the inherited classes to obtain the desired behavior.

2. Type information. The base classes do not have enough type information to carry out their tasks.

For example, imagine you try to implement deep copy for your smart pointer class by deriving

from a

DeepCopy base class. What interface would DeepCopy have? It must create objects of a

type it doesn't know yet.

3. State manipulation. Various behavioral aspects implemented with base classes must manipulate

the same state. This means that they must use virtual inheritance to inherit a base class that holds

the state. This complicates the design and makes it more rigid because the premise was that user

classes inherit library classes, not vice versa.

Although combinatorial in nature, multiple inheritance by itself cannot address the multiplicity of design

choices.

1.4 The Benefit of Templates

Templates are a good candidate for coping with combinatorial behaviors because they generate code at

compile time based on the types provided by the user.

Class templates are customizable in ways not supported by regular classes. If you want to implement a

special case, you can specialize any member functions of a class template for a specific instantiation of the

class template. For example, if the template is

SmartPtr<T>, you can specialize any member function for,

say,

SmartPtr<Widget>. This gives you good granularity in customizing behavior.

Furthermore, for class templates with multiple parameters, you can use partial template specialization (as

you will see in Chapter 2

). Partial template specialization gives you the ability to specialize a class

template for only some of its arguments. For example, given the definition

template <class T, class U> class SmartPtr { ... };

you can specialize SmartPtr<T, U> for Widget and any other type using the following syntax:

template <class U> class SmartPtr<Widget, U> { ... };

The innate compile-time and combinatorial nature of templates makes them very attractive for creating

design pieces. As soon as you try to implement such designs, you stumble upon several problems that are

not self-evident:

1. You cannot specialize structure. Using templates alone, you cannot specialize the structure of a

class (its data members). You can specialize only functions.

2. Specialization of member functions does not scale. You can specialize any member function of a

class template with one template parameter, but you cannot specialize individual member

functions for templates with multiple template parameters. For example:

template <class T> class Widget

{

void Fun() { .. generic implementation ... }

};

// OK: specialization of a member function of Widget

template <> Widget<char>::Fun()

{

... specialized implementation ...

}

template <class T, class U> class Gadget

{

void Fun() { .. generic implementation ... }

};

// Error! Cannot partially specialize a member class of Gadget

template <class U> void Gadget<char, U>::Fun()

{

... specialized implementation ...

}

3. The library writer cannot provide multiple default values. At best, a class template implementer

can provide a single default implementation for each member function. You cannot provide

several defaults for a template member function.

Now compare the list of drawbacks of multiple inheritance with the list of drawbacks of templates.

Interestingly, multiple inheritance and templates foster complementary trade-offs. Multiple inheritance has

scarce mechanics; templates have rich mechanics. Multiple inheritance loses type information, which

abounds in templates. Specialization of templates does not scale, but multiple inheritance scales quite

nicely. You can provide only one default for a template member function, but you can write an unbounded

number of base classes.

This analysis suggests that a combination of templates and multiple inheritance could engender a very

flexible device, appropriate for creating libraries of design elements.

1.5 Policies and Policy Classes

Policies and policy classes help in implementing safe, efficient, and highly customizable design elements.

A policy defines a class interface or a class template interface. The interface consists of one or all of the

following: inner type definitions, member functions, and member variables.

Policies have much in common with traits (Alexandrescu 2000a

) but differ in that they put less emphasis

on type and more emphasis on behavior. Also, policies are reminiscent of the Strategy design pattern

(Gamma et al. 1995

), with the twist that policies are compile-time bound.

For example, let's define a policy for creating objects. The Creator policy prescribes a class template of

type

T. This class template must expose a member function called Create that takes no arguments and

returns a pointer to

T. Semantically, each call to Create should return a pointer to a new object of type T.

The exact mode in which the object is created is left to the latitude of the policy implementation.

Let's define some policy classes that implement the Creator policy. One possible way is to use the

new

operator. Another way is to use

malloc and a call to the placement new operator (Meyers 1998b). Yet

another way would be to create new objects by cloning a prototype object. Here are examples of all three

methods:

template <class T>

struct OpNewCreator

{

static T* Create()

{

return new T;

}

};

template <class T>

struct MallocCreator

{

static T* Create()

{

void* buf = std::malloc(sizeof(T));

if (!buf) return 0;

return new(buf) T;

}

};

template <class T>

struct PrototypeCreator

{

PrototypeCreator(T* pObj = 0)

:pPrototype_(pObj)

{}

T* Create()

{

剩余284页未读，继续阅读

txp914

粉丝: 22
资源: 700

现代C++设计：泛型编程与设计模式精华

Modern.C++.Design.Generic.Programming.and.Design.Patterns.Applied繁体版

Modern C++ Design: Generic Programming and Design Patterns Applied

Modern C++ Design Generic Programming and Design Patterns Applied .pdf

[计算机科学经典著作].Addison.Wesley.Modern.C...Design-.Generic.Programming.and.Design.Patterns.Applied.pdf

Modern+C++ Design Generic Programming and Design Patterns

Modern C++ Design Generic Programming and Design Patterns.rar

Modern C++ Design Generic Programming and Design Patterns Applied.pdf

Modern C++ Design Generic Programming and Design Patterns Applied.rar

Modern C++ Design Generic Programming and Design Patterns Applied epub

Modern C++ Design - Generic Programming and Design Patterns Applied

最新资源