附录B编程准则.PDFVIP

下载 附录B 编 程 准 则 这个附录 [1] 收集了C + +编程的一些建议，它们是我在教学和实践过程中收集而成的，当然 还有： 从朋友那儿得到的忠告，包括 Dan Saks （与Tom Plum 合写了“ C++ Programming G u i d e l i n e s ”，Plum Hall 1991 ）、Scott Meyers( “E ffective C++ ”一书的作者， A d d i s o n - We s l e y, 1 9 9 2 )和Rob Murray （“C++ strategies Ta c t i c s ”的作者，A d d i s i o n - We s l e y, 1 9 9 3 ），有许 多条目都是从这本书上摘录下来的。 1. 不要用C + +主动重写我们已有的C代码，除非我们需要对它的功能做较大的调整，（也就 是说，不破不立）。用C + +重新编译是很有价值的，因为这可以发现隐藏的错误。把一段运行 得很好的C代码用C + +重写可能是在浪费时间，除非 C + + 的版本以类的形式提供许多重用的机 会。 2. 要区别类的创建者和类的使用者（客户程序员）。类的使用者才是“顾客”，他们并不需 要或许也不想知道类的内部是怎样运作的。类的创建者必须是设计类和编写类的专家，以使得 被创建的类可以被最没有经验的程序员使用，而且在应用程序中工作良好。库只是在透明的情 况下才会容易使用。 3. 当我们创建一个类时，要尽可能用有意义的名字来命名类。我们的目标应该是使用户接 口要领简单。可以用函数重载和缺省参数来创建一个清楚、易用的接口。 4. 数据隐藏允许我们（类的创建者）将来在不破坏用户代码（代码使用了该类）的情况下 随心所欲地修改代码。为实现这一点，应把对象的成员尽可能定义为 private, 而只让接口部分 为p u b l i c ，而且总是使用函数而不是数据。只有在迫不得已时才让数据为 p u b l i c 。如果类的使 用者不需要调用某个函数，就让这个函数成为 p r i v a t e 。如果类的一部分要让派生类可见，就定 义成p r o t e c t e d ，并提供一个函数接口而不是直接暴露数据，这样，实现部分的改变将对派生类 产生最小的影响。 5. 不要陷入分析瘫痪之中。有些东西只有在编程时才能学到并使各种系统正常。 C + +有内 建的防火墙，让它们为我们服务。在类或一组类中的错误不会破坏整个系统的完整性。 6. 我们的分析和设计至少要在系统中创建类、它们的公共接口、它们与其他类的关系、特 殊的基类。如果我们的方法产生的东西比这些更多，就应当问问自己，是不是所有的成分在程 序的整个生命期中都是有价值的，如果不是，将会增加我们对它们的维护开销。开发小组的人 都认为不应该维护对他们的产品没有用的东西。许多设计方法并不大奏效，这是事实。 7. 记住软件工程的基本原则：所有的问题都可以通过引进一个额外的间接层来简化 (Andrew Koenig 向我解释了这一点）。这是抽象方法的基础，而抽象是面向对象编程的首要 特征。 8. 使类尽可能地原子化。也就是每个类有一个单一、清楚的目的。如果我们的类或我们设 计的系统过于复杂，就应当将所有复杂的类分解成多个简单的类。 9. 从设计的角度，寻找并区分那些变化和不变的成分。也就是在系统中寻找那些修改时不 [1] 增加这个附录是Andrew Binstock建议的，他是《Unix Review 》的主编，兼撰稿人。 410 C + +编程思想 下载 需要重新设计的成分，把它们封装到一个类中。 10. 注意不同点。两个语义上不同的对象可能有同样的操作或反应，自然就会试着把一个 作为另一个的子类以便利用继承性的好处。这就叫差异，但并没有充分的理由来强制这种并不 存在的父子关系。一个好的解决办法是产生一个共同的父类：它包含两个子类——这可能要多 占一点空间，但我们可以从继承中获益，并且可能对这种自然语言的解有一个重要发现。 11. 注意在继承过程中的限制。最清晰的设计是向被继承者加入新的功能，而如果在继承 过程删除了原有功能，而不是加入新功能，那这个设计就值得怀疑了。但这也不是