北航oo（2020）第二单元博客作业

目录

• 北航oo（2020）第二单元博客作业
  • homework 3 solid分析与可扩展性分析
    • single responsibility principle
    • open close principle
    • liskov substitution principle
    • interface segregation principle
    • dependency inversion principle
  • • homework 1
    • homework 2
    • homework 3
    • uml时序图
  • bug分析
  • hack策略分析

设计策略分析（多线程视角）

本单元的三次作业中，我采用了相似的策略：采用输入线程与电梯线程通过线程安全的调度器进行交互的方式。这种方式基本属于生产者-消费者模式。在调度器的设计方面，我主要采用synchronized关键字结合wait和notify方法完成互斥访问和同步控制。

homework 3 solid分析与可扩展性分析

single responsibility principle

elevator类有且仅有一个public方法：run方法，仅仅负责执行电梯的运行逻辑。

main类有且仅有一个public方法：main方法。但main方法既负责创建线程，又负责输入的处理与结束，具有多重责任。可以采取创建新的输入类和输入线程的方法解决这个设计问题。

dispatcher类具有多个public方法，但每个方法都有唯一确定的职责，通过下面章节中uml类图即可确认这一特性。dispatcher类负责将请求放置于每一楼层，供elevator取用，满足了srp原则。

floorconverter类有两个public方法，负责将楼层号与数组下标相互转换，满足了srp原则。

floorselector类有两个public方法，分别用来判断当前层是否可以停靠和选择乘客的目的楼层。这两个职责都需要电梯的停靠信息，而且逻辑联系较为紧密，因此可以置于同一类中完成。

open close principle

本次作业中除继承thread类外没有使用任何继承，几乎都是通过修改已有实现完成新增功能，违反了ocp原则。

liskov substitution principle

本次作业中除继承thread类外没有使用任何继承，因此该原则无从体现。

interface segregation principle

本次作业中没有使用任何接口，因此该原则无从体现。

dependency inversion principle

本次作业中除继承thread类外没有使用任何继承，且没有使用任何接口，因此该原则无从体现。

可扩展性

通过上面的分析可以看出，扩展功能几乎一定需要通过改写已有的实现来完成。但由于类的public方法职责都较为明确，这样的设计可以为功能的扩展带来一定的便利。

基于度量的程序结构分析

homework 1

代码度量

type name	method name	loc	cc	pc
dispatcher	dispatcher	10	2	0
dispatcher	setfinished	6	1	0
dispatcher	addrequest	13	2	1
dispatcher	getrequests	14	2	2
dispatcher	gettask	30	9	1
elevator	elevator	11	2	1
elevator	run	39	10	0
elevator	stoponfloor	20	2	1
elevator	geton	7	2	1
elevator	getoff	7	2	0
elevator	go	10	1	0
main	main	23	3	1

type name	nof	nopf	nom	nopm	loc	wmc	nc	dit	lcom	fanin	fanout
dispatcher	5	1	5	5	80	16	0	0	0.0	2	0
elevator	6	0	6	2	102	19	0	0	0.0	1	1
main	0	0	1	1	25	3	0	0	-1.0	0	2

类图

本次作业构建了三个类。这些类的封装较好，对外暴露的方法较少，且都具有明确的职责。大部分方法具有明确的职责，也较为简洁。但是，elevator类的run方法展开了电梯的一次运行逻辑，整体较为复杂；dispatcher类的gettask方法也较为复杂，不便改动和维护。

homework 2

代码度量

type name	method name	loc	cc	pc
dispatcher	dispatcher	10	2	0
dispatcher	setfinished	6	1	0
dispatcher	addrequest	13	2	1
dispatcher	getrequests	23	6	3
dispatcher	gettask	35	9	1
dispatcher	getuppertask	8	3	1
dispatcher	getlowertask	8	3	1
elevator	elevator	12	2	2
elevator	run	39	10	0
elevator	stoponfloor	20	2	1
elevator	geton	7	2	1
elevator	getoff	7	2	0
elevator	go	10	1	0
floorconverter	indextofloor	7	2	1
floorconverter	floortoindex	7	2	1
main	main	27	4	1

