前言
这学期的数字电路模拟程序作业一共分三次迭代完成，从最基础的五个逻辑门实现，到增加三态门、译码器等复杂组合元件，再到最终支持子电路封装和完整异常处理，整个过程循序渐进，题量和难度都逐步提升。第一次作业我大概写了 200行代码，第二次到250 多行，第三次因为增加了组合模式和异常处理模块，代码量突破了 900行，实属给我吓哭了。
知识点方面，除了数字电路本身的逻辑运算规则，更多的是面向对象设计思想的实践，包括封装、继承、多态的运用，第三次作业还接触到了组合模式这种结构型设计模式。同时，迭代开发的流程、测试的重要性、异常处理的规范这些软件工程的基本概念，也在作业中得到了实实在在的锻炼。通过这三次作业，我对如何从需求出发，一步步设计并实现一个中等复杂度的程序，有了非常直观的认识，也踩了很多印象深刻的坑，学到了很多书本上学不到的实战经验。
一、设计与分析
1.1 第一次作业：基础逻辑门模拟
整体设计思路
第一次作业的需求相对简单，只需要实现与门、或门、非门、异或门、同或门五种基本逻辑门，解析输入的电路连接关系，计算并按指定顺序输出各元件的输出电平。我当时的核心思路是将每个逻辑门抽象为独立的类，提取它们的共同属性和方法形成父类，通过继承实现不同门的特有逻辑。
具体来说，我先定义了一个抽象的Gate类，里面包含了输入引脚的存储结构、输出电平变量，以及一个抽象的calculate()方法。然后针对五种逻辑门分别创建了AndGate、OrGate、NotGate、XorGate、XnorGate五个子类，每个子类实现自己的calculate()方法。另外设计了一个Circuit类作为整个电路的管理器，负责解析输入内容、存储所有元件和连接关系、按顺序触发所有元件的计算。Main类则作为程序入口，负责读取输入流和输出最终结果。
PowerDesigner 类图与分析
下图是我PowerDesigner 16 绘制的第一次作业类图
plaintext
从类图可以很清楚地看到整个程序的结构：Main类依赖Circuit类，Circuit类聚合了多个Gate对象，Gate作为抽象父类被五个具体的逻辑门类继承。这种结构基本符合面向对象的设计原则，每个类都有相对明确的职责。
复杂度分析
我用 SourceMonitor 对代码进行了复杂度分析，结果如下表：
| 方法 | ev(G) | iv(G) | v(G) |
|---|---|---|---|
| Main.main(String[]) | 1 | 3 | 3 |
| Circuit.Circuit() | 1 | 1 | 1 |
| Circuit.parseInput(String) | 2 | 10 | 12 |
| Circuit.parseElement(String) | 3 | 5 | 7 |
| Circuit.parseConnection(String) | 2 | 6 | 7 |
| Circuit.calculateAll() | 1 | 4 | 4 |
| Circuit.printResults() | 2 | 5 | 6 |
| Gate.Gate() | 1 | 1 | 1 |
| Gate.setInput(int, int) | 1 | 1 | 1 |
| Gate.getOutput() | 1 | 1 | 1 |
| Gate.isValid() | 1 | 2 | 2 |
| AndGate.calculate() | 1 | 2 | 3 |
| OrGate.calculate() | 1 | 2 | 3 |
| NotGate.calculate() | 1 | 1 | 1 |
| XorGate.calculate() | 1 | 1 | 2 |
| XnorGate.calculate() | 1 | 1 | 2 |
| Total | 21 | 49 | 57 |
| Average | 1.36 | 3.14 | 3.57 |
| 从复杂度数据可以看出，整个程序的复杂度主要集中在Circuit类的解析方法上。parseInput()方法的循环复杂度 v (G) 达到了 12，因为它需要同时处理 INPUT 行、连接行和 end 结束标志三种不同的输入类型，里面嵌套了很多 if-else 判断。parseElement()方法的复杂度也偏高，因为要区分两种不同格式的元件名：带括号的与门 / 或门（如 A (2) 1）和不带括号的非门 / 异或门 / 同或门（如 X1）。相比之下，各个具体逻辑门的calculate()方法复杂度都很低，因为它们的运算逻辑本身很简单。 | |||
| 设计心得 | |||
| 第一次作业是我第一次真正意义上用面向对象的思想写程序，很多地方都考虑不周。最明显的问题是Circuit类的职责过重，几乎把所有的解析、计算、管理、输出逻辑都塞了进去，导致这个类变得非常臃肿，耦合度很高。从类图上也能看出来，Circuit类承担了太多的工作，几乎和其他所有类都有交互。 | |||
| 另外，引脚只是用整数编号来表示，没有封装成独立的类，很多地方重复写了检查引脚是否存在的代码。不过整体的分层思路是对的，用抽象类和继承来处理不同类型的逻辑门，为后面两次作业的迭代打下了比较好的基础。如果当时能把解析逻辑单独抽成一个Parser类，把输出逻辑抽成一个Printer类，整个结构会更清晰。 | |||
| 1.2 第二次作业：复杂组合电路元件模拟 | |||
| 整体设计思路 | |||
| 第二次作业在第一次的基础上新增了四种元件：三态门、译码器、数据选择器、数据分配器。这些元件的共同特点是都包含控制引脚，而且输出引脚数量不再固定为 1 个（比如译码器有多个输出引脚）。因此我首先修改了父类Gate的结构，增加了控制引脚的存储属性，并将原来单一的输出变量改成了输出引脚的映射表。 | |||
| 然后我新增了四个具体的门类：TriStateGate（三态门）、Decoder（译码器）、Mux（数据选择器）、Demux（数据分配器），分别实现它们的计算逻辑。Circuit类的解析方法也需要相应修改，增加对新元件标识符（S、M、Z、F）和新元件名格式的支持，同时还要处理新的引脚编号规则。 | |||
| 这次作业最大的难点是引脚编号的对应关系。题目要求含控制引脚的元件按 "控制 - 输入 - 输出" 的顺序编号，每种类型的引脚内部按从小到大排序。比如 3-8 线译码器 M (3) 1，0-2 号引脚是控制端 S1-S3，3-5 号是输入端 A0-A2，6-13 号是输出端 Y0-Y7。这个对应关系非常容易搞混，也是我这次作业踩坑最多的地方。 | |||
| PowerDesigner 类图与分析 | |||
| 第二次作业的类图是在第一次的基础上扩展的，我直接在原来的 PowerDesigner 文件里新增了四个元件子类，修改了Gate类的属性。 | |||
| plaintext | |||
 |
