当时看到书名《大规模C++程序设计》感觉好厉害的样子，毫不犹豫下单了，一年之后我翻开它，如果不写点东西就对不起这本书了，不对，对不起我自己了，整本书有点抽象，加上我经验尚浅，头悬梁锥刺股都无法阻挡我进入梦乡……
在工作中很多人开发人员都会遇到：对于公司的很多年的产品，每次添加新功能，或者调整一点点架构其实都是一次不小的变动，以至于有些程序员一写代码就开始暴躁起来，就像坐我旁边的这位同志，每天一写代码就给我说想打人，除了给他一个白眼我能怎么办，所以对于大型项目一开始的架构就显得非常重要。封装性，继承性，以及可扩展性
大型项目中经常会碰到的问题：
1.循环依赖
2.过度的链接时依赖
3.过度编译时依赖
4.冲突的全局名字空间
5.不可重用
6.物理设计或者逻辑设计缺陷
7.软件质量不高（可靠性，可维护性，可用性，性能）
8.没有质量保证，很多公司都是用户级的测试，底层的可靠性都是靠程序员来保持的
作者给出了一些基本规则，物理设计以及逻辑设计上的一些建议
基本规则：
1.数据成员应该封装，不要暴露给用户
2.少用全局变量，用私有静态成员变量代替
3.用静态成员函数代替一些全局函数
4.enum,typdef以及全局常量数据也会造成全局名称冲突，尽量加上作用域
5.头文件中要防止重复包含
物理设计以及逻辑设计这两大部分是重点，物理设计和逻辑设计有时候也是分不开的，所以在这本书中，物理设计更像是从宏观上来看这些设计，像组件，层次化，封装隔离以及包。而逻辑设计更像是代码架构上的一些建议，比如函数设计，对象实现等。
书中对两者的区别的观点是：逻辑设计只解决体系结构问题，物理设计解决组织问题。
物理设计
不得不说物理设计这几章真的是既抽象又枯燥，既抽象又枯燥。
组件：
现在很多人都把模块化组件化挂嘴边，不明觉厉
什么是组件？
组件是物理设计的最小单位，本书强调了，组件不是类，组件通常定义了一个或者多个密切相关的类，通常由一个.h，一个.c组成。
1.一个组件常常把跨越许多实体的大量易管理的内聚功能打包到单一的物理单元中
2.一个组件不仅作为单一的实体捕获整个抽象，而且允许考虑不通过类级别的设计来解决物理问题
3.一个适当的组件设计可以作为一个单元提取出来，不需要重写任何代码就可以在另一个系统重用
层次化，隔离技术这些概念划分在大型项目中非常复杂，先掠过好了。。。。
逻辑设计
逻辑设计这部分其实比较重要，收获还是比较大的
其中的重点：
1.在可能的情况下延缓不必要的功能的实现可以降低开发和维护成本，并且避免过早的实施精确的接口设计和行为设计。
2.努力使函数集最小化
3.通过参数返回，可以在保持整体封装的同时提高性能（其实不太理解）
例子：
//部分封装接口
class geom_PointArray
{
public:
geom_Point& operator[] (int index);
const geom_Point& operator[](int index) const;
};
//完全封装接口
class geom_PointArray
{
public:
geom_Point point(int index) const;
void setPoint(const geom_Point& array, int index);
};
//不完全封装
class geom_PointArray
{
public:
void getPoint(geom_Point* returnValue, int index) const;
void setPoint(const geom_Point& point, int index);
};4.不要通过值来传递用户自定义类型（类，结构体，联合体等）给函数
5.不要试图删除一个通过引用传递的对象
6.在声明虚函数的类或其派生类中，把析构函数显示的声明为类中的第一个虚函数
7.类的初始化列表避免依赖其数据成员的的定义顺序
8.多用const
9.少用完全封装有的时候是正确的选择
10.可读性大于易用性
11.合适封装隔离
and so on....