当前位置：首页 > news >正文

Java_conclusion_2

news 2026/6/22 1:58:25

前言:

1、正则表达式的运用
2、七大设计原则的代码体现和运用
3、设计模式的运用场景
4、类继承、多态、接口的运用

第一次作业分析

(1)Dataprocessing的单方法平均语句84行，单个方法冗长，需通过拆分出子方法来优化冗余问题。
(2)ShowAgent中分支覆盖率高，由于在处理输入数据问题时采用过多的if-else语句，此时应该采用正则表达式来优化硬编码的问题。
(3)当前And/Not/Or/Xor/Xnor/CircuitElement/Pin方法注释少，需添加注释来提高代码的可读性

DataProcessing类中的getOutputPinElectrcalSignal方法

从参数列表明显可以看出随着电子元件类型的增加，显然这个参数列表会更加冗长，这明显违背了里氏代换原则(LSP)，应该讲所有元件常见列表时以抽象为参数，如以下方式：

在对比下明显可以看出参数列表并不会由于元件类型增加而增加
原因:以父类定义的List这个类型能代表所有的子类
优点:能明显的减少代码的冗余性
缺点:这个列表中存储的全部子类，具体一个不知道是哪一种元件
解决方案:通过给每一种子类添加type属性，通过instanceOf来确定具体元件种类，从而采取不同的方案

第二次作业分析

(1)main方法冗余，应通过将业务代码迁移到Datadistributor、DataSelector、ShowAgent等业务类中
(2)Decoder的类职责超载，应通过按功能将类方法拆分到其他类中
(3)代码总体的注释含量较低，可通过添加注释来提高可读性

输入数据处理

(1)将输入数据分为三个层次处理，第一个为提取有效信息，第二层是对有效信息的信息解读，第三层则是对引脚之间建立联系；即分别对应InputDataProcessing,InputParse,Transfermation三个类
(2)这里采取正则表达式来提取有效信息，提高了数据处理的统一性

输出

采取创建一个抽象父类，在多次迭代中不同的输出结构只需要不断继承这个showAgent类，从而提高代码的可维护性，可拓展性

第三次作业分析

(1)Main类中代码行数有308行，超出合理行数
(2)Transformation单方法平均语句过长，通过拆解为更小的方法来优化

Connection类的创建

这里通过给每个电子元件添加type属性实现，在输入数据处理创建Connection对象，当信号传递时通过对Connection对象里的两个元件类型判断，从而采取不同的处理方法，优化了对信号传递时关系存储的问题

同时采用了组合模式

通过组合设计模式实现对电路嵌套电路的问题，同时可以看出组合设计模式的运用场景就是用来解决嵌套问题

类图如下:

踩坑心得:

一、对代码没满足里氏代换原则(LSP)导致代码冗余

例子即第一次作业分析中的代码例子

二、在创建一个类要思考它的需求变化性

以电子元件为例，在三次作业的迭代中有最初的And/Or/Not/Xor/Xnor的五个电子元件，到后来加了DataDistributor/Decoder/ThreeGate,这个例子充分说明当有一类相似的东西，就必须要创建抽象父类来维持代码的可拓展性。

第一次迭代

第二次迭代

三、对里氏代换原则的应用归纳(以AndGateElement为例)

(1)对于定义一个对象时，如果他又父类赋值左侧类型是父类，在实例化对象时赋值右侧再写具体的子类
Circuitment andGate = new AndGateElment();
(2)对于数组也遵循(1)的原则
List andGateList = new ArrayList<>();
问题:对于这个子类要加类型属性，不然只能知道他们的类型时父类，所以在子类加类型属性来方便对不同子类进行不同的操作。

四、正则表达式在字符串数据处理的重要性

对于不用正则表达式的字符串我要考虑的是在整个字符串找第几个位置的数据，即要在不确定性的字符串长度中找出有效数据位置和数据的特殊位置(例如:字符串的头和尾)来确定有效信息的位置，这很容易导致数组越界问题；但是正则表达式则帮助我们把关注点放到字符串和正则表达式规则的对应，然后就能找到有效数据，大大减少对字符串的处理难度；

五、lamda表达式在自定义类型数据处理的简便性(以第三次迭代的排序为例)

(1)最麻烦的方式:
<1>创建一个实现Comparator接口的类
<2>创建对象
<3>作为参数传到sort的参数中
代码:
public class ComparatorImplementation implements Comparator{
@Override
public int compare(Circuitment g1, Circuitment g2) {
int index_1 = order.indexOf(g1.getType());
int index_2 = order.indexOf(g2.getType());
if(index_1 != index_2) {
return index_1 - index_2;
}
return g1.getNumber() - g2.getNumber();
}
}
ComparatorImplementation c = new ComparatorImplementation();
//假设这个list就是自定义对象数组
Collections.sort(list, c);
(2)匿名类
Comparator c = new Comparator(){
@Override
public int compare(Circuitment g1, Circuitment g2) {
int index_1 = order.indexOf(g1.getType());
int index_2 = order.indexOf(g2.getType());
if(index_1 != index_2) {
return index_1 - index_2;
}
return g1.getNumber() - g2.getNumber();
}
}
Collections.sort(list, c);
(3)lamda表达式
Collections.sort(list,(g1,g2)->{
int index_1 = order.indexOf(g1.getType());
int index_2 = order.indexOf(g2.getType());
if(index_1 != index_2) {
return index_1 - index_2;
}
return g1.getNumber() - g2.getNumber();
}
});
从代码的演变能明显感觉到lamda表达式的简便性
同时也从当前能总结出:lamda表达式更偏向于用在实现Java已经写好的接口实现上

改进建议

一、对引脚的改进

在这几次迭代中，并没有将Pin抽象为父类，应将Pin抽象为父类，因为在后续迭代中，出现类控制引脚的新种类

二、数据初始化问题

对于构造方法不论是无参还是有参构造一定要实例化对象，就是普通数据类型(例如:int则赋值为0或者-1等，String则赋值为空字符串)以防止数据操作时出现空指针的问题。

整体总结

一、七大设计原则(补充第一次)
1、里氏代换原则:父类用子类替换不会报错
代码体现方面:创建对象以父类创建对象，以具体子类实例化对象
二、设计模式
组合模式
解决的问题:对于本身可能包含本身的问题
类图以第三次作业的类图为例
代码:
父类:
public abstract class Component {
// 添加子元件
public abstract void add(Component component);

// 移除子元件
public abstract void remove(Component component);

// 获取所有子元件
public abstract List getChildren();
}
子类:和父类既是继承也是组合关系
public class Subcircuit extends Component {
private List children = new ArrayList<>();

@Override
public void add(Component component) {
children.add(component);
}

@Override
public void remove(Component component) {
children.remove(component);
}

@Override
public List getChildren() {
return children;
}
}
子类:只继承父类
public abstract class CircuitElement extends Component {
protected String type;
protected int number;

public String getType() {
return type;
}

public int getNumber() {
return number;
}

@Override
public void add(Component component) {
}

@Override
public void remove(Component component) {
}

@Override
public List getChildren() {
return Collections.emptyList();
}
}