Doodle:大家都说了能来的时间,会议才算定了吗?
Doodle 帮一群人商量开会时间。组织者给出几个时段,参与者分别表示方便、必要时可以或不行,最后由组织者确定一个时间。
先尝试拆解问题、设计和实现,再展开思路,检查状态、边界与取舍,并设计验证用例。思路提供分析路径,不给出完整实现。
01
代码思考
排期定案后,通知该发给谁?
实现一个在本地运行的排期通知模块。组织者邀请了甲、乙、丙,候选时段是周二和周四。只有提交过整张答卷的人会收到最终时间,哪怕他两个时段都不能来。收到邀请但还没作答的人不会收到这封通知。通知内容是一对「收件人、确定的时段」。
- 模块能接收某人对两个时段的完整答卷(方便、必要时可以、不行),以及组织者的定案操作。定案前,同一人重新提交时替换旧答卷。首次定案时返回本次应发的通知,并记住选定时段;定案后拒绝新的答卷,再次请求定案也不能改期或产生新通知。操作依次到达,姓名和时段均合法;通知的排列顺序不限。
- 甲先填两天都方便,又改为仅周四方便。乙填两天都不行,丙未答。组织者确定周二,本次只能产生「甲、周二」「乙、周二」各一条。此后丙来补答,应被拒绝;再请求确定周四,本次通知为空,查询结果仍是周二。
- 用熟悉的语言交付可运行的模块和上述调用。用返回值代替实际发信,说明代码怎样区分“有没有回应”和“能不能出席”,以及哪个操作有权触发通知。
查看思路
先站在乙和丙的位置看,两人都不会参加周二,系统却需要为他们做出不同决定。再沿两次定案操作检查,哪些信息必须保留,才能确定第二次应返回什么。