OO_JAVA_四个单元的总结

总结本单元两次作业的架构设计

设计目标

尽量减少特殊容器的存在，能通用就通用，减少重复的类同代码。

基础容器的存在，就是为上述目标而服务的。

设计概要

底层：基础的、类型无关、无依赖的容器以及对应的查询方法
中间层：用来存所有的parent和association映射关系及对应的查询方法
顶层：基于底层容器和中间层容器的业务逻辑处理方法

基础层

    private Map<String, UmlElement> elementMap;
    private MultiValueMap<ElementType, UmlElement> typeMap;
    private DuoMap<String, ElementType, UmlElement> nameMap;
    private DuoMap<String, ElementType, UmlElement> parentIdMap;

总结自己在四个单元中架构设计及OO方法理解的演进

原则

简洁：思路到代码都要简洁。
解耦：能提取的共性统统提取。

演进过程

所谓演进，就是上述原则理解的不断深化，和实际运用的不断深化。

第一单元：表达式：继承与CAST

设计要求

处理表达式的输入输出，以及对表达式求导。

提取共性

无论数字、加号、乘号、减号、指数符号、sin函数、cos函数，都可以称之为函数，都是由函数本身，以及参数构造而成，形成一种树形结构，即表达式树。

对其一视同仁可以完成非常简化的设计架构，所有的函数，这里叫他函子。

共性

树或者说函子（某些）可以具有子树即子函子
对树或者说函子可以求导，求其导函数
对树或者说函子（某些）可以反科里化，将嵌套的同函子表达式展平
对数或者说函子（某些）可以合并同类项，比如数字相加可以合并

第二单元：多线程：层次分离

分离处理层次

分离层次的目的是为了每一部分都足够的简单，而且相互解离，可以独立或者一步步的设计构建，减轻脑力负担。

层次

顶层调度层，负责把乘客请求分配给电梯
电梯调度层，负责把乘客请求转化成电梯运行指令
电梯执行层，负责运行电梯运行指令

第三单元：JML规格：stream的运用

从第一单元接触到stream，学习运用，到第三单元，stream的运用已经在我的代码里处处都是，可以减小代码的复杂度。

第四单元：UML：容器的设计

从简洁、通用的角度出发，不应该为每一种UML元素的关系结构都设置对应的类或容器进行存储与获取

在这些元素与元素之间有很多关系直接从元素本身就可以构建得到，也即我所使用的4个类型无关Map，通过这4个Map，我的代码中没有大量的存储容器，这就是共性的效果。

总结自己在四个单元中测试理解与实践的演进

所谓面对对象，就是在抽离类似对象之间的共性，以这些共性组织代码，提升代码的抽象程度，减轻编写的体力劳动。

在编写代码时，疏漏不可避免，这时就体现出分层与解离的好处了，当你的代码分离的层次清晰时，就可以快速地定位到发生错误的所在，这也是OO课程中我努力趋向的目标。

从来自c语言、数据结构课程的单纯通过输入输出数据来约束代码的正确性，我又学到了单元测试这一利器，以及为了解决正确性问题而发明的JML形式验证语言，这些都是约束程序的正确性的办法。

总结自己的课程收获

我OO的历程，就是不断地提升自己的解耦代码的能力，即提取共性的能力，第二单元时我觉得第一单元用接口以及实现接口可以写的复杂度降低一些，现在我回过头看我第一单元的代码，我发现，有很多操作都可以进一步提取共性，简化代码，这就是进步，不断地掌握抽象的思维方法。

每一个单元，每一次project，最重要的是进步，所谓收获，也就是从一次次的作业中，体会到的自己的思路、设计的进步。

立足于自己的体会给课程提三个具体改进建议

第一单元
- 第一单元的难度可以适当的降低，降低的方法可以是提供官方的架构，然后让学生填写实现即可，比如表达式的求导，可以设置如下简易结构（四个接口）：
```
public interface Differentiable {
    Differentiable derivate();
}
public interface Recursive extends Differentiable {
    Collection<Differentiable> getChildren();
}
public interface Mergeable extends Recursive {
    Differentiable merge();
}
public interface Coryled extends Recursive {
    Differentiable uncoryled();
}
```
  然后给出表达式项的模板(一种项的例子，省略初始化和构造)：
```
public class Plus implements Differentiable, Recursive, Mergeable, Coryled {
    private List<Differentiable> children;
    @Override
    public Collection<Differentiable> getChildren() {
        return children;
    }
    @Override
    public Differentiable derivate() {
        Plus plus = new Plus();
        for (Differentiable diff : getChildren) {
            plus.addChild(diff.derivate());
        }
        return plus;
    }
    @Override
    public Differentiable uncoryled() {
        return this; // TO BE IMPLEMENTED
    }
    @Override
    public Differentiable merge() {
        return this; // TO BE IMPLEMENTED
    }
    public void addChild(Differentiable diff) {
        children.add(diff);
    }
}
```
  设置结构与模板的目的，是为了学生易于掌握面对对象的内涵，并快速地理解Java里的类的继承和接口的实现。
  
  面对对象，即解离出对象与对象之间的共性，上面四个接口，就是表达式项的四种特性：
  1. 可导：每一项都是可导的，所以其他特性接口都继承自该特性接口
  2. 递归：有些项具有子项，比如加法项，其子项即两个相加的项，求导时需要进行一些类似递归的操作
  3. 可合并：有些具有子项的项，比如加法项，其子项可以合并同类项，比如1+2可以转化成3
  4. 可反科里化：嵌套的同种类项，可以解除嵌套，比如1+(1+2)可以转化成1+1+2
  而且，第一单元夹杂的输入处理部分，比重和难度较大，可以予以改良，比如像上述框架一般，也提供类似的框架。
  
  对于大多数学生来说，刚刚学习面对对象的思维，既然在对面对对象一无所知的情况下大家写出的代码都是面向过程，不如官方提供一个或数个框架，让学生按图索骥，照猫画虎，这样，既减轻了第一单元的课业难度，又让学生友好的接触这一门课程，何乐而不为？
评分：单元测试

首先，像JML和UML这样的单元，评分的方式和标准是否可以改变呢？

因为这两个单元我们写代码，都是按照官方的接口来实现，那么评分是否可以按照单元测试来给分呢，这样也一定工程的需要，锻炼大家测试的能力。
评价：架构考察

然后就是架构的考察，一个学期，如此多的project，我觉得，这个课程，学生最应该提升的能力，就是一定程度上，驾驭复杂架构的能力，而伴随课程推进的，应该是学生的进步，对这一方面能力的进步与否，也应予以考察。