如题
这不是作业，也不是我公司的工作(小弟在数位广告业当码农，在台北扣完劳健保大概快四万QQ)
是刚好有一次去医院看病的时候想到，医院的排队叫号机
好像刚好可以是一个小system design的题目 ?
(小弟非本科年资快两年，但平常几乎都在CRUD跟设计TABLE还有接第三方API，所以以下内容
没意外应该会有很多不太对的地方，希望可以海涵QQ)
就我的理解，医院的排队叫号机有以下规则
1.首先是可以线上挂号(checkInOnline)，这边很简单，反正就是先挂号的优先看病，我这边为了简化先不考虑
现场挂号这件事，也假设只有一间医院，以及一个门诊，门诊也没有其他
2.可以过号(skipNumber)，也就是现场叫号(callNumber)的时候，如果病人不在，那么就把他
跳掉，直到他又现场注册(checkInAgain)，重新插入健保卡的时候，排队叫号机才会
每看三个线上挂号的病人就去看现场注册的病人，当然当现场线上挂号的病人时，排队叫号机
就会一直去叫被过号的病人
上面就是我粗浅的规则
然后下面是我的思路:
我决定用物件来区分行为，因为事情好像没有很复杂所以不引入Interface
我决定区分两个class分别是 Patient 和 Hospital
Patient有两个函数分别是
1.checkInOnline
2.checkInAgain (要有基本的防呆，只有被过号了，才能现场注册，另外看过医生的话，也不能再次注册)
这两个函数都argument都是 Hospital物件
Hospital我一开始有想到优先伫列，只是后来觉得好像直接设成两个Queue事情好像
比较简单?
我决定Hosptital要有这几个Member
int skipNumber=3;
int skipNumberNow=0;
Queue<Patient> normalQueue= new LinkedList<>();
Queue<Patient> skipQueue= new LinkedList<>();
并且要有下面两个函数
1.callNumber()
2.skipNumber()
说了这么多，这是我的github，我觉得我真的code写得很乱很烂
https://reurl.cc/nDEYG8
懒得看github的人
我直接贴code

我这边为了各种防呆，宣告了一堆 flag
感觉程式码没有写的很好
想请问各位先进，有没有什么可以改善的方法，或是思路
谢谢各位年薪三百万

不是你想怎么写就怎么写是以医院制度医生跟护理师说的算

建议把你手上的专案优化比较实在...

现实当然很难，但想想也没关系吧

这感觉比较像是OOP随堂小练习XD可以多想一下要变成一个可以用的系统，会有哪些service、资料怎么传递、db怎么设计之类的

当下号码为n,叫号未到的号码x存set过号者x重新注册时去查setx在set的话从set踢出 塞入 pq<K,V> = (n+3,x)pq 依K排序每次叫号 if(pq.peek().K <= n) 改叫过号者号码之后做pq.poll() 如果再度过号就重新塞进set应该连OOP都用不太到 现成的资结就能实作了

你这是OOP跟系统设计没什么关联 这就简单的CRUD就能解决了 顶多就是思考怎么解决多人同时预约热门医生的问题

实务上一定是crud吧，大概四个字段就搞定了好像需要五个，编号,id,是否挂号,是否看完,挂号时间

现在的医院叫号机应该还有一些病人的优先级，例如高龄病患的顺序比般人高之类的，然后再叠加上去是否已过号，过号病患插卡后，会等两位未过号的病患看诊完就轮到他，此时他的优先度又比其他人高，可以再多观察看看叫号机的实务状况

开三条thread放东西就好main准备要进入main的（max3)skip变量只用一个 priority，剩下都是内部的商业逻辑处理

我以为挂号机的目的是如何取最大的公平性，每家医院诊所看来不太一下，自己看诊挂号多注意一下就可以观察到

广告业码农也太有上进心

刚好公司最近在做类似的东西，没做这么复杂因为实体的叫号机可以自己按号码，医生想先看谁就看谁XD

这么简单的功能,先上线,使用者有问题再改就好了

前提就错了吧，这不是system design

喔喔 我想说leetcode有一题是design twitter 所以这种只是算是物件设计吗？

已经从 OOP 下手了，可以从 OOA 的角度先找关联性

只有表面看起来公平，里面医生要先看几号就按几号

在现场都没有发现自己被医生跳号过 XD

其实我有发现，但能怎样，还是要加入一个强制跳号功能

讨论题目是不需要跟真实世界情况一致的只要专注在想要讨论的点就可以了

