软件构造学习笔记

3.1 Data Type and Type Checking
1. 编程语言的数据类型

​ 在Java中，数据类型分为基本数据类型(int、boolean、char等)和对象数据类型(String、Integer等)。所有的基本数据类型都是Immutable的，而且在栈中分配内存，代价也比较低。而对象数据类型有的是Immutable的，有的是Mutable的，分配的内存都在堆中，代价相对昂贵。因此在能使用基本类型的情况下尽量使用基本数据类型，降低代价。

对象数据类型是OOP的核心，由于对象数据类型存在继承(extends)机制，因此在OOP中可以更好的复用代码。

基本类型被包装为对象类型，通常只有在定义集合的时候使用，其他情况下尽量避免使用。基本类型和对象类型之间一般可以自动转换。
2. 类型检查

静态类型语言(Java)可执行静态类型检查，在编译阶段进行类型检查，这意味着避免了将错误带入到运行阶段，可以提高程序的正确性/健壮性，例如语法错误、类名/函数名错误，参数类型或数目错误、返回值类型错误都可以在静态类型检查时发现；动态类型语言(python)只有动态类型检查，在运行阶段才会进行类型检查，例如非法的参数值 (最典型的NULL引用)、非法的返回值、越界等等。

静态类型检查是关于数据类型的检查，它不会关心具体的值，而动态类型检查是关于值的检查。

例如int n=1.1在静态类型检查的时候就会报错，但double a=0; double b=2/a;只有在运行之后，执行动态类型检查的时候才会报告除零错。
3. Mutability和Immutability

    改变变量：使变量指向存储着另一个值的空间

    改变变量的值：变量指向的空间不变，变化的是存储的内容。

Immutability：不变性，一个重要的设计原则，设计ADT时尽量保证这个原则。

Immutable types：不可变的数据类型，当实例对象被创建以后，该对象的值就不可变化了，也就是该ADT中不能有mutator方法。

在编写程序的时候使用final关键字可以保证该变量不可再被改变，但不能保证该变量的值不变。所以，尽量使用final变量作为方法的输入参数、作为局部变量。

3.2 Designing Specification
1. 为什么要写注释？

因为单靠代码自己无法把开发者的设计决策全部清晰直观地表现出来，如 final 关键字本身就是一种设计决策，开发者很容易理解，但这个的只要目的不是为了给人读，是为了给编译器读，如果未来程序员对这个部分做了什么改动，编译器可以很快的在静态代码分析中就能发现错误，避免错误带入后面的开发中，而只有注释，才能够让其他人清晰的看到这部分干了什么，甚至是怎么实现的等等信息。
2. 为什么要写spec？

spec是程序员自己对所写的方法的规约，它规定了方法应该做什么，不应该做什么，有了spec就可以编写测试用例了，因为程序员所编写的代码必定是符合spec的，否则就是不合格的，符合spec的代码也必然能通过根据spec所设计出的测试。同时，有了spec，客户端在使用所写的代码时就有所依据，客户端可以轻松的知道他需要为这个方法提供什么样的参数，以及会得到什么样的结果，而不必知道内部逻辑是怎么样的，大大节省了客户端使用自己的API时所需要的时间，并且大大降低了客户端对自己所编写的代码的误解。

而且，拥有精确的spec，有助于区分责任，很容易地就可以找到是哪一部分的代码出了问题。

最后，由于客户端并不需要了解内部的实现也就意味着你可以在满足spec的大前期下对实现方法进行任意的改动而不需要告知客户端，因为无论你怎么改，只要满足spec，在客户端看来，你的行为 (作用) 都是相同的。

    没有spec的代码就是垃圾！！！

3. spec的结构

    precondition前置条件：对客户端的约束，在使用方法时必须满足的条件
        使用@param annotation说明每个参数的前置条件
    postcondition后置条件：对开发者的约束，方法结束时必须满足的条件
        使用@return annotation说明后置条件
        使用@throws annotation说明出现异常的时候会发生什么
    在方法声明中使用static等关键字声明，可据此进行静态类型检查

当客户端满足前置条件的时候，结果必须满足后置条件；当前置条件不满足的时候，方法内部可以做任何事情，但作为开发者，应该尽量让程序做到fail fast。

spec不能有什么？

spec不能暴露实现细节，不应该暴露局部变量，也不应该暴露私有的数据域，这些东西一旦暴露，就有可能给被非法的程序员利用，发现漏洞并实施攻击。

注意：方法不应该改变输入参数的取值，如果改了，则必须在spec中做出说明。所以不推荐使用mutable的对象。另外，我们无法强迫类的实现体和客户端不保存可变变量的“别名”，因此，如果直接返回本来的mutable对象，客户端可能修改它的值造成内部实现的错误，同样，如果返回了的是原来mutable对象的拷贝，虽然内部不用再担心客户端的更改影响到自己，但客户端无法知道内部是否保留了被返回的拷贝的别名，因此双方无法完全的信任彼此，故而不推荐使用mutable类作为返回值类型。
4. spec的评判标准

    评判哪个规约更好的三个方面：规约的确定性、规约的陈述性、规约的强度

重点是规约的强度的判断，spec变强的要求是更宽松的前置条件+更严格的后置条件，在这种情况下，就可以用变强了的spec去替换原来的spec。越强的规约，意味着implementor的自由度和责任越重，而client的责任越轻。

    强的spec可以替换弱的spec，这一点会在第4章的LSP中得到应用

用椭圆表示spec的强度

如下图，大椭圆表示更弱的spec，小椭圆表示更强的spec，椭圆的大小表示的是开发者的自由度，小椭圆有更强的后置和更弱的前置，因此所包含的结果的点就少，所以就小。