C++CommonKnowledge:EssentialIntermediateProgramming资源-CSDN文库

4星 · 超过85%的资源需积分: 9 65 浏览量 2011-05-31 14:46:39 上传评论收藏 1.38MB PDF 举报

资源详情

资源评论

资源推荐

Item 1. Data Abstraction

A ―type‖ is a set of operations, and an ―abstract data type‖ is a set of operations

with an implementation. When we identify objects in a problem domain, the first

question we should ask about them is, ―What can I do with this object?‖ not

―How is this object implemented?‖ Therefore, if a natural description of a

problem involves employees, contracts, and payroll records, then the

programming language used to solve the problem should contain Employee,

Contract, and PayrollRecord types. This allows an efficient, two-way

translation between the problem domain and the solution domain, and software

written this way has less ―translation noise‖ and is simpler and more correct.

In a general-purpose programming language like C++, we don’t have

application-specific types like Employee. Instead, we have something better:

the language facilities to create sophisticated abstract data types. The purpose

of an abstract data type is, essentially, to extend the programming language

into a particular problem domain.

No universally accepted procedure exists for designing abstract data types in

C++. This aspect of programming still has its share of inspiration and artistry,

but most successful approaches follow a set of similar steps.

Choose a descriptive name for the type. If you have trouble choosing a name for the

type, you don’t know enough about what you want to implement. Go think some

more. An abstract data type should represent a single, well-defined concept, and

the name for that concept should be obvious.

List the operations that the type can perform. An abstract data type is defined by

what you can do with it. Remember initialization (constructors), cleanup

(destructor), copying (copy operations), and conversions (nonexplicit

single-argument constructors and conversion operators). Never, ever, simply

provide a bunch of get/set operations on the data members of the implementation.

That’s not data abstraction; that’s laziness and lack of imagination.

Design an interface for the type. The type should be, as Scott Meyers tells us, ―easy

to use correctly and hard to use incorrectly.‖ An abstract data type extends the

language; do proper language design. Put yourself in the place of the user of your

type, and write some code with your interface. Proper interface design is as much a

question of psychology and empathy as technical prowess.

Implement the type. Don’t let the implementation affect the interface of the type.

Implement the contract promised by the type’s interface. Remember that the

implementations of most abstract data types will change much more frequently than

their interfaces.

This makes sense. (It’s surprising how much of advanced object-oriented

programming is basic common sense surrounded by impenetrable syntax.) If I

were to ask you, ―What’s the present value of that American option?‖ I’d expect

to receive the same answer if I’d phrased my question as, ―What’s the present

value of that option?‖

The same reasoning applies, of course, to an object’s nonvirtual functions:

b->update(); // if this calls Option::update...

d->update(); // ...so should this!

The contract provided by the base class is what allows the ―polymorphic‖ code

written to the base class interface to work with specific options while promoting

healthful ignorance of their existence. In other words, the polymorphic code

may be manipulating AmOption and EurOption objects, but as far as it’s

concerned they’re all just Options. Various concrete Option types can be added

and removed without affecting the generic code that is aware only of the Option

base class. If an AsianOption shows up at some point, the polymorphic code

that knows only about Options will be able to manipulate it in blissful ignorance

of its specific type, and if it should later disappear, it won’t be missed.

By the same token, concrete option types such as AmOption and EurOption

need to be aware only of the base classes whose contracts they implement and

are independent of changes to the generic code. In principle, the base class can

be ignorant of everything but itself. From a practical perspective, the design of

its interface will take into account the requirements of its anticipated users, and

it should be designed in such a way that derived classes can easily deduce and

implement its contract (see Template Method [22, 77]). However, a base

class should have no specific knowledge of any of the classes derived from it,

because such knowledge inevitably makes it difficult to add or remove derived

classes in the hierarchy.

In object-oriented design, as in life, ignorance is bliss (see also Virtual

Constructors and Prototype [29, 99] and Factory Method [30, 103]).

Item 3. Design Patterns

Anyone who is not already familiar with design patterns may, after a brief

survey of the field, come away with the impression that design patterns are a lot

of marketing hype, are just some simple coding techniques, or are the

playthings of computer scientists who really should get out more. While each of

these impressions carries a grain of truth, design patterns are an essential

component of the professional C++ programmer’s toolkit.

A ―design pattern‖ is a recurring architectural theme that provides a solution to

a common design problem within a particular context and describes the

consequences of this solution. A design pattern is more than a simple

description of a technique; it’s a named capsule of design wisdom gleaned from