type name	nof	nopf	nom	nopm	loc	wmc	nc	dit	lcom	fanin	fanout
dispatcher	6	1	7	5	111	26	0	0	0.0	2	1
elevator	8	0	6	2	105	19	0	0	0.0	1	2
floorconverter	0	0	2	2	16	4	0	0	-1.0	2	0
main	0	0	1	1	29	4	0	0	-1.0	0	2

类图

本次作业与上一次作业架构极为相似，只是多了floorconverter类。因此优缺点与上次大体相同，在此不再赘述。

homework 3

代码度量

type name	method name	loc	cc	pc
dispatcher	dispatcher	10	2	0
dispatcher	setfinished	8	2	0
dispatcher	addrequest	13	2	1
dispatcher	elevatoraddrequest	9	2	2
dispatcher	getrequests	12	2	4
dispatcher	filterrequests	19	4	5
dispatcher	decreaserequestcount	6	2	0
dispatcher	gettask	35	9	2
dispatcher	hasvalidrequest	10	3	4
dispatcher	getuppertask	11	4	2
dispatcher	getlowertask	11	4	2
elevator	elevator	28	5	3
elevator	run	40	10	0
elevator	changedirection	8	2	0
elevator	stoponfloor	18	2	1
elevator	geton	10	2	1
elevator	getoff	15	3	0
elevator	go	12	1	0
floorconverter	indextofloor	7	2	1
floorconverter	floortoindex	7	2	1
floorselector	isstoppable	12	4	2
floorselector	selectfloor	15	5	4
floorselector	selectfloora	6	2	1
floorselector	selectfloorb	18	6	3
floorselector	selectfloorc	24	8	3
main	main	33	6	1

type name	nof	nopf	nom	nopm	loc	wmc	nc	dit	lcom	fanin	fanout
dispatcher	6	1	11	7	152	36	0	0	0.2727272727272727	2	2
elevator	10	0	7	2	143	25	0	0	0.0	0	3
floorconverter	0	0	2	2	16	4	0	0	-1.0	3	0
floorselector	3	0	5	2	80	25	0	0	1.0	2	1
main	0	0	1	1	35	6	0	0	-1.0	0	1

类图

本次作业构建了五个类。这些类的封装较好，对外暴露的方法较少，且都具有明确的职责，类间的协作关系也较为明确。大部分方法具有明确的职责，也较为简洁。但是，与前两次作业一样，elevator类的run方法仍然展开了电梯的一次运行逻辑，整体较为复杂；dispatcher类的gettask方法也较为复杂，不便改动和维护。

uml时序图

由于三次作业的线程交互模式较为类似，因此统一绘制uml时序图如下。

bug分析

本单元作业在公测和互测中未出现任何bug。

在第三次作业的开发过程中，由于dispatcher类的gettask方法和getrequests方法判断请求是否为空的标准不一致，我的电梯线程在一些情况下出现了轮询，导致在中测中出现了ctle的现象。我在本地通过在jprofiler中观察线程状态及cpu时间，并在程序中打印log的方式，最终定位了bug的位置，并进行了修复。

hack策略分析

本次作业同第一单元不同，需要做到在线交互。因此，本次作业的测试要求更高。但是，由于摸鱼心切，我仍然采用了手动构造测试用例的方法。因此，本单元我未能发现他人的任何bug。

心得体会：线程安全与设计原则

通过本单元的三次作业，我对java多线程编程有了一个初步的认识，并了解了一些简单的互斥访问与同步控制的方法。在多线程编程中，通过线程安全的共享对象来完成线程间交互是十分清晰而简洁的方式。通过对象锁，可以使该对象在同一同步块内只能被一个线程访问，且不会被打断。再结合wait和notifyall方法，可以避免轮询，高效利用cpu资源。此外，在设计中遵循solid原则及一些其他重要的设计原则也是十分重要的，这些原则保证了程序结构的清晰性和良好的可扩展性。在本单元作业中，部分设计原则未能体现甚至有所违背，在今后的编程中会多加注意。