1.GitHub项目
https://github.com/Littlehui3/wc
2.用时表格
| PSP2.1 |
任务内容 |
计划完成需要的时间(min) |
实际完成需要的时间(min) |
| Planning |
计划 |
45
扫描二维码关注公众号，回复：
7365506 查看本文章
|
50 |
| Estimate |
估计这个任务需要多少时间，并规划大致工作步骤 |
45 |
50 |
| Development |
开发 |
880 |
740 |
| Analysis |
需求分析 (包括学习新技术) |
60 |
30 |
| Design Spec |
生成设计文档 |
30 |
- |
| Design Review |
设计复审 (和同事审核设计文档) |
10 |
- |
| Coding Standard |
代码规范 (为目前的开发制定合适的规范) |
40 |
40 |
| Design |
具体设计 |
60 |
80 |
| Coding |
具体编码 |
400 |
510 |
| Code Review |
代码复审 |
30 |
30 |
| est |
测试（自我测试，修改代码，提交修改） |
250 |
200 |
| Reporting |
报告 |
450 |
180 |
| Test Report |
测试报告 |
300 |
370 |
| Size Measurement |
计算工作量 |
30 |
- |
| Postmortem & Process Improvement Plan |
事后总结 ,并提出过程改进计划 |
60 |
80 |
| Summary |
合计 |
2690 |
2410 |
3.解题思路
一开始审题认为可能需要处理多条语句，考虑使用线程池来处理每个用户的请求，这样既可以封装用户的每个请求到一个request类里，还能有效防止线程过多造成的效率下降。考虑到控制台和图形界面都需要与管理线程的业务逻辑相分离，设计了一个RequestManager来管理所有请求。统计空格、行数、字符数都十分相似，分开为三个类，实现Counter接口，使得它们的结构更加规范，同时也使得增加新的Counter更方便，可扩展性提高。
实际开发过程中，从三个Counter的实现开始，让Request处理选项和文件，代码有点长，于是分开了两个方法来分别处理选项和文件。
文件方面，支持相对路径、绝对路径、当前目录下的同类型文件（*.txt *.c）输入
选项方面，支持 -l、-w、-c、-s
4.类的关系图
