对象揭秘[LanJoyner]--第三章 模块与导入

 

 

 

    大致扫了下第3章,模块与导入。写作风格大致是LanJoyner批判C++的某些不是，然后以Java,Eiffel的在这方面的优势来比较论述的。作为程序员。从我的观点出发，这一章是写的非常客观的。我大致有2年的C++开发经验和2年的Java开发经验。而且是不断切换（而不是中间断层）这两种技术解决工作上的问题的。所以深有感触。虽然项目不大，但是在"模块"这个特性上，C++要逊于Java的。

     但我个人认为,Stroustrup博士(C++发明者)在当时有大量的问题处理。而且本来就是踩着C的肩膀往上走的。在当时那个环境下，需要优先处理的关于语言的特性中，#include可能是放在最后，或者根本不予考虑的。而且本身要兼容C,所以在有用C的#include机制这个武器上，可能本身就没有认为有什么不对。而且我个人认为，因为Java,Eiffel的"模块"处理技术更完善（对于程序员来讲更轻松）才凸显出C++"模块"特性的不足。

    对于C++"模块"的缺点是:(我粗粗看了这一章，归纳出下面几点，估计还有其他)

       1 #include 机制的主要问题是它建立了递进依赖关系.(<<对象揭秘>>中文版P70)

                  猪头---->递进依赖关系的大体含义就是没有使用某实体还会被被某实体影响。

                  如果A包含于B,B包含于C,C包含于D,那如果A改变了D一定需要重新编译吗？

                  在C++里回答是"是",在Java,Eiffel回答是"否",(Java偶确定，Eiffel偶不熟悉:))

     2 C++的头文件机制并没有彻底实现接口与实现的分离(内联和私有成员的作怪)

                猪头---->LanJoyner的看法,如果私有成员本身需要隐藏的东西，子类和其他类

               都不可见,那为什么要给其他类的使用者能看到这个东西。（难道是考虑友元的

              需要？）

    3 （个人认为）C++的#include 机制额外地的增加了集成开发环境编写一些有助于提高编码效率

    的工具的复杂度(eclipse的CDT)。

LanJoyner写的比较精彩的几处地方(猪头个人认为):

1 接口与实现必须分离。我同意模块的用户只应该看接口.但是,C++这点上做的好吗?答案是否定的,至少有两个理由。首先,如果你要利用内联函数的潜能,你就必须讲实现放在头文件中.其次,类的定义包含了一个私有区域,这个私有区域把类的私有实现细节暴露给了用户。C++鼓吹讲接口和实现分离,可是在这一支持上却做的很差.(LanJoyner写的真是一针见血)

2  在构造任何系统时要考虑的基本问题是:如何将系统细分为模块,这些模块讲如何交互,如何访问彼此的信息，获得彼此的服务。你不仅必须考虑这个问题(问题分析),还必须决定这些新的模块将如何从已有模块的基础上创建（问题综合）。综合为我们提供了一些有趣的问题。因为你试图整合进一个系统的模块之间可能会有冲突。所以,我们需要一种"模块演算法"来为程序员提供必要的工具。本章将着眼于本书所讨论的编程语言如何看待模块。

3 这是因为C/UNIX的风格:在分开的模块中编程，不做或只做很少的全局分析。