博客作业

第一次大作业

前言

java学习的感受

到至今的4-15号,学习java应该快有了2个月,相对于c语言,java难度更大,c语言是面向过程的一门语言,它主要关注解决问题的步骤和过程。程序由一系列函数构成，通过函数的调用来实现特定的功能。例如，一个 C 语言程序可能会包含多个函数，每个函数负责完成一个特定的任务。而java是面向对象的一门语言,作为一种面向对象的编程语言，它支持封装、继承和多态等面向对象的特性。在 Java 里，所有代码都要写在类中，程序的运行依赖对象的交互。例如，一个简单的 Java 程序可能会定义一个类，然后创建该类的对象来调用类中的方法。

大作业的踩坑感受

第一次大作业

第一次的大作业,那一个70分的测试点,我并没有过,尽管我后面知道,代码的运行逻辑是:
都与电梯方向相同,取最短路径,都与电梯方向相反,电梯方向对比,选择顺路(就是是你会保持他电梯原来运行惯性方向,取最近的那一个)的,一个相同一个相反,取电梯方向相同的,电梯顺路就比如电梯向上,选择反方向最大的那个,电梯向下,选择反方向最小
我初次代码过不了测试点,直到第二天,我发现:当电梯方向和乘客内外需求方向相同时,如果电梯当前楼层大于当前外部请求的位置,按我上面的想法来说,电梯会自己下去,后上去,这就导致我的错误.我就在代码修改成:
public void process() {
int inf = 0;
int outf = 0;
String indirection = "UP";
String outdirection;

    while (!in_request.isEmpty() && !out_request.isEmpty()) {
        //判断内部方向
        if (in_request.get(0) > current_floor) {
            indirection = "UP";
        } else if (in_request.get(0) < current_floor) {
            indirection = "DOWN";
        }

        //判断外部方向
        Pattern pattern = Pattern.compile("UP|DOWN");
        Matcher matcher = pattern.matcher(out_request.get(0));
        if (!matcher.find()) {
            return;
        }
        outdirection = matcher.group();

        //读取外部目标楼层
        Pattern pattern1 = Pattern.compile("\\d+");
        Matcher matcher1 = pattern1.matcher(out_request.get(0));

        if (!matcher1.find()) {
            return;
        }
        //内外目标楼层
        outf = Integer.parseInt(matcher1.group());
        inf = in_request.get(0);

        //同方向的判断
        if (direction.equals(indirection) && direction.equals(outdirection)) {
            if (direction.equals("UP")) {
                if (outf > inf) {
                    moveElevator(inf, direction);
                    in_request.remove(0);
                } else if (outf < inf&&outf>current_floor) {
                    moveElevator(outf, direction);
                    out_request.remove(0);
                } 
                else if(outf<inf&&outf<current_floor){
                    moveElevator(inf,direction);
                    in_request.remove(0);
                }
                else {
                    moveElevator(outf, direction);
                    in_request.remove(0);
                    out_request.remove(0);
                }
            } else {
                if (outf > inf&&current_floor>outf) {
                    moveElevator(outf, direction);
                    out_request.remove(0);
                } 
                else if(outf>inf&&current_floor<outf){
                    moveElevator(inf,direction);
                    in_request.remove(0);
                }
                    else if (outf < inf&&outf<current_floor) {
                    moveElevator(inf, direction);
                    in_request.remove(0);
                } else {
                    moveElevator(outf, direction);
                    in_request.remove(0);
                    out_request.remove(0);
                }
            }
        }

第二次大作业

第二次作业我开始采用了Linklist,我对于这个应用不是那么清晰,我经常造成非零返回,因为在创建对象时,一遍一遍访问时,没注意两个队列是否是空的情况,这也导致我的错误

第三次大作业

第三次代码,对于我的代码发现主要问题:我对判断下一个方向和下一个楼层调用的是同一个函数,这也会让我多次进行remove,这会让我代码并不符合我的预期,后面添加是否是这个函数调用来判断是否remove;

大作业

第一次大作业

题目:

设计一个电梯类，具体包含电梯的最大楼层数、最小楼层数（默认为1层）当前楼层、运行方向、运行状态，以及电梯内部乘客的请求队列和电梯外部楼层乘客的请求队列，其中，电梯外部请求队列需要区分上行和下行。
电梯运行规则如下：电梯默认停留在1层，状态为静止，当有乘客对电梯发起请求时（各楼层电梯外部乘客按下上行或者下行按钮或者电梯内部乘客按下想要到达的楼层数字按钮），电梯开始移动，当电梯向某个方向移动时，优先处理同方向的请求，当同方向的请求均被处理完毕然后再处理相反方向的请求。电梯运行过程中的状态包括停止、移动中、开门、关门等状态。当电梯停止时，如果有新的请求，就根据请求的方向或位置决定移动方向。电梯在运行到某一楼层时，检查当前是否有请求（访问电梯内请求队列和电梯外请求队列），然后据此决定移动方向。每次移动一个楼层，检查是否有需要停靠的请求，如果有，则开门，处理该楼层的请求，然后关门继续移动。
使用键盘模拟输入乘客的请求，此时要注意处理无效请求情况，例如无效楼层请求，比如超过大楼的最高或最低楼层。还需要考虑电梯的空闲状态，当没有请求时，电梯停留在当前楼层。
请编写一个Java程序，设计一个电梯类，包含状态管理、请求队列管理以及调度算法，并使用一些测试用例，模拟不同的请求顺序，观察电梯的行为是否符合预期，比如是否优先处理同方向的请求，是否在移动过程中处理顺路的请求等。为了降低编程难度，不考虑同时有多个乘客请求同时发生的情况，即采用串行处理乘客的请求方式（电梯只按照规则响应请求队列中当前的乘客请求，响应结束后再响应下一个请求），具体运行规则详见输入输出样例。

输入格式:
第一行输入最小电梯楼层数。
第二行输入最大电梯楼层数。
从第三行开始每行输入代表一个乘客请求。

电梯内乘客请求格式：<楼层数>
电梯外乘客请求格式：<乘客所在楼层数,乘梯方向>，其中，乘梯方向用UP代表上行，用DOWN代表下行（UP、DOWN必须大写）。
当输入“end”时代表输入结束（end不区分大小写）。

输出格式:
模拟电梯的运行过程，输出方式如下：

运行到某一楼层（不需要停留开门），输出一行文本：
Current Floor: 楼层数 Direction: 方向
运行到某一楼层（需要停留开门）输出两行文本：
Open Door # Floor 楼层数
Close Door

输入样例:

1
20
<3,UP>
<5>
<6,DOWN>
<7>
<3>
end

输出样例:

Current Floor: 1 Direction: UP
Current Floor: 2 Direction: UP
Current Floor: 3 Direction: UP
Open Door # Floor 3
Close Door
Current Floor: 4 Direction: UP
Current Floor: 5 Direction: UP
Open Door # Floor 5
Close Door
Current Floor: 6 Direction: UP
Current Floor: 7 Direction: UP
Open Door # Floor 7
Close Door
Current Floor: 6 Direction: DOWN
Open Door # Floor 6
Close Door
Current Floor: 5 Direction: DOWN
Current Floor: 4 Direction: DOWN
Current Floor: 3 Direction: DOWN
Open Door # Floor 3
Close Door

这个图可以看出:
% Comments (注释百分比): 4%
Methods/Class (每个类的方法数): 4
Avg Complexity (平均复杂度): 未显示具体数值
Avg Depth (平均深度): 未显示具体数值
Max Depth (最大深度): 未显示具体数值
Max Complexity (最大复杂度): 未显示具体数值
Avg Stmts/Method (每个方法的平均语句数): 15.63
注:注释百分比较低，可能需要增加代码注释以提高可读性。每个类的方法数适中，平均每个类有4个方法。

得出结论:

代码注释: 注释百分比较低，建议增加注释以提高代码的可读性和维护性。
代码复杂度: 分支语句百分比为26.1%，表明代码逻辑较为复杂，可能需要简化。
代码结构: 每个类的方法数适中，但最复杂方法的行数未定义，需要进一步分析。
代码块深度: 代码块的深度分布较为均匀，但深度为3的代码块最多，表明项目中存在一些较为复杂的逻辑结构。

getIn_request()：复杂度为1，包含1条语句，最大深度为2，未被调用（调用次数为0）。
inrequest()：复杂度为3，包含2条语句，最大深度为3，被调用1次。
outrequest()：复杂度为3，包含2条语句，最大深度为3，被调用1次。
process()：复杂度为36，包含79条语句，最大深度为6，被调用59次。
setMax_floor()：复杂度为1，包含1条语句，最大深度为2，未被调用。
setMin_floor()：复杂度为1，包含1条语句，最大深度为2，未被调用。

得出结论:
从这些数据可以看出，process() 方法是最复杂的，具有最高的圈复杂度、语句数和调用次数，这可能意味着它是项目中的关键部分，需要特别注意其可维护性和可读性。而 getIn_request()、setMax_floor() 和 setMin_floor() 方法虽然简单，但未被调用，可能需要检查它们的必要性或调用逻辑。

得出结论:
% Comments（注释百分比）: 4.0 [8-20]
项目的注释百分比为4%，这远低于推荐的范围（8%到20%）。这可能意味着代码的可读性和可维护性较差，建议增加注释。
Methods/Class（每个类的方法数）: 4.00 [4-16]
每个类平均有4个方法，这处于推荐范围的下限。这表明类的职责可能过于集中，但也可能表明类的设计较为简洁。
Avg Stmts/Method（每个方法的平均语句数）: 15.63 [6-12]
每个方法平均有15.63条语句，这高于推荐范围（6到12条）。这可能意味着方法过于复杂，建议将方法拆分成更小的、功能单一的部分。
Max Complexity（最大复杂度）: 36 [2-8]
项目中存在复杂度为36的方法，这远高于推荐的最大复杂度（2到8）。这表明某些方法可能非常复杂，难以理解和维护，需要重构。
Max Depth（最大深度）: 6 [3-7]
项目中存在深度为6的嵌套结构，这接近推荐范围的上限（3到7）。这表明代码中存在较深的嵌套，可能需要简化。
Avg Complexity（平均复杂度）: 7.43 [2.0-4.0]
项目的平均复杂度为7.43，这高于推荐范围（2.0到4.0）。这表明整体代码复杂度较高，可能需要简化。
Avg Depth（平均深度）: 3.26 [1.0-2.2]
项目的平均深度为3.26，这高于推荐范围（1.0到2.2）。这表明代码中存在较多的嵌套结构，可能需要简化。

第二次大作业

题目:

对之前电梯调度程序进行迭代性设计，目的为解决电梯类职责过多的问题，类设计要求遵循单一职责原则（SRP），要求必须包含但不限于设计电梯类、乘客请求类、队列类以及控制类，具体设计可参考如下类图。

电梯运行规则与前阶段单类设计相同，但要处理如下情况：

乘客请求楼层数有误，具体为高于最高楼层数或低于最低楼层数，处理方法：程序自动忽略此类输入，继续执行
乘客请求不合理，具体为输入时出现连续的相同请求，例如<3><3><3>或者<5,DOWN><5,DOWN>，处理方法：程序自动忽略相同的多余输入，继续执行，例如<3><3><3>过滤为<3>

输入格式:
第一行输入最小电梯楼层数。
第二行输入最大电梯楼层数。
从第三行开始每行输入代表一个乘客请求。

输出格式:
模拟电梯的运行过程，输出方式如下：

输入样例1:

1  
20  
<3,UP>  
<5>  
<6,DOWN>  
<7>  
<3>  
end

输出样例1:

Current Floor: 1 Direction: UP  
Current Floor: 2 Direction: UP  
Current Floor: 3 Direction: UP  
Open Door # Floor 3  
Close Door  
Current Floor: 4 Direction: UP  
Current Floor: 5 Direction: UP  
Open Door # Floor 5  
Close Door  
Current Floor: 6 Direction: UP  
Current Floor: 7 Direction: UP  
Open Door # Floor 7  
Close Door  
Current Floor: 6 Direction: DOWN  
Open Door # Floor 6  
Close Door  
Current Floor: 5 Direction: DOWN  
Current Floor: 4 Direction: DOWN  
Current Floor: 3 Direction: DOWN  
Open Door # Floor 3  
Close Door

输入样例2:

1  
20  
<3,UP>  
<3,UP>  
<5>  
<5>  
<5>  
<6,DOWN>  
<7>  
<7>  
<3>  
<22,DOWN>  
<5,DOWN>  
<30>  
END

输出样例2:

Current Floor: 1 Direction: UP  
Current Floor: 2 Direction: UP  
Current Floor: 3 Direction: UP  
Open Door # Floor 3  
Close Door  
Current Floor: 4 Direction: UP  
Current Floor: 5 Direction: UP  
Open Door # Floor 5  
Close Door  
Current Floor: 6 Direction: UP  
Current Floor: 7 Direction: UP  
Open Door # Floor 7  
Close Door  
Current Floor: 6 Direction: DOWN  
Open Door # Floor 6  
Close Door  
Current Floor: 5 Direction: DOWN  
Open Door # Floor 5  
Close Door  
Current Floor: 4 Direction: DOWN  
Current Floor: 3 Direction: DOWN  
Open Door # Floor 3  
Close Door

这个要求相对于原来,需要多加一些类,比我之前写的代码,需要更加规范一些,以下是我的代码分析:

Kiviat 图
Kiviat 图展示了项目在多个度量维度上的分布情况，包括：
% Comments（注释百分比）: 0%（没有注释）
Methods/Class（每个类的方法数）: 5.14
Avg Stmts/Method（每个方法的平均语句数）: 5.86
Max Complexity（最大复杂度）: 未显示具体数值
Avg Complexity（平均复杂度）: 未显示具体数值
Avg Depth（平均深度）: 未显示具体数值
Max Depth（最大深度）: 未显示具体数值

总结
注释不足：项目的注释百分比为0%，建议增加注释以提高代码的可读性和可维护性。
代码复杂度：每个方法的平均语句数为5.86，表明方法相对简单。
代码深度：代码块的深度分布较为均匀，但深度为1和2的代码块最多，表明项目中存在一些较为简单的逻辑结构。
最大复杂度和最大深度：这些指标未定义，可能需要进一步分析以确定代码中是否存在非常复杂的部分。

分析
% Comments（注释百分比）: 0.0 [8-20]
项目的注释百分比为0%，远低于推荐范围（8%到20%）。这意味着代码中没有任何注释，这可能会影响代码的可读性和可维护性。
Methods/Class（每个类的方法数）: 5.14 [4-16]
每个类平均有5.14个方法，这在推荐范围（4到16）内，表明类的职责分配较为合理。
Avg Stmts/Method（每个方法的平均语句数）: 5.86 [6-12]
每个方法平均有5.86条语句，这在推荐范围（6到12条）内，表明方法相对简洁。
Max Complexity（最大复杂度）: 39 [2-8]
项目中存在复杂度为39的方法，这远高于推荐的最大复杂度（2到8）。这表明某些方法可能非常复杂，难以理解和维护，需要重构。
Avg Complexity（平均复杂度）: 3.39 [2.0-4.0]
项目的平均复杂度为3.39，这在推荐范围（2.0到4.0）内，表明整体代码复杂度较为合理。
Avg Depth（平均深度）: 2.76 [1.0-2.2]
项目的平均深度为2.76，略高于推荐范围（1.0到2.2）。这表明代码中存在一些嵌套结构，但总体上较为合理。
Max Depth（最大深度）: 6 [3-7]
项目中存在深度为6的嵌套结构，这在推荐范围（3到7）内，表明代码中存在一些较深的嵌套，但总体上较为合理。

结论
注释不足：项目的注释百分比为0%，建议增加注释以提高代码的可读性和可维护性。
方法复杂度：最大复杂度远高于推荐范围，表明某些方法可能过于复杂，需要重构以降低复杂度。
代码深度：平均深度和最大深度都在合理范围内，但平均深度略高，表明代码中存在一些嵌套结构，可能需要简化。
方法数量：每个类的方法数量在合理范围内，表明类的职责分配较为合理。

第三次大作业

对之前电梯调度程序再次进行迭代性设计，加入乘客类（Passenger），取消乘客请求类，类设计要求遵循单一职责原则（SRP），要求必须包含但不限于设计电梯类、乘客类、队列类以及控制类，具体设计可参考如下类图。

电梯运行规则与前阶段相同，但有如下变动情况：

乘客请求输入变动情况：外部请求由之前的<请求楼层数,请求方向>修改为<请求源楼层，请求目的楼层>
对于外部请求，当电梯处理该请求之后（该请求出队），要将<请求源楼层，请求目的楼层>中的请求目的楼层加入到请求内部队列(加到队尾）

输入格式:
第一行输入最小电梯楼层数。
第二行输入最大电梯楼层数。
从第三行开始每行输入代表一个乘客请求。

电梯内乘客请求格式：<楼层数>
电梯外乘客请求格式：<请求源楼层，请求目的楼层>，其中，请求源楼层表示乘客发起请求所在的楼层，请求目的楼层表示乘客想要到达的楼层。
当输入“end”时代表输入结束（end不区分大小写）。
输出格式:
模拟电梯的运行过程，输出方式如下：

输入样例1:

1
20
<5,4>
<5>
<7>
end

输出样例1:

Current Floor: 1 Direction: UP
Current Floor: 2 Direction: UP
Current Floor: 3 Direction: UP
Current Floor: 4 Direction: UP
Current Floor: 5 Direction: UP
Open Door # Floor 5
Close Door
Current Floor: 6 Direction: UP
Current Floor: 7 Direction: UP
Open Door # Floor 7
Close Door
Current Floor: 6 Direction: DOWN
Current Floor: 5 Direction: DOWN
Open Door # Floor 5
Close Door
Current Floor: 4 Direction: DOWN
Open Door # Floor 4
Close Door

输入样例2:

1
20
<5,9>
<8>
<9,3>
<4>
<2>
end

输出样例2:

Current Floor: 1 Direction: UP
Current Floor: 2 Direction: UP
Current Floor: 3 Direction: UP
Current Floor: 4 Direction: UP
Current Floor: 5 Direction: UP
Open Door # Floor 5
Close Door
Current Floor: 6 Direction: UP
Current Floor: 7 Direction: UP
Current Floor: 8 Direction: UP
Open Door # Floor 8
Close Door
Current Floor: 9 Direction: UP
Open Door # Floor 9
Close Door
Current Floor: 8 Direction: DOWN
Current Floor: 7 Direction: DOWN
Current Floor: 6 Direction: DOWN
Current Floor: 5 Direction: DOWN
Current Floor: 4 Direction: DOWN
Open Door # Floor 4
Close Door
Current Floor: 3 Direction: DOWN
Current Floor: 2 Direction: DOWN
Open Door # Floor 2
Close Door
Current Floor: 3 Direction: UP
Current Floor: 4 Direction: UP
Current Floor: 5 Direction: UP
Current Floor: 6 Direction: UP
Current Floor: 7 Direction: UP
Current Floor: 8 Direction: UP
Current Floor: 9 Direction: UP
Open Door # Floor 9
Close Door
Current Floor: 8 Direction: DOWN
Current Floor: 7 Direction: DOWN
Current Floor: 6 Direction: DOWN
Current Floor: 5 Direction: DOWN
Current Floor: 4 Direction: DOWN
Current Floor: 3 Direction: DOWN
Open Door # Floor 3
Close Door

Kiviat Graph:
% Comments（注释百分比）
Methods/Class（每个类的方法数）
Avg Stmts/Method（每个方法的平均语句数）
Max Complexity（最大复杂度）
Avg Depth（平均深度）
Avg Complexity（平均复杂度）
从图中可以看出，注释百分比较低（1.6%），而最大复杂度（56）和最大代码块深度（6）较高。

Block Histogram:
深度为0的代码块中有20条语句。
深度为1的代码块中有60条语句。
深度为2的代码块中有80条语句。
深度为3的代码块中有60条语句。
深度为4的代码块中有40条语句。
深度为5的代码块中有20条语句。
深度为6的代码块中有10条语句。
深度为7及以上的代码块中语句数量很少。

总结
从这些度量数据可以看出：
代码注释率较低：只有1.6%的代码行包含注释，这可能影响代码的可读性和可维护性。
代码复杂度较高：最大复杂度为56，最大代码块深度为6，这表明代码中存在一些复杂的逻辑，可能需要重构以提高可读性和可维护性。
方法调用较多：有136条方法调用语句，这表明代码中存在较多的方法调用，可能需要检查方法的合理性和必要性。
分支语句覆盖率较低：分支语句覆盖率为24.8%，这表明代码中存在较多的分支逻辑，可能需要增加测试用例以提高覆盖率。

分析:
% Comments（注释百分比）: 1.6%
这个值远低于推荐范围（8-20%），表明代码注释不足。增加注释可以帮助其他开发者（或未来的你）更好地理解代码逻辑和目的。
Methods/Class（每个类的方法数）: 4.63 [4-16]
这个值处于推荐范围的低端，表明每个类的方法数量适中。这可能意味着类的职责较为集中，但也可能表明类的设计较为简洁。
Avg Stmts/Method（每个方法的平均语句数）: 6.78 [6-12]
这个值处于推荐范围的低端，表明方法相对简洁。这是一个好的实践，有助于提高代码的可读性和可维护性。
Max Complexity（最大复杂度）: 56 [2-8]
这个值远高于推荐的最大复杂度，表明某些方法可能非常复杂，难以理解和维护。需要重构这些方法以降低复杂度。
Avg Complexity（平均复杂度）: 3.92 [2.0-4.0]
这个值略高于推荐范围，表明整体代码复杂度略高。虽然不是极端情况，但仍然建议简化代码以提高可读性和可维护性。
Avg Depth（平均深度）: 2.89 [1.0-2.2]
这个值略高于推荐范围，表明代码中存在一些嵌套结构。虽然不是极端情况，但建议简化嵌套结构以提高代码的清晰度。
Max Depth（最大深度）: 6 [3-7]
这个值处于推荐范围的高端，表明代码中存在一些较深的嵌套结构。这可能会影响代码的可读性，建议简化这些结构。

总结:
注释不足：需要增加注释以提高代码的可读性和可维护性。
方法复杂度：最大复杂度远高于推荐范围，表明某些方法可能过于复杂，需要重构以降低复杂度。
代码深度：平均深度和最大深度都在合理范围内，但平均深度略高，表明代码中存在一些嵌套结构，可能需要简化。
方法数量：每个类的方法数量在合理范围内，表明类的职责分配较为合理。
通过解决这些不足之处，可以提高代码的质量和可维护性，使代码更加健壮和易于理解。

java学习的总结

代码的不足和改进建议

注释不足：
代码中注释的比例非常低，会影响代码的可读性和可维护性。应增加注释以提高代码的可读性，使其他开发者更容易理解代码的意图和逻辑。
代码复杂度较高：
从上面软件分析的结果来看，表明代码中存在一些复杂的逻辑。复杂的代码会导致难以理解和维护，应该进行重构以简化逻辑，提高代码的可读性和可维护性。
方法调用较多：
代码有大量方法调用语句，这表明代码中存在较多的方法调用。过多的方法调用可能会使代码难以跟踪和维护，应该检查方法的合理性和必要性，需要简化或合并一些方法。
分支语句覆盖率较低：
分支语句覆盖率低，这表明代码中存在较多的分支逻辑。较低的覆盖率意味着某些分支逻辑没有被充分测试，增加测试用例以提高覆盖率，确保代码的健壮性。
类和方法的设计：
每个类的方法数适中，但最复杂方法的行数未定义，需要进一步分析。应该遵循单一职责原则（SRP），确保每个类和方法都有明确的职责，避免类和方法过于庞大和复杂。
代码深度：
代码块的深度分布较为均匀，但深度为3的代码块最多，表明项目中存在一些较为复杂的逻辑结构。应该简化这些复杂的逻辑结构，以降低代码的复杂度。
代码复用性：
代码并没有做到高标准的复用性，每次修改都要修改很多内容。应该提高代码的复用性，通过抽象和封装等减少重复代码，提高代码的可维护性。
代码标准性
代码也不是特别标准，这些也是我今后需要改正和提升的地方。建议遵循代码规范和最佳实践，使代码更加标准化和一致化。

学习和成长总结

(1) 在解决复杂问题时，可能会接触到不同的设计模式，如单例模式、工厂模式等。这些模式是软件开发中经过验证的解决方案，可以帮助我编写更高效、更可维护的代码。
(2) 在编写电梯调度程序等需要处理复杂逻辑的程序时，理解和实现不同的算法和数据结构。这有助于提高我的算法思维和问题解决能力.
(3) 在编程过程中遇到问题是正常的。通过解决这些问题，我正在提高自己的问题解决能力，这也是软件开发中的一项关键技能。
(4)我也加强了调试的能力,面对一些逻辑问题,更好,更快地找出.

对于课程

(1) 多添加类关系设计的讲解,不是很能听得懂,😶‍🌫️,多讲一些具体的例子
(2) 题目可以设定的背景有趣一点,可以调动学生的积极性.

posted @ 2025-04-17 23:06 li'skindom 阅读(146) 评论(0) 收藏举报

刷新页面返回顶部

likindom

博客作业

第一次大作业

前言

java学习的感受

大作业的踩坑感受

第一次大作业

第二次大作业

第三次大作业

大作业

第一次大作业

第二次大作业

第三次大作业

java学习的总结

代码的不足和改进建议

学习和成长总结

对于课程

公告