如題
這不是作業，也不是我公司的工作(小弟在數位廣告業當碼農，在台北扣完勞健保大概快四萬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
https://imgur.com/jKRcBmK
https://imgur.com/UW2yp0z
我這邊為了各種防呆，宣告了一堆 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做序列

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