2023秋BUAA-OOpre·总结笔记

@Monterey

已于 2023-11-04 00:39:58 修改

阅读量96

点赞数 1

分类专栏： BUAA-OOpre 文章标签：笔记 java

于 2023-11-03 21:10:37 首次发布

本文链接：https://blog.csdn.net/X861314666/article/details/134209656

版权

BUAA-OOpre 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

2023秋BUAA-OOpre·总结笔记

OOpre课程的简单建议
代码架构分析
Jnuit使用心得
OOpre学习体会

OOpre课程的简单建议

经过这学期的学习，我收获颇丰，这门课程的开设于笔者而言很有意义。

笔者的建议是：

加大课程训练力度，可以考虑包括但不限于加强深入迭代、增加hack互测与博客作业形式、增加研讨课和实验课、引入上机比赛等等，达到全面模拟并提前熟悉OO正课节奏的效果

伟大的领袖毛泽东曾说：“不打无准备之仗，方能立于不败之地。”
《礼记·中庸》中记载:“凡事预则立，不预则废。”
生活中，人们也常说:“机会都是留给有准备的人的。”

由此可见，任何事情成功的前提便是做充分的准备，对于这门重要的OO课程也是如此。

下面是笔者的学习心得和过程总结，还请不吝赐教。

代码架构分析

最后一次作业代码架构

笔者用从IntelliJ IDEA导出的一张类图以供参考。
最后一次作业类图
总体而言，这份代码基本能够~~一次性通过历次强测~~ ，也符合checkstyle检查规范。但仍然存在诸多不足。这里浅显地分析两点。

第一是类的设计问题。Adventure类的Adventure这个单词似乎没有很好地表达“冒险者”的意思。上一次作业原本想改，但是不想再大动干戈，避免出现其他奇怪的错误。还有PrintInfo这个类，原本是用来处理输出信息的，但是后来的迭代没再用到，也算是一个败笔。
第二个是封装性问题。对于很多的新增特性，比如背包，笔者在Adventure类中新增了三个属性来处理，但是应该封装成一个Package类更加妥当。战斗日志也可以单独封装，但笔者在Main类中直接对其进行处理。可以看到这样导致每个类分工不明确。

Main类重构历程

笔者对代码的重构主要集中在Main类上。

第四次作业前

第二次作业时，笔者的Main类结构如下：

public class Main {
    public static void main(String[] args) {
        int n;
        int capacity;
        int star;
        int advId;
        int botId;
        int equipId;
        String name;
        int type;
        HashMap<Integer, Adventure> adventures = new HashMap<>();
        Scanner scanner = new Scanner(System.in);
        n = scanner.nextInt();
        for (int i = 0; i < n; i++) {
            type = scanner.nextInt();
            switch (type) {
                case 1:
                    advId = scanner.nextInt();
                    name = scanner.next();
                    adventures.put(advId, new Adventure(advId, name));
                    break;
                case 2:
                    advId = scanner.nextInt();
                    botId = scanner.nextInt();
                    name = scanner.next();
                    capacity = scanner.nextInt();
                    adventures.get(advId).addBottle(new Bottle(botId, name, capacity));
                    break;
                case 3:
                    advId = scanner.nextInt();
                    botId = scanner.nextInt();
                    adventures.get(advId).removeBottle(botId).printIntFirst();
                    break;
                case 4:
                    advId = scanner.nextInt();
                    equipId = scanner.nextInt();
                    name = scanner.next();
                    star = scanner.nextInt();
                    adventures.get(advId).addEquipment(new Equipment(equipId, name, star));
                    break;
                case 5:
                    advId = scanner.nextInt();
                    equipId = scanner.nextInt();
                    adventures.get(advId).removeEquipment(equipId).printIntFirst();
                    break;
                case 6:
                    advId = scanner.nextInt();
                    equipId = scanner.nextInt();
                    adventures.get(advId).increaseStar(equipId).printStringFirst();
                    break;
                default:
                    break;
            }
        }
    }
}

有两个很突出的问题。方法行数很容易超过限制；没有统一的输入解析，不便进行Junit测试。因此从第三次作业开始，笔者尝试通过重构来解决这些问题。下面是第三次作业的结构：