从类图可以看到，这次作业的核心变化是Gate类增加了controls和outputs两个属性，分别用来存储控制引脚和多个输出引脚。原来的五个基础逻辑门类不需要修改，只需要新增四个新的元件子类即可。这体现了继承的优势，对于新增的同类型功能，只需要扩展子类，不需要修改父类和其他已经存在的子类。
复杂度分析
复杂度分析结果如下：
| 方法 | ev(G) | iv(G) | v(G) |
|---|---|---|---|
| Main.main(String[]) | 1 | 3 | 3 |
| Circuit.Circuit() | 1 | 1 | 1 |
| Circuit.parseInput(String) | 2 | 12 | 15 |
| Circuit.parseElement(String) | 4 | 8 | 11 |
| Circuit.parseConnection(String) | 2 | 7 | 8 |
| Circuit.calculateAll() | 1 | 5 | 6 |
| Circuit.printResults() | 3 | 8 | 10 |
| Gate.Gate() | 1 | 1 | 1 |
| Gate.setControl(int, int) | 1 | 1 | 1 |
| Gate.setInput(int, int) | 1 | 1 | 1 |
| Gate.getOutput(int) | 1 | 1 | 1 |
| Gate.isValid() | 2 | 3 | 4 |
| TriStateGate.calculate() | 2 | 3 | 4 |
| Decoder.calculate() | 5 | 10 | 15 |
| Mux.calculate() | 3 | 6 | 8 |
| Demux.calculate() | 3 | 7 | 9 |
| AndGate.calculate() | 1 | 2 | 3 |
| OrGate.calculate() | 1 | 2 | 3 |
| NotGate.calculate() | 1 | 1 | 1 |
| XorGate.calculate() | 1 | 1 | 2 |
| XnorGate.calculate() | 1 | 1 | 2 |
| Total | 37 | 78 | 95 |
| Average | 2.10 | 4.89 | 5.94 |
| 可以看到，这次作业的整体复杂度比第一次明显上升。复杂度最高的是Decoder.calculate()方法，v (G) 达到了 15。这是因为译码器的逻辑比较复杂：首先要判断控制引脚是否满足工作条件（S1=1 且 S2+S3=0），如果不满足则所有输出无效；如果满足，则需要将输入引脚的电平组合成二进制数，找到对应的输出引脚并将其设为 0，其余设为 1。里面包含了多层条件判断和循环，所以复杂度很高。 | |||
| parseElement()方法的复杂度也从 7 上升到了 11，因为现在需要处理四种不同格式的元件名：与门 / 或门的 "A (n) x" 格式、非门等的 "Nx" 格式、数据选择器 / 分配器的 "Z (n) x"/"F (n) x" 格式、译码器的 "M (n) x" 格式，条件分支更多了。 | |||
| 设计心得 | |||
| 这次作业让我深刻体会到了迭代开发的优势。因为第一次作业已经搭建好了基础框架，这次只需要新增元件子类和修改对应的解析方法，不用从零开始写。但同时也暴露了第一次设计的缺陷：原来的Gate类没有考虑到控制引脚和多输出的情况，导致这次需要修改父类的结构，影响了所有的子类。这让我明白，在做初始设计的时候，要尽量考虑到未来可能的扩展，留出足够的灵活性。 | |||
| 另外一个严重的问题是引脚规则的硬编码。我把每个元件的引脚数量、类型和编号范围都直接写在了对应的类里，比如在Decoder类里写死了 "3 个控制引脚，n 个输入引脚，2^n 个输出引脚"，不仅容易写错，而且以后要修改规则的话必须改动源码。还有计算逻辑和输出逻辑混在一起，比如Decoder的calculate()方法里不仅计算了结果，还直接生成了符合要求的输出字符串，耦合度很高。 | |||
| 1.3 第三次作业：子电路与异常处理 | |||
| 整体设计思路 | |||
| 第三次作业是变化最大的一次，新增了子电路封装和异常处理两大核心功能。子电路可以将一部分电路打包成一个整体，在主电路中像普通元件一样使用，这个需求正好符合组合模式的适用场景。因此我对整个类结构进行了重构：提取出一个更上层的抽象类Component，原来的Gate类和新增的SubCircuit类都继承自Component。这样不管是单个逻辑门还是一个复杂的子电路，都可以被当作统一的Component对象来处理，极大地提高了代码的可扩展性。 | |||
| 异常处理方面，题目要求处理五种特定的异常情况，并且有严格的优先级顺序，多条异常只处理最先出现的那个。我专门设计了一个ExceptionHandler类，负责检查输入中的所有异常情况。在解析每个连接的时候，按题目规定的优先级从高到低依次检查，找到第一个异常就立即输出并终止程序。 | |||
| PowerDesigner 类图与分析 | |||
| 这次作业我重新画了类图，因为整个架构都变了。画组合模式的类图的时候我纠结了很久，不知道怎么表示SubCircuit内部包含多个Component对象的关系，后来才明白应该用聚合关系，而且箭头要指向Component抽象类。 | |||
| plaintext | |||
 |
