一、前言
三次電梯調度程序設計圍繞單一職責原則（SRP）和迭代式開發展開，逐步優化類結構和功能實現：

1. 知識點覆蓋：
   面向對象設計（類、枚舉、接口）
   集合框架（Queue、List、Map）
   正則表達式（輸入解析）
   狀態機管理（電梯運行狀態、方向）
   調度算法（請求優先級、路徑規劃）
2. 難度遞進：
   題目一：基礎實現，單類包辦所有邏輯（輸入解析、狀態管理、調度）。
   題目二：拆分職責，新增請求隊列類，處理重複請求，初步遵循SRP。
   題目三：引入乘客類，取消請求類，外部請求自動轉換為內部目的樓層，進一步細化職責。
3. 核心目標：
   實現電梯的基本運行規則（方向優先、順次停靠）。
   理無效請求（樓層範圍、重複請求）。
   通過迭代優化類結構，提升代碼可維護性和擴展性。
   ** 二、設計與分析**
   題目1：單類全能設計

源碼結構：

class Elevator {
    private enum State { STOPPED, MOVING }
    private int minFloor, maxFloor, currentFloor;
    private Direction currentDir;
    private State currentState;
    private Queue<Integer> innerQueue;
    private Queue<ExternalRequest> outerQueue;
    // 方法：addInnerRequest、addExternalRequest、selectNextCommand、moveTo、run...
}

優點：
實現簡單，邏輯集中，適合快速驗證調度規則。
缺點：
違反SRP：電梯類承擔了輸入解析、狀態管理、調度算法、請求隊列管理等多個職責。
可維護性差：修改一個功能可能影響其他模塊（如修改調度算法需改動selectNextCommand，可能影響moveTo）。
擴展性不足：新增功能（如乘客類、多電梯調度）需大幅重構。

類圖（簡化）：

題目2：職責拆分與隊列優化

源碼結構：

class ExternalRequest {
    int floor;
    Direction dir;
    @Override
    public boolean equals(Object obj) { ... } // 用於去重
}
class Elevator {
    private LinkedList<Integer> innerQueue; // 改用LinkedList支持尾部判斷
    private LinkedList<ExternalRequest> outerQueue;
    // 方法：addInnerRequest（過濾重複）、addExternalRequest（過濾重複）...
}

改進點：
新增ExternalRequest類，封裝外部請求的屬性和去重邏輯。
隊列改用LinkedList，支持判斷尾部元素，實現連續重複請求過濾。
電梯類專注於狀態管理和調度，輸入解析仍在Main類中。
優點：
遵循SRP：請求類負責數據封裝，電梯類負責運行邏輯。
可維護性提升：重複請求處理邏輯集中在addInnerRequest和addExternalRequest中。
不足：
輸入解析仍與業務邏輯混合（Main類負責解析和調用電梯方法）。
調度算法仍與電梯類綁定，未獨立為控制類。

類圖（簡化）：

題目3：引入乘客類與控制類雛形
源碼結構：

class ExternalRequest { // 實際為乘客的外部請求，包含源和目的樓層
    int sourceFloor;
    int targetFloor;
    Direction dir;
    @Override
    public boolean equals(Object obj) { ... }
}

class Elevator {
    private LinkedList<Integer> innerQueue;
    private LinkedList<ExternalRequest> outerQueue;
    // 方法：處理外部請求時，將目的樓層加入內部隊列
}

改進點：
外部請求改為<源樓層, 目的樓層>格式，模擬乘客的完整行程。
處理外部請求時，自動將目的樓層加入內部隊列，實現“接客→送客”的完整流程。
進一步強化請求類的數據封裝，電梯類專注於樓層移動和隊列管理。
優點：
更貼近真實場景：乘客請求包含出發地和目的地，電梯需完成接送全流程。
職責更清晰：外部請求類封裝乘客行程，電梯類負責執行移動和請求轉換。
不足：
仍未引入獨立的控制類，調度算法（selectNextCommand）仍在電梯類中。
輸入解析與業務邏輯混合，可進一步拆分。

類圖（簡化）：

三、採坑心得
1.類設計職責混亂：單類包辦導致的維護災難（題目1）
題目1的初始設計中，Elevator類承擔了狀態管理、請求隊列管理、調度算法、輸入驗證四大核心職責，代碼行數超過300行。例如，輸入解析的正則匹配、請求隊列的添加與去重、電梯移動邏輯、調度優先級判斷全部耦合在一個類中。
具體表現
當需要修改調度算法（如調整同方向優先邏輯）時，需改動selectNextCommand方法，但該方法與moveTo、processCurrentFloor等方法高度關聯，修改後出現“方向判斷失效”的BUG：電梯在處理完UP方向請求後，未切換至DOWN方向，導致反向請求一直未處理。
新增“重複請求過濾”功能時，需在addInnerRequest和addExternalRequest中添加判斷邏輯，但因類內方法過多，誤修改了getDistance方法的距離計算邏輯，導致電梯優先選擇遠距離請求。