这功能不能太常用啊 不然整天逛医院的老人家会抗议

这题目难的是需求分析跟访谈 写code不算问题

可是我看大部分的，过号他就直接停在那里，然后人工出来叫，等到知会过的都看完了，号码就继续往下按，会来回显示的反而很少

而且还要分挂号顺序跟 报到顺序(含过号报到)最重要的设计其实在人工介入的部分XD

简单的事情不用写得很复杂,放在 list 里面就好吧

医院取号这东西 考虑线上取号的话 最极端情况应该就等于售票系统 瞬间一堆连线进来时系统要撑得住 然后要有一套算法去决定谁抢到几号这样

叫号机没用，还是会有人一直问护理师可不可以先看

这个东西需要整合到HIS里面,而且是寡占,可以研究但没市场

发给护士一个扩音喇叭，她说几号就是几号更正 是护理师

这个题目还有个重点是要设计一个可抽换的策略模组啊..因为规则每家可能要的都不一样,而且还会变...

一个list就解决了，不用复杂化吧…

你忘了设计有民代关说乔床位时有user会无视queue直接排到最前面的问题

蛮有趣的啊，有点类似设计电梯的题目

现在结合线上挂号 还会有报到功能 到现场插健保卡报到

有没有看过医生一开诊直接把所有号码按完，所有人都变过号之后就看谁先报到先看了

这个很简单 你需要的是读写锁 外加一个list 你用的

说一个list解决的去看一下system design在玩什么吧 又不是学校写作业

linkedlist就很不错 病人申请是写 医生更改顺序也是写 只是你需要储存当前的顺序 建议储存在硬盘 整个物

既然是当作SD题目讨论 那就不是要问你怎么样最简单写code实现功能 也不是要你自己想像题目没提到的use case让讨论越来越发散

件储存在硬盘一个档案 每个医生一个档当然数据库也可以 但有点太肥务实操作 不打高空

实际上user 只有登入医院的系统以及医院的实体机器。这应该流量不会很大吧看起来就算不存db,只用 一个list也搞定

精神可嘉

这题目觉得有趣，之前看到的情境是病患看诊后，医师决定要排当日检查，检查完毕后还要回来诊间报到，此外他还有可能是年长者，必须优先进入，光是这些情境就有不少要判断的事情了

有些医院会故意把网络挂号的排在很后面,现挂的较优先当天检完马上要回来的,医生会要他回来后直接敲门告知至于乔床位不需要考虑,因为需要乔床位表示已经没床位,没床位那就根本没法先预约病床了,就无关系统预约了.

都还好 不就是list内结构需要有什么field 目前能想到最麻烦就是不只一个人可以改顺序的问题 但这情况让它存在就很奇妙 有的话必须引入diff机制

就算讨论发散也是很正常的网络上也不是所有人都会跟你认真的讨论。回过头来说，真实世界就是会有那么多奇奇怪怪规则

SD在玩什么？你是问实务还是考试还是粉丝向？这种人为远大于系统的，实务上就是list+插队搞定不然你提个系统能符合所有医生的规矩啊，没接过业务喔不然为什么考试都问抢票系统，选课系统，从未考过医院

快四万先辞职吧 怎么生活啊

靠年终生活，而且我还四大硕qq 但当然不是电资考试好像很喜欢考短网址哈哈

因为短网址很多知识点可以讨论 算是背答案的题你这题因为你已经把scale限缩 硬要讨论效能瓶颈有点怪你如果改成提供全国医院统一使用的线上预约系统就变成类似抢票系统的标准题然后答题方式你google一下就很多了只有一间医院 一个诊间 就没有concurrency以及资料量的问题，SD题目也不是要面试者天马行空自己引入其他需求

喔喔 因为我原本想说想要实作具有扩充性的程式码，万一如果抽换看病的规则的话之前看到有人讨论过电商的折价券，虽然没牵涉到并发，但我觉得已经够复杂了Qq

其实SD不考写code 但我还是离题顺便说一下那个code，建议不要让Patient直接存取queue，他可以向诊间预约报名，queue应该是诊间的private member，封装在诊间内，排队逻辑怎么实作外面不用知道。如果你有一天要换成用magic queue来实作，外面不用知道magic queue的存在，也不用参考，病患只要知道他可以向诊间线上报名就好了。你想做可抽换排队逻辑是对的，更好的做法是有一个interface定义排队机，让诊间选择使用哪一个这样诊间也不用看到data structure

