关键的“构建”决策
阅读了第四章之后，收获很多，具体内容如下：
在真正构建之前，需要进行一些决策，首先是要选择语言，这貌似是一个难题，而且很有争议，其实对于具体程序员来说却不是一个问题，你几乎没啥选择权，老 板让你用啥你就用啥吧，对新手来说，你会什么就找什么样的工作就是了，对于老手来说，公司要决定换一种语言开发，你就学习学习，换呗，难道你还换个工作？ 如果你的职位需要你对编程语言做出选择，每种语言都是有他自己的优势和适用范围，我想应该不会有人用javascript写驱动程序，用汇编语言做网页 吧。当然除了个人喜好和信仰外，对语言的选择还需要考虑员工的熟悉程度，是否容易招到人等因素。
明确你在技术浪潮中的位置，要深入一门语言去编程，而不是限制在一门语言上去编程。这一节是说在软件发展的前期阶段，编译器，开发工具，周边辅助系统都 很原始，且有BUG，编程的参考文档也不全面，程序员需要为这些问题花费很多时间，而现在大多数语言，工具都已成熟，程序员可以更专注于实现软件本身的功 能，如果你用的这门语言有一些限制，或者少一些你需要的特性，不要受制于它，而是想办法利用一些约定或者自己开发一些类库来支持你的需求。
一个理想的设计的特征
这一章我主要了解了一个理想设计的特征，书中是这样说的：
一个理想的设计的特征是怎样的呢？ 他们有一些共同的特征，这里罗列里一些，虽然都是一个一个的点，但你可以以此针对你做出的设计一一对照一下。
1）最小的复杂度：你的设计得很容易看懂，很清晰明了，而不是自作聪明的用一些高深的东西。
2）易于维护：你的设计是自说明的，一目了然的，不需要太多的解释，让别人看到你的设计后很少会问你一些问题。
3）松散耦合：模块间的关联很少，这样可以减少集成，测试和维护的工作量，应用合理的抽象，封装，信息隐藏等做到松散耦合。
4）可扩展性：你的设计不是死的，在不大动底层结构的情况下，可以增加一些有可能增加的功能。
5）可重用性：如果做出一个通用模块，就可以在其它项目里重用了。
6）高扇入：第一次听这个词，就是一些少数的底层的工具类，会被上层大量的类使用。
7）低扇出：一个类使用其它类的数量尽量少，如果多的话，这个类就会很复杂。
8）可移植性：尽量避免用特定平台，特定语言的特性来进行设计，当然这个看具体情况。
可以工作的类
抽象数据类型定义
ADT(abstract data type)，是指一些数据以及对这些数据所进行的操作的集合。
使用ADT的益处：
1、 可以隐藏实现细节。
2、 改动不会影响到整个程序。
3、 让接口提供更多的信息。
4、 更容易提高性能。
5、 让程序的正确性更显而易见。
6、 让程序更具有自我说明性。
7、 无须在程序内部到处传递数据。
8、 你可以像在显示世界中那样操作实体，而不用在底层实现细节上操作他。
良好的类接口
定义类的时候，把public放在最前面，使用类的时候，一下就可以看到公共的方法。
1、 类的接口应展现一致的抽象层次。每一个类应该实现一个ADT，并且仅实现这个ADT。如果你发现一个类不止实现了一个ADT，或者不能确定究竟它实现了何种ADT，你就应该把这个类重新组织为一个或多个定义更加明确的ADT。
所谓层次一致，就是要所有的接口都是围绕ADT中的“data”来展开的。并且，要对实现的细节进行隐藏。
2、 一定要理解类实现的抽象是什么。
3、 提供成对的服务。大多数接口都有相应的，相等的，相反的操作。
4、 把不相关的信息转移到其他类中
5、 尽量让接口可编程，而不是表达语义。编程部分有接口中的数据类型和其他属性构成，编译器强制要求他们。语义部分则由“本接口将会怎样被使用”的假定组成，编译器无法强制检查，比如，接口A应该在接口B调用前调用，否则会引起崩溃；调用接口A前需要设置全局变量。等。断言可以将语义部分转换为编程部分？深入研究一下断言。
6、 谨防在修改时破坏接口的抽象。流程编辑中的Node类现在有点杂乱了。
7、 不要添加与接口抽象不一致的公用成员，每次向类中的接口中添加子程序时，问问“这个子程序与现有接口提供的抽象一致吗？”，如果不一致，该如何解决？我遇到过类似的问题，可以参考一下设计模式
8、 同时考虑内聚性和抽象性。
良好的封装
“设计精良的模块和设计糟糕的模块的唯一最大区别，就是对其他模块隐藏本模块内部数据和其他实现细节的程度。”——Joshua Bloch。
封装是比抽象更强的一个概念。抽象通过让你忽略实现细节的模型来管理复杂度，而封装则强制阻止你看到细节