類結構對比（問題vs改進）

心得
單一職責原則（SRP）不是“可選原則”，而是“基礎原則”。當一個類承擔超過2個核心職責時，維護成本會呈指數級增長。

2.請求隊列管理漏洞：重複請求與數據結構選擇失誤（題目2）
問題1：連續重複請求未過濾
問題描述
題目2要求過濾連續相同的請求（如<3><3><3>或<5,DOWN><5,DOWN>），初始設計使用LinkedList存儲隊列，但未判斷隊列尾部元素，僅簡單調用offer方法添加請求，導致重複請求被多次處理。

測試數據與結果

解決方案
在addInnerRequest和addExternalRequest中添加尾部判斷邏輯：

// 內部請求去重：判斷隊列尾部是否與當前請求相同
public void addInnerRequest(int floor) {
    if (!innerQueue.isEmpty() && innerQueue.getLast() == floor) {
        return;
    }
    innerQueue.offer(floor);
}

// 外部請求去重：重寫ExternalRequest的equals方法，判斷源樓層和方向是否相同
public void addExternalRequest(ExternalRequest req) {
    if (!outerQueue.isEmpty() && outerQueue.getLast().equals(req)) {
        return;
    }
    outerQueue.offer(req);
}

問題2：數據結構選擇錯誤導致的性能問題
問題描述
題目1中使用LinkedList作為隊列，但在selectNextCommand中需要頻繁獲取隊列頭部元素（peek）和計算距離，LinkedList的隨機訪問性能較差（時間複雜度O(n)），當請求數量超過10個時，調度延遲明顯增加。

性能測試數據

解決方案
將隊列改為ArrayDeque，其peek、offer、poll方法均為O(1)時間複雜度，同時保留尾部判斷功能（通過iterator反向遍歷獲取尾部元素），優化後調度效率提升75%以上。

3.調度算法邏輯缺陷：同方向優先原則失效（題目1-3）
問題描述
電梯核心運行規則“同方向優先”未正確實現，具體表現為：電梯在UP方向運行時，優先處理了DOWN方向的近距離請求，導致同方向請求被阻塞。

流程圖對比（問題邏輯vs正確邏輯）

測試用例與問題結果

解決方案
在selectNextCommand中強化方向判斷邏輯，增加“同方向且路徑可達”的校驗：

// 外部請求是否可達：方向一致且在當前路徑上
boolean outerReachable = (currentDir == Direction.IDLE) || 
                        (outerHead.dir == currentDir && 
                         ((currentDir == Direction.UP && outerHead.sourceFloor >= currentFloor) || 
                          (currentDir == Direction.DOWN && outerHead.sourceFloor <= currentFloor)));

同時，新增directionSwitchCount計數器，僅當2次切換方向後仍無可達請求時，才選擇最近的跨方向請求，避免頻繁變向。

4.外部請求與內部請求轉換錯誤（題目3）
問題描述
題目3要求“外部請求處理後，將目的樓層加入內部隊列”，初始設計中在processCurrentFloor方法中直接調用innerQueue.offer(processed.targetFloor)，未過濾重複的目的樓層，且未考慮內部隊列的優先級。

測試數據與問題結果

解決方案
複用addInnerRequest方法（已實現重複過濾），將目的樓層加入內部隊列，確保隊列中無連續重複元素：

// 處理外部請求時，調用去重後的addInnerRequest方法
if (!outerQueue.isEmpty() && outerQueue.peek().sourceFloor == target) {
    ExternalRequest processed = outerQueue.poll();
    addInnerRequest(processed.targetFloor); // 複用去重邏輯
}

額外問題：源樓層與目的樓層相同的無效請求
問題描述
輸入<3,3>（源樓層=目的樓層）時，程序未過濾該請求，導致電梯停靠3層但無實際操作，浪費資源。

解決方案
在輸入解析階段添加校驗：

// 外部請求解析時，過濾源樓層=目的樓層的無效請求
if (source == target) continue;
// 過濾超出樓層範圍的請求
if (source >= minFloor && source <= maxFloor && 
    target >= minFloor && target <= maxFloor) {
    elevator.addExternalRequest(new ExternalRequest(source, target));
}