successful existing practice, written in such a way that it can be easily

communicated and reused. Patterns are about programmer to programmer

communication.

From a practical perspective, design patterns have two important properties.

First, they describe proven, successful design techniques that can be

customized in a context-dependent way to new design situations. Second, and

perhaps more important, mentioning the application of a particular pattern

serves to document not only the technique that is applied but also the reasons

for its application and the effect of having applied it.

This sort of thing is nothing new. Consider an analogy from the field of

algorithms. (Algorithms are not design patterns, and they’re not ―code patterns.‖

They’re algorithms, and this is an analogy.) Consider the following statement

that I might make to a colleague: ―I have an unsorted sequence that I have to

search a number of times. Therefore, I’m going to quick sort it and use binary

search to perform each lookup.‖ The ability to use the terms ―quick sort‖ and

―binary search‖ is of inestimable value not only in design but also in

communicating that design to an educated colleague. When I say ―quick sort,‖

my colleague knows that the sequence I’m sorting is in a random access

structure, that it will probably be sorted within O(nlg

n) time, and that the

elements in the sequence may be compared with a less-than-like operator.

When I say ―binary search,‖ my colleague knows (even if I hadn’t earlier

mentioned ―quick sort‖) that the sequence is sorted, that I will locate the item of

interest within O(lg

n) comparisons, and that an appropriate operation is

available to compare sequence elements. Shared knowledge of, and a standard

vocabulary for, standard algorithms permits not only efficient documentation

but also efficient criticism. For example, if I planned to perform this search and

sort procedure on a singly linked list structure, my colleague would immediately

smirk and point out that I couldn’t use quick sort and probably wouldn’t want to

use binary search.

Until the advent of design patterns, we missed these advantages in

documentation, communication, and efficient smirking with our object-oriented

designs. We were forced into low-level descriptions of our designs, with all the

inefficiency and imprecision that entails. It’s not that techniques for

sophisticated object-oriented design didn’t exist; it’s that the techniques were

not readily available to the entire programming community under a shared,

common terminology. Design patterns address that problem, and we can now

describe object-oriented designs as efficiently and unambiguously as

algorithmic designs.

For example, when we see that the Bridge pattern has been applied to a design,

we know that at a simple mechanical level an abstract data type implementation

剩余152页未读，继续阅读

wwf5067

2015-01-09

豆瓣上说不错，下下来看看原版如何

评论收藏

内容反馈

louisla

粉丝: 7
资源: 1

C++ Common Knowledge : Essential Intermediate Programming

评论2

最新资源

C++ Common Knowledge : Essential Intermediate Programming

评论2

C++ Common Knowledge Essential Intermediate Programming epub

C++.Common.Knowledge (C++必知必会 中文版)

C++ Common Knowledge Essential Intermediate Programming 无水印pdf

游戏程序员需要读哪些书

C++.Common.Knowledge.Essential.Intermediate.Programming

Intermediate C++ programming.rar

Prentice.Hall.Rapid.GUI.Programming.with.Python.and.Qt.the.definitive.guide.to.PyQt.programming.2008.pdf

Game programming in c++

年度最经典C++教程10本打包下载

2005年度最经典C++教程8本

RxSwift: Reactive Programming with Swift, 2nd Edition

Programming Languages Lecture Notes (Washington CSE341)

C++ Crash Course- A Fast-Paced Introduction 2019.rar

下载 Intermediate iOS 11 Programming with Swift by AppCoda

Advanced R：中级和高级R程序员的基本参考Advanced R: An Essential Reference for Intermediate and Advanced R Programmers

Addison.Wesley.C++.Template.Metaprogramming.LiB.chm

Programming Games with Visual C#(15th) epub

Intermediate.iOS.Programming.with.Swift.iOS.10.and.Swift.3

C/C++ GUI Programming with Qt4 (S - Jasmin Blanchette),pdf

win10环境下vscode运行opencv(C++)(解压即用)-1号包

虹软3.0人脸识别客户端（追踪，活体检测，人脸特征存储，人脸识别，人脸注册，人脸匹配）可离线断网部署 5000个免费key/年

c++入门，核心，提高讲义笔记

仿照Visionmaster，用C++、Qt编写的视觉软件

C++STL库常用库函数总结

c++小游戏 c++小游戏

mingw-w64-install.exe

C/C++中文帮助文档

我的世界简易版（C++编写，源代码+程序）

最新资源

C++.Common.Knowledge (C++必知必会中文版)