大规模C++程序设计
出版社:中国电力出版社
出版日期:2003.9
ISBN:9787508315041
作者:John Lakos
页数:624页
作者简介
在本书中，Lakos介绍了将大型系统分解成较小且较好管理的组件层次结构（不是继承）的过程。这种具有非循环物理依赖的系统的维护、测试和重用从根本上比相互紧密依赖的系统更容易且更经济。此外，本书还说明了遵从好的物理设计和逻辑设计规划的动机。Lakos给读者提供了一系列用来消除循环依赖、编译时依赖和连接时（物理）依赖的特殊技术。
书籍目录
前言
译者序
第0章 引言
第1部分 基础知识
第1章 预备知识
第2章 基本规则
第2部分 物理设计概念
第3章 组件
第4章 物理层次结构
第5章 层次化
第6章 绝缘
第7章 包
第3部分 逻辑设计问题
第8章 构建一个组件
第9章 设计一个函数
第10章 实现一个对象
附录A 协议层次结构设计模式
附录B 实现一个与ANSI C兼容的C++接口
附录C 一个依赖提取器/分析器包
参考文献
内容概要
John Lakos在Mentor Graphics公司工作。该公司编写的大规模C++程序比大多数其他公司要多，并且是首先尝试真正的大规模C++项目的公司之一。Lakos从1987年起就一直使用C++进行专业编程，并于1990年在哥哥伦比亚大学开设了面向对象编程方面的研究生课程。
发布书评
精彩书评 (总计12条)
-
本书的写作背景比较特殊，面向的人群比较狭窄。满足以下条件，你可以好好看看这本书：1 在某个软件中，必须使用C++作为软件开发的主要语言。2 软件的代码规模在100万以上。也就是要有一百万以上的C++代码。有这两个条件，你就会发现书里面说的很有用。如果你觉得看不懂，觉得书里介绍的问题和解决方案，莫名其妙，很想拍转，那说明这本书不适合你，你还是别看了。 -
这两天，要改动1个基础的类型。之前参考书里的方法画了package之间的依赖图。这下方便了，顺着依赖图指示，从依赖关系少的底层包开始重构编译，逐次推进到顶层包，最后整个程序一次性编译通过。package依赖图的好处还不止于此：1，可以指出相互依赖的不合理现象。2，新增模块时，考虑对依赖图的影响，便于保持程序结构的稳定和简洁。3，有了程序的全局俯视图，平时可以做更多的调整和优化。-------------------------------------------------------之前，和大侠讨论说，如果有工具能把依赖关系细化到模块就好了。这段实践下来，应该没有这个必要。有个包里的模块关系有点搞，特别为这个包画个模块依赖图就够了。 -
其实lakos这本书讲述的问题很简单，就是包设计原则，这些原则跟OCP、DIP一样，在敏捷软件开发中都论述过，当然不是每个人都看懂了这些后面的原则；但是，在C++语言中，你找不到包这个抽象概念所对应的东西，而且C++的链接过程有太多初学者没有弄明白的内容，而恰恰是这些内容破坏了文件的物理组织，加上大多数未经训练的软件开发者都没有将文件、目录当作包组织的概念，造成了大多数项目工程中代码组织的混乱，也许他们是好运的，没有遇上lakos它们那样，一个版本要编译一周的厄运；其实lakos是想在这本书上提出一套规范，大家按照这套规范来设计具有良好物理组织的大规模C++软件，这曾经是老B为了兼容C的同时赋予自由散漫C++程序员的自由，但这些自由却成了C++程序员的噩梦；稍后在C++基础之上改进的语言中，无不悄悄的加上了物理设计的限制，例如java中：1、一个类只能放在一个源文件中，而不能像C++那样区分.h和.cpp，要是.h和.cpp的文件名还不一样怎么办，天哪。。。2、一个.java只能有一个public class，这样的要求强制开发者去严肃对待源文件的物理组织，这个物理单元提供的接口是什么？哪些作为实现？；3、没有了extern这样的链接指示符，避免了C++中两个毫无关系的obj，莫名的在链接时刻产生了依赖，java中一个import关键字的轻易搞定的依赖声明，在C++中lakos却要先保证.h/.cpp同名，然后还要禁止掉extern声明，他的idep工具才能正常工作，要是再遇到#include后面的大小写有区别。。。idep也不干活了。。。整本书下来,lakos除了苦口婆心的告诉大家依赖危害性，如何建立起一套规范从物理上来改善依赖，如何从逻辑设计上避免引入依赖，最后的最后还给了一套用来分析依赖、度量依赖和检测循环依赖的idep工具集。可惜的是，如此工程界大师的作品，却没人关注……
精彩短评 (总计25条)
-
凡是说这本书垃圾的人，都是做的小项目。对他们来说，这都是奇巧淫技。主题是绝缘 -
没能看完…… -
浏览一遍先 -
cpp不适合大规模项目呢 -
很有干货，很有启迪的一本C++程序开发方面的好书。 -
蜗居中小贝看的书 -
看完这本书你就会明白c++的纠结与失败。一个现代程序设计语言不应该让程序员考虑如此庞杂的细节。 -
不管他有用没用，先看了再说 -
翻的很不通顺 有些概念有些过时 但很多还是很有用 -
看明白的东西不多, 只对书中关于程序复杂度评定的几个图有些印象. -
帮助不大
-
学习小贝 -
对于大型系统构建讲的非常到位！ -
这本书更多的是对 C++ 的友好批判。很适合 C++ 中毒的程序员读。
-
翻译真的是很不到位，不建议买中文版。虽然书中知识的应用领域很局限，不过经验很宝贵，值得一看的。 -
非常好的书，大规模程序设计涉及到不少不常关注的问题，书里做了很好的介绍 -
深入分析c++文件的结构，布局及设计结构 -
忘了讲什么的了 -
只能说泛读过这本书，自刚刚翻这本书时候起，就想着哪天我要是当了系统架构师了，而且手头有着大项目，我再来复习这本书，那是再好不过了 ！ -
大规模项目中的C++,时代久远，难免有些观点过时。翻译有些不靠谱... -
观念有点老了，还有些翻译问题。 -
看来自己开发c++的经验的确不足，看着有些吃力，虽然在很多地方也能明白作者的意图。
看这本书的初步感觉就是，c++由于天生的一些局限，导致编译和链接阶段的大量问题；这些问题的解决办法有和oo的模式有冲突。
要全面掌握C++，真不是件容易的事情 -
2006年的时候，我们开发了一个比较大的系统，开发参与人数有十几个（其实也不错），在但是的机器情况下，有时候只是动了一个头文件，会导致很长的编译时间，在这本书中可以找到答案。
《大规模C++程序设计》这本书是在2006年开发完一个相对较大的系统后读的一本书，当时看完，是少有的让我看完觉得相见恨晚的书，书分两部分内容，C++的逻辑设计和物理设计，这本书写的很早，95年左右，所以很多逻辑设计的原则在后来都在很多其它书中出现，但是物理设计其他书很少涉及，但是物理设计在大规模程序设计（平台开发）、接口设计和模块解耦上有非常重要的左右，现在很多概念上可能将之称为部署方式，随便提一句，翻译上有些是不怎么好，但基本上不影响阅读。推荐给每一位C++开发者。 -
有帮助 -
很久没接触C++了，已经有点忘了当年看这本书时的感受