所以病人挂号的那个Function input是排队机吗？那医院是还要被排队机依赖注入吗？

可以用工厂模式让诊间取得他要使用的排队机用 clinic.register(catient); 注册病患*patient

谢谢b大，原来b大是c#派哈哈

SPEC和流程定好后其实不难...

身为医院资讯码农...这个问题最困难的不是程式...而是平衡整院方、医师、护理师的要求一开始很单纯，挂号序号+检查后回来报到，两个规则后来多了一个过号要延后顺序，再来又多了敬老号最后做出来的东西，医师、护理师、病人都不爽全部抱怨都变成资讯处的锅...讲到后面变成抱怨了...

噗 这么差的东西不用展示了 list当queue... 需求到这样子其实也不用写系统 原来老旧系统还比较好用你以为是concurrency 其实只是保障正确性 这东西确实不用注重什么高并发

是啊，医生哪管你什么工厂模式，急不急都是医生决定的

可以

高并发更不用管，遇到高并发都是会死人了还管你SD？高并发都是重大灾难，医院自己有检伤SOP拉回来，这题就是命题太烂，医院绝对不是软件技术问题

我不懂你们为什么要一直讨论实务讨论到最后攻击题目太烂？原文不是说当作小的SD题目讨论吗

我是没攻击题目 但依照范例这连system都不算 以number排连简单的事件都处理不了到这样还不如照原来 我是不觉得楼主只是当讨论

攻击题目是指另一位，至于我贴的那个范例，是因为刚好讨论到code的部分，那个跟系统设计无关因为原po有提到他想实作具有扩充性的程式，才讨论一下他的code可以怎么开接口，那个是OOP的部分了，所以贴出的范例也只是想清楚一点表达coding的部分，跟系统设计需要考量的东西无关

不是code是政治问题，然后工程师话语权在医院就是底层，所以...QQ

这样做扩充性并没有高没扩充多少 只是多了规范说题目很烂的其实也说的通 因为还真的不如旧方法然后楼主还很奇怪 说不复杂不需要引interface 后面又说需要扩充 然后给的范例又interface 突然又可以了所以你提供的楼主应该会 到底在做什么

其实是我知道interface可以隔离，但是我不会实作，有点像是我知道llm训练了chatgpt但我不会用llm 另外我觉得我code写的很丑qq 一堆flag 变量

你的说词很反复 还没走先学跑了 语言还没弄好就开始system design了 这样都差不多4万可领真的是上天眷顾

好吧 那先不要说这是system design好了，其实我上过交大资结跟oop,这边建议语言要先补充什么呢，因为我thread也看了，但是现职工作就是一直堆商业逻辑，才想说可以写一些东西来进步的税有没有什么具体的考核点呢?因为所谓的更熟Java不知道指的是更熟内建的资结的api吗？还是什么，因为如果没去看我现在不会的东西，好像就没进步的感觉，还是说我应该要去补充设计模式吗？

那你就先写个演唱会抢票系统 TDD跟DDD也了解一下设计模式常用的几招会就好 不一定要整本书都学完

很简单 自己玩 现在都是用框架 外加有上头 你很难玩出什么花样 也很难领悟奥秘 但代价什么自己想想 因为有人会组挡你看穿本质现在看起来是好开发了 但学得更多了阻挡

演唱会抢票是指不要超卖吗？那有需要记录User是谁抢到票这样吗？看过对岸的课程，但讲的不深只有提到jvm锁或是分布式锁谢谢二位

别人是旁敲侧击学东西 你是旁敲侧击别人学东西

不要超卖只是整个系统中的一个小issue你要想burwei大提出的那些问题

这根本没意义 推文所考虑的点都是值得考量的

喔喔，了解了，谢谢哈哈

如果你想做正经的东西出来 但你这篇很糟糕

电商 影音串流 社群 instant messaging 都去github找看看别人怎么做 多注意接口怎么设计 尽量画图帮助理解

好的谢谢

先把题目明确再来想怎么做吧一直出想法小专案都被扩成大问题了门诊挂号一路加到住院回诊紧急开刀要不要连哪个民代插队比较有利也一起放进来？

公立医院: 80岁敬老优先

有人做.google 一下

实务上一定是crud啦 不过之前去长庚看诊在挂门号上好像没遇到什么不便

你应该参考状态设计模式 而不是建一堆flag

你用内存去搞？服务重启怎么办这个用数据库读写锁就完成 用 redis queue做序列

基本的排版空格也要做一下