The GNU C++ library
The GNU C++ library
复制标题
DOI：
--
复制
发表时间：
1996-05
影响因子：
3.8
通讯作者：
D. Lea
中科院分区：
文献类型：
--
作者：
D. Lea
数据类型和值虽然两者都可以被描述为C++类，但在复数和银行账户之间有很大的区别。例如，有一个庞大的、完善的复数数学理论，但基本上没有银行账户。一个结果是，开发一个Complex类要容易得多，它包含的特性可以合理地确定在广泛的应用程序中是有意义的。对于任何可以构造的BankAccount类来说，这都是不正确的。一个更重要的区别是由此产生的设计差异。复数的“理论”是围绕着复数的属性而不是对象。数学方法通常对具有（Re，Im）属性的对象的实际身份进行抽象，只处理值本身{无论哪个或多少个对象将这个量报告为真实的（）和imag（）属性函数，复数量（2.4，17.17）都保持不变。通过设计，许多操作不关心对象，而只是处理数量。然而，对于像BankAccount这样的类来说，这是一种失败的态度。例如，即使我们碰巧有相同的银行余额，一个特定的可识别的BankAccount实例属于你而不是我，这是一个明显但关键的设计问题。这些不同导致了设计相关类和实用程序的不同风格、方法和攻击计划。例如，虽然写一个接受两个复数并返回第三个代表它们之和的“构造性”函数是完全合理的，但几乎没有理由创建一个接受两个银行账户并返回第三个代表它们余额之和的函数。相反，BankAccount类包含诸如withdraw、transfer等方法，这些方法改变特定对象的状态。Libg++包含的Complex等组件比BankAccount等组件多得多。许多类维护“值语义”，其方式更类似于经典ADT方法，而不是经典OO方法。
Data Types and Values While both may be described as C++ classes, there is a big di erence between, say, a Complex number and, say, a BankAccount. For example, there is a large, well-established mathematical theory of complex numbers, but essentially none for bank accounts. One consequence is that it is simply much easier to develop a Complex class containing features that one may be reasonably certain will makes sense across a wide range of applications. This is much less true of any BankAccount class one could construct. A more important distinction underlies the resulting design di erences. The \theory" of complex numbers revolves around the properties of complex values, not objects. Mathematical approaches typically abstract over the actual identities of objects possessing (Re, Im) attributes, and just deal with the values themselves { the complex quantity (2.4, 17.17) remains the same regardless of which or how many objects report this quantity as real(), and imag() attribute functions. By design, many operations don't care about the objects, and just deal with the quantities. However, this would be a losing attitude for a class like BankAccount. For example, even when we happen to both have the same bank balance, the fact that a particular identi able BankAccount instance belongs to you and not me is an obvious but critical design issue. These di erences result in di erent styles, approaches, and plans of attack for designing the associated classes and utilities. For example, while it is perfectly sensible to write a \constructive" function that accepts two complex numbers and returns a third representing their sum, there is hardly ever a reason to create a function that accepts two bank accounts and returns a third representing (among other things) the sum of their balances. Instead, the BankAccount class contains methods such as withdraw, transfer, and so on that mutate the states of particular objects. Libg++ contains substantially more components like Complex than those like BankAccount. Many classes maintain \value semantics", in a manner more similar to classic ADT approaches than to classic OO approaches.