//addAdventure等函数的具体实现不再列出
public static ArrayList<String> getOrders(String line) {
        String[] strings = line.trim().split(" ");
        return new ArrayList<>(Arrays.asList(strings));
    }

    public static void makeChoice(HashMap<Integer, Adventure> advs, ArrayList<String> orders) {
        int type = Integer.parseInt(orders.remove(0));
        switch (type) {
            case 1:
                addAdventure(advs, orders);
                break;
            case 2:
                addBottle(advs, orders);
                break;
            case 3:
                removeBottle(advs, orders);
                break;
            case 4:
                addEquipment(advs, orders);
                break;
            case 5:
                removeEquipment(advs, orders);
                break;
            case 6:
                increaseStar(advs, orders);
                break;
            case 7:
                addFood(advs, orders);
                break;
            case 8:
                removeFood(advs, orders);
                break;
            case 9:
                takeEquipment(advs, orders);
                break;
            case 10:
                takeBottle(advs, orders);
                break;
            case 11:
                takeFood(advs, orders);
                break;
            case 12:
                useBottle(advs, orders);
                break;
            case 13:
                eatFood(advs, orders);
                break;
            default:
                break;
        }
    }

    public static void main(String[] args) {
        int n;
        HashMap<Integer, Adventure> advs = new HashMap<>();
        Scanner scanner = new Scanner(System.in);
        n = Integer.parseInt(scanner.nextLine().trim());
        for (int i = 0; i < n; i++) {
            String nextLine = scanner.nextLine();
            makeChoice(advs, getOrders(nextLine));
        }
    }
}

这里对输入进行了集中处理，也把每个操作封装成一个函数来调用。算是~~比较妥善地解决了上述的两个问题~~ 。
但是随着迭代的进行很快又出现了第三个问题：

switch-case语句中即使每个case只有三行，也会显得太过臃肿。方法限制为60行，最多只能有20个case语句。

这时笔者进行了最大的一次改动。

第四次作业后

第四次作业Main类结构如下：

//只展示架构核心内容
public static void addAction() {
        actionsMap.put(1, Main::addAdventure);
        actionsMap.put(2, Main::addBottle);
        actionsMap.put(3, Main::removeBottle);
        actionsMap.put(4, Main::addEquipment);
        actionsMap.put(5, Main::removeEquipment);
        actionsMap.put(6, Main::increaseStar);
        actionsMap.put(7, Main::addFood);
        actionsMap.put(8, Main::removeFood);
        actionsMap.put(9, Main::takeEquipment);
        actionsMap.put(10, Main::takeBottle);
        actionsMap.put(11, Main::takeFood);
        actionsMap.put(12, Main::useBottle);
        actionsMap.put(13, Main::eatFood);
        actionsMap.put(14, Main::enterFightMode);
        actionsMap.put(15, Main::searchByDate);
        actionsMap.put(16, Main::searchByAttacker);
        actionsMap.put(17, Main::searchByAttacked);
    }
public static ArrayList<String> getOrders(String line) {
        String[] strings = line.trim().split(" ");
        return new ArrayList<>(Arrays.asList(strings));
    }

public static void makeChoice(ArrayList<String> orders) {
        int type = Integer.parseInt(orders.remove(0));
        actionsMap.get(type).accept(orders);
    }

public static void main(String[] args) {
        addAction();
        int n;
        n = Integer.parseInt(scanner.nextLine().trim());
        for (int i = 0; i < n; i++) {
            String nextLine = scanner.nextLine();
            makeChoice(getOrders(nextLine));
        }
    }

下面是笔者具体的修改过程。

确保每个case只调用一个函数解决对应业务逻辑。
修改每个上述函数（后称业务函数）的参数表，只允许有一个参数，尽量不要有返回值。

这是为了配合使用Consumer函数式接口，使得每个业务函数都可以看作一个对象（像是C语言中的函数指针），能够给Consumer“赋值”（~~说法可能不严谨，体会一下意思~~）。

构建一个HashMap成员，将Consumer作为HashMap的值，将选项作为HashMap的键。

例如：
HashMap<Integer, Consumer<ArrayList<String>>> actionsMap = new HashMap<>();
在这里我们通过1个Integer类型的键值来获取1个Consumer类型的值，这个Consumer类型的值就是我们的业务函数。
给Consumer指定的类型就是唯一参数的声明类型。

实际调用时，通过HashMap的get方法获取对应的Consumer，再调用Consumer的accept方法。

例如：
actionsMap.get(1).accept(args);
这里等价于case为1时，调用相应的函数。
这里args是传给业务函数的实际参数。accept方法是Consumer提供的方法，用来接收参数并调用业务函数。

现在可以去掉switch语句块了。

除了Consumer函数式接口，还有其他很多函数式接口，感兴趣可以自行了解。
这种方法称为表驱动法，可以有效减少代码量，提高可读性。

Jnuit使用心得

注解类型

只说说笔者用到的吧。

@Test：这个注释说明依附在 JUnit 的 public void 方法可以作为一个测试案例。
@Before：有些测试在运行前需要创造几个相似的对象。在 public void 方法加该注释是因为该方法需要在 test 方法前运行。
@After：如果你将外部资源在 Before 方法中分配，那么你需要在测试运行后释放他们。在 public void 方法加该注释是因为该方法需要在 test 方法后运行。