从类图可以清晰地看到组合模式的结构：Component作为抽象根节点，Gate和SubCircuit作为它的两个子类。SubCircuit内部又聚合了多个Component对象，形成了递归的树形结构。这种设计完美解决了子电路的问题，使得子电路可以像普通元件一样被无缝集成到主电路中。
另外，我还新增了一个ExceptionHandler类，专门负责异常检查。这个类和Circuit类是依赖关系，Circuit在解析每个连接的时候会调用ExceptionHandler的方法进行异常检查。
复杂度分析
复杂度分析结果如下：
| 方法 | ev(G) | iv(G) | v(G) |
|---|---|---|---|
| Main.main(String[]) | 1 | 4 | 4 |
| Circuit.parseInput(String) | 3 | 15 | 18 |
| Circuit.parseSubCircuit(String) | 4 | 12 | 16 |
| Circuit.parseConnection(String) | 5 | 13 | 18 |
| Circuit.calculateAll() | 2 | 8 | 10 |
| Component.Component() | 1 | 1 | 1 |
| SubCircuit.calculate() | 6 | 14 | 20 |
| SubCircuit.setInput(String, int) | 2 | 3 | 4 |
| SubCircuit.getOutput(String) | 1 | 2 | 3 |
| ExceptionHandler.checkConnection(String) | 5 | 13 | 17 |
| ExceptionHandler.checkPinConflict(String) | 2 | 5 | 6 |
| Total | 32 | 90 | 117 |
| Average | 2.73 | 6.21 | 7.50 |
| 这次作业的复杂度是三次中最高的。SubCircuit.calculate()方法以 v (G)=20 位居榜首，因为它需要处理子电路的整个计算流程：先接收主电路传入的输入信号，然后按顺序计算内部所有元件的输出，最后将指定的输出信号返回给主电路。里面包含了循环遍历、依赖处理和多层条件判断，逻辑非常复杂。 | |||
| parseConnection()和ExceptionHandler.checkConnection()方法的复杂度也很高，都达到了 18 和 17。这是因为它们需要处理五种异常情况，并且要严格按照优先级顺序检查，每个异常都对应一段独立的检查逻辑，所以条件分支非常多。 | |||
| 设计心得 | |||
| 这次作业让我真正感受到了设计模式的威力。组合模式的运用完美解决了子电路的问题，使得子电路可以像普通元件一样被无缝集成到主电路中，几乎不需要修改原来的计算逻辑。这让我明白，合理运用设计模式可以极大地简化复杂问题的解决方案，提高代码的可扩展性和可维护性。 | |||
| 但同时也存在很多不足。比如子电路的计算顺序还是按元件加入的顺序进行的，如果出现后加入的元件被先加入的元件依赖的情况，就会导致计算错误。异常处理部分用了大量的 if-else 语句，代码非常臃肿，而且不容易扩展新的异常类型。另外，子电路目前只支持一层嵌套，不能在子电路内部再定义子电路，限制了它的使用场景。 | |||
| 二、采坑心得 | |||
| 这三次作业我踩了无数的坑，有些是因为对题目理解不透彻，有些是因为代码设计有缺陷，还有些纯粹是粗心大意。这些坑让我印象深刻，也让我学到了很多宝贵的经验。 | |||
| 2.1 第一次作业的坑 | |||
| 元件名正则表达式错误：这是我遇到的第一个大坑。一开始我想用字符串分割的方法来解析元件名，比如把 "A (2) 1" 按字符拆分成数组，然后手动提取括号里的数字和后面的编号。结果遇到多位数的输入引脚数就完全出错了，比如 "O (10) 2" 会被解析成输入引脚数为 1。后来查了很多资料，才学会用正则表达式来处理这种结构化的字符串。我写了两个正则表达式，一个匹配带括号的元件：([AO])((\d+))(\d+)$，另一个匹配不带括号的：([NXY])(\d+)$，用了正则之后解析就再也没出过错了。 | |||
| 输出顺序不符合要求：题目要求严格按照 "与门→或门→非门→异或门→同或门" 的顺序输出，同类元件按编号从小到大排序。一开始我把所有元件都存在一个 ArrayList 里，按加入的顺序输出，结果经常出现顺序错误。比如先加入了异或门 X1，再加入与门 A (2) 1，输出的时候就会先输出 X1，这不符合要求。后来我改成用五个 TreeMap 分别存储五种类型的元件，TreeMap 的 key 是元件编号，这样自动就按编号排序了。输出的时候按顺序遍历这五个 TreeMap，完美解决了顺序问题。 | |||
| 未处理未连接的元件：一开始我不管元件的输入引脚有没有全部连接，都会计算它的输出，导致输出了很多无效的结果。比如一个两输入与门只有一个引脚接了信号，另一个悬空，我还是会计算它的输出，结果肯定是错的。后来我在Gate类里加了一个isValid()方法，检查所有必需的输入引脚是否都有连接，如果有任何一个没有连接，就返回 false，输出的时候直接忽略这个元件。 | |||
| 2.2 第二次作业的坑 | |||
| 引脚编号对应关系搞反：这绝对是这次作业最让我崩溃的坑。题目说含控制引脚的元件按 "控制 - 输入 - 输出" 的顺序编号，我一开始完全理解反了，以为是 "输入 - 控制 - 输出"。比如三态门的正确引脚是 0 号控制、1 号输入、2 号输出，我写成了 0 号输入、1 号控制、2 号输出。结果三态门的所有测试用例全错，不管输入是什么，输出都不对。我对着代码查了整整一个下午，才发现是引脚编号搞反了。后来我把每个元件的引脚规则都写在纸上，一个一个对着改，才终于把这个问题解决。 | |||
| 译码器输出格式错误：题目要求译码器不输出每个引脚的电平，而是直接输出输出为 0 的引脚编号，比如 "M (3) 1:3"。一开始我完全没注意到这个要求，还是按原来的格式输出每个输出引脚的电平，结果所有译码器的测试用例都不通过。后来反复读了三遍题目要求，才发现这个细节。我在Decoder类里加了一个getActiveOutputPin()方法，专门返回输出为 0 的引脚编号，如果控制引脚无效则返回 null，输出的时候忽略无效的译码器。 | |||
| 数据分配器控制端与输出端对应错误：数据分配器的控制端组合与输出端的对应关系也很容易搞反。题目说 AB=00 对应 W0，AB=01 对应 W1，以此类推。我一开始写成了 AB=00 对应 W3，AB=01 对应 W2，正好反过来了。这个错误非常隐蔽，因为有时候测试用例的输入正好能让错误的对应关系输出正确的结果，我直到最后跑完整测试集才发现这个问题。 |
2.3 第三次作业的坑
子电路引用解析错误：一开始我把子电路的输入输出当成了普通的元件引脚，比如主电路里的 "C1-A"，我以为是一个叫 "C1-A" 的元件的引脚，结果子电路根本没有被计算。后来我才明白，子电路应该被当作一个整体的Component对象，它的输入引脚对应子电路定义里的 INPUT 列表，输出引脚对应 OUT 列表。比如子电路 C1 定义了 "INPUT:A B"，那么 "C1-A" 就是子电路 C1 的第一个输入引脚，"C1-B" 是第二个输入引脚。我修改了parseConnection()方法，专门处理子电路引脚的解析，才解决了这个问题。
异常优先级处理错误：题目要求异常按 1 到 5 的优先级处理，一条连接如果有多个异常，只输出优先级最高的那个。一开始我是按代码编写的顺序检查异常，结果把优先级低的异常放在了前面，导致输出错误。比如一条连接既包含多个输入（优先级 1），又输入输出写反（优先级 4），我会先检查到输入输出写反，输出错误的异常信息。后来我严格按照题目给的优先级顺序重新排列了检查逻辑：先检查异常 1，再异常 2，依此类推，找到第一个异常就立即返回，不再检查后面的。
子电路内部元件输出格式错误：题目要求子电路内部的元件输出必须带上子电路编号，比如 "C1-A (2) 1-0:0"。一开始我输出的还是 "A (2) 1-0:0"，没有子电路编号，导致测试用例失败。后来我在Component类里加了一个parentId属性，用来存储它所属的父电路编号。每个元件在生成输出字符串的时候，如果parentId不为空，就先输出parentId + "-"，然后再输出元件本身的信息。子电路内部的元件在创建的时候，自动把parentId设为子电路的编号，这样输出就符合要求了。
三、改进建议
通过这三次作业，我发现了自己代码中很多可以改进的地方，也有了一些具体的优化思路。
3.1 基础架构改进
封装 Pin 类：目前所有引脚都是用整数编号表示，没有封装成独立的类，导致很多地方重复写了检查引脚类型、引脚是否存在的代码。应该设计一个Pin类，包含引脚号、引脚类型（控制 / 输入 / 输出）、电平值等属性，以及对应的 getter 和 setter 方法。这样每个Component内部就可以用Map<Integer, Pin>来存储引脚，代码会更清晰，也更容易扩展。
引脚规则配置化：现在每个元件的引脚数量、类型和编号范围都是硬编码在类里的，不仅容易出错，而且修改起来非常麻烦。应该把这些规则提取到外部配置文件中，比如用 properties 文件或者 JSON 文件，每个元件的引脚规则都从配置文件中读取。这样以后要修改引脚规则的时候，只需要修改配置文件，不用改动源码。
使用枚举类型：现在很多地方用整数表示类型，比如引脚类型、元件类型，很容易搞混。应该定义对应的枚举类型，比如PinType.CONTROL、PinType.INPUT、PinType.OUTPUT，ComponentType.AND_GATE、ComponentType.OR_GATE等。用枚举代替整数可以大大提高代码的可读性和安全性，编译器会自动检查类型错误。
3.2 计算逻辑改进
用拓扑排序确定计算顺序：目前元件的计算顺序是按加入的顺序进行的，如果出现依赖倒置的情况就会计算错误。应该引入拓扑排序算法，先构建元件之间的依赖关系图，然后生成正确的计算顺序。这样可以处理任何没有循环依赖的电路，大大提高程序的健壮性。
分离计算逻辑和输出逻辑：现在很多元件的calculate()方法里既做计算，又处理输出格式，耦合度很高。应该把这两部分分离，calculate()方法只负责计算并返回原始的结果数据，然后由一个专门的OutputFormatter类来负责将原始数据转换成符合题目要求的输出格式。这样以后要修改输出格式的时候，只需要修改OutputFormatter类，不用改动元件的计算逻辑。
3.3 异常处理改进
用责任链模式重构异常处理：现在的异常处理用了大量的 if-else 语句，代码臃肿且不易扩展。应该用责任链模式来重构，每个异常类型对应一个独立的异常处理器，然后将这些处理器按优先级顺序连成一条链。当检查一个连接的时候，将它传给这条链，第一个能处理的处理器就处理它并返回结果。这样以后要增加新的异常类型，只需要新增一个处理器并加入链中即可，不用修改原来的代码。
增加更多异常类型的处理：目前只处理了题目要求的五种异常，还有很多常见的异常没有处理，比如元件编号重复、引脚号超出范围、子电路未定义、输入信号不是 0 或 1、循环依赖等。应该逐步增加这些异常的处理，给出清晰明确的错误提示，让程序更加健壮。
3.4 子电路功能扩展
支持子电路嵌套：目前的子电路只能是一层，不能在子电路内部再定义子电路。应该修改SubCircuit类的解析和计算逻辑，让它可以包含其他SubCircuit对象，实现任意深度的子电路嵌套。这样可以支持更复杂的电路设计，比如把 8 位加法器封装成子电路，再用它构建 16 位加法器。
子电路参数化：可以考虑增加子电路参数化的功能，比如让子电路的输入引脚数量、元件参数等可以在实例化的时候指定。这样可以进一步提高子电路的复用性，减少重复代码。
四、总结
这三次数字电路模拟程序的作业，是我这学期收获最大的编程实践。从最开始只会写简单的面向对象代码，到后来能运用继承、组合模式来设计中等复杂度的系统，我对面向对象的核心思想有了非常深刻的理解。我明白了好的面向对象设计应该是高内聚、低耦合的，每个类只负责一件事，并且要为未来的扩展留出足够的空间。
测试的重要性也在这次作业中体现得淋漓尽致。一开始我不重视测试，都是写完代码之后手动测几个简单的用例，结果很多问题到最后才发现，花了几倍的时间去调试。后来我开始学着写单元测试，每个元件的计算逻辑、每个解析方法都写对应的测试用例，这样修改代码之后，只要运行单元测试就能知道原来的功能有没有被破坏，开发效率大大提高。
异常处理也是我这次学到的重要一课。一个好的程序不仅要能处理正确的输入，还要能优雅地处理各种错误情况，给用户清晰的提示。以前我写程序从来不会考虑异常情况，只要输入正确能跑就行，这次作业让我明白，异常处理是程序不可或缺的一部分。
当然，我也清楚地认识到自己还有很多不足。对设计模式的掌握还不够熟练，这次只用到了组合模式和简单的责任链模式，还有很多常用的设计模式不会运用。代码的可读性和可维护性还有待提高，有些地方的代码写得很臃肿，注释也不够详细。调试技巧也需要加强，有时候一个简单的 bug 要找很久才能定位。
在以后的学习中，我会继续深入学习设计模式，多研究优秀的开源代码，提高自己的代码设计能力。同时也要多做编程练习，积累实战经验，提高自己的编程水平和调试技巧。另外，我还要学习更多的算法知识，比如图论算法，为以后实现更复杂的时序电路打下基础。
总的来说，这三次作业虽然过程很辛苦，踩了很多坑，但收获也是巨大的。它让我从一个只会写简单程序的新手，变成了一个能独立设计和实现中等复杂度系统的程序员。这些宝贵的经验，一定会对我以后的学习和工作产生非常积极的影响。