C++设计模式与泛型编程实战

5星 · 超过95%的资源需积分: 9 190 浏览量更新于2024-07-27 1 收藏 2.14MB PDF 举报

“Modern C++ Design - Generic Programming and Design Patterns Applied”是Andrei Alexandrescu撰写的一本关于C++编程和设计模式的经典著作。该书由Addison Wesley出版社于2001年出版，ISBN为0-201-70431-5，共352页。在这本书中，Andrei Alexandrescu提出了一种强大的新方法——泛型编程（Generic Programming）和设计模式的结合，称为“泛型模式”或“模式模板”。这种方法为C++程序员提供了一种创建可扩展设计的新途径，它将模板和设计模式相结合，创造出以前可能无法想象的编程可能性。Herb Sutter高度推荐这本书，认为任何涉及C++设计和编码工作的人都应该阅读。书中的内容涵盖了许多C++的创新观点，正如John Vlissides在序言中指出的，关于C++还有很多未被充分探讨的领域。Andrei Alexandrescu通过其独特的创造力和编程技巧，为C++程序员开辟了新的视野。他引入了“泛型组件”的概念，这些是可重用的设计模板，能够为编译器生成样板代码，从而实现更表达性强、灵活度高且可复用性出色的代码。书中深入讨论了如何利用泛型编程来实现设计模式，这包括但不限于工厂模式、观察者模式、装饰器模式等。作者展示了如何使用模板元编程技术来创建自定义类型系统，以及如何利用C++的模板特性和STL（标准模板库）来实现高效和灵活的解决方案。此外，书中还探讨了类型安全、资源管理（如RAII原则）以及如何通过模板和设计模式来降低复杂性。通过阅读《Modern C++ Design》，读者将不仅能够学习到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页未读，继续阅读

qq910438219

粉丝: 68
资源: 169

C++设计模式与泛型编程实战

C++设计模式与泛型编程实践

C++设计模式：泛型编程与设计模式应用

现代C++设计：泛型编程与设计模式应用

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

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

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

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

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

最新资源