5.狀態初始化與邊界條件處理缺失（題目1）
問題1：初始狀態未正確輸出
問題描述
電梯初始停留在1層，狀態為STOPPED，當第一個請求到來時，未輸出初始樓層和方向，直接從1層移動到目標樓層，導致輸出格式不完整。

測試結果對比

解決方案
添加isInitialStatePrinted標記，首次移動時輸出初始狀態：

if (!isInitialStatePrinted) {
    System.out.println("Current Floor: " + currentFloor + " Direction: " + currentDir);
    isInitialStatePrinted = true;
}

問題2：最小樓層≠1時的初始位置錯誤
問題描述
當輸入最小樓層為2時，電梯初始位置仍為1層（超出最小樓層範圍），導致處理請求時出現“樓層越界”的邏輯錯誤。

解決方案
初始化時將當前樓層設置為最小樓層，而非固定1層：

public Elevator(int minFloor, int maxFloor) {
    this.minFloor = minFloor;
    this.maxFloor = maxFloor;
    this.currentFloor = minFloor; // 修復：初始樓層=最小樓層
    this.currentDir = Direction.UP;
    this.currentState = State.STOPPED;
    // ...其他初始化
}

四、改進建議

1. 引入獨立的控制類（調度器）
   目的：將調度算法從電梯類中分離，實現“電梯負責移動，調度器負責決策”。
   設計：新增ElevatorController類，接收請求隊列，計算最優目標樓層，調用電梯的moveTo方法。
   優勢：支持多種調度算法（如FCFS、SSTF），可動態切換，無需修改電梯類。

2. 輸入解析與業務邏輯分離
   目的：將輸入解析移至獨立的InputParser類，負責驗證和轉換輸入為請求對象。
   設計：InputParser接收字符串輸入，返回Request對象（內部或外部），Main類調用解析器和調度器。
   優勢：支持多種輸入方式（如文件、GUI），業務邏輯不受輸入格式影響。

3. 乘客類的完整封裝
   目的：題目3中ExternalRequest本質是乘客的行程，可直接封裝為Passenger類。
   設計：

  class Passenger {]()
      private int sourceFloor;]()
      private int targetFloor;]()
      private Direction direction;]()
     // 構造函數、getter]()
  }(())

優勢：更貼近真實場景，支持乘客狀態跟蹤（如是否在電梯內、是否到達目的地）。
4. 多電梯調度擴展
目的：為後續多電梯調度預留接口。
設計：
調度器維護多個電梯實例，計算每個電梯的負載和距離。
新增ElevatorStatus類，封裝電梯的當前樓層、方向、隊列長度等狀態。
優勢：支持分佈式調度，提升系統吞吐量。
五、總結

學到的知識

1. 面向對象設計原則：深刻理解SRP的重要性，職責拆分可顯著提升代碼可維護性和擴展性。
2. 數據結構應用：根據需求選擇合適的集合（如LinkedList支持尾部操作，Queue保證FIFO）。
3. 狀態機管理：電梯的運行狀態（停止、移動）和方向切換需嚴格遵循邏輯，避免死鎖。
4. 問題迭代解決：從單類實現到職責拆分，逐步優化，每一步都基於前序問題的解決。

進一步學習方向

1. 設計模式應用：引入工廠模式（創建電梯）、策略模式（調度算法）、觀察者模式（狀態監聽）。
2. 多線程與併發：真實電梯系統需處理併發請求，需學習多線程同步和鎖機制。
3. 性能優化：多電梯調度中的負載均衡、最短路徑算法（如Dijkstra）。
4. 系統集成：結合GUI（如JavaFX）或Web接口，實現可視化調度。

建議

1. 課程方面：
   增加設計模式的講解和實踐，幫助學生理解如何將原則轉化為代碼。
   提供更多迭代式作業，逐步引導學生從簡單到複雜構建系統。
2. 作業方面：
   題目可增加開放性要求，鼓勵學生嘗試不同的調度算法。
   提供更詳細的測試用例，幫助學生驗證邊界情況（如無效樓層、併發請求）。
3. 實踐方面：
   引入代碼審查機制，讓學生互相評價類設計是否符合原則。
   鼓勵使用工具（如PowerDesigner、SourceMonitor）進行類圖繪製和代碼分析。

通過三次電梯調度程序的設計，不僅掌握了面向對象的基本技能，更理解了軟件設計的核心思想：職責清晰、結構合理、可擴展、可維護。這為後續更復雜系統的開發奠定了堅實基礎。