平台產品銷售收費機制的收銀系統 - 需求檢視

需求檢視

【作業】
針對平台產品銷售有不同的收費機制，該系統中有平台點數及平台幣（平台幣是主要扣款使用的幣別），依照不同商品及不同的用戶等級會有不同的收費模式。

主要收費模式會分成下列三種。
Ａ、正常平台幣收費
Ｂ、VIP會員有平台幣優惠價格 (例如: VIP1: 95折，VIP2: 9折，VIP3: 85折，各個等級的折扣會依照活動做調整。)
Ｃ、扣平台點數折抵平台幣優惠（例如：設定平台點數1:1折抵，則1000元商品可以使用100點扣抵扣在另外支付900元購買，折抵比例依照活動做調整。）

平台會不定時舉辦各式的優惠活動，活動時會彈性調整方案B及C的優惠內容。依照不同的活動內容可以排程調整活動。

1. 請使用Golang實作一個收銀系統（請考慮Clean Code及Design Pattern）。
2. 承上題，平台後來新增了另一個收費模式，如果有VIP身份扣100點以上折抵，另外享再九折優惠。（考慮SOLID）

作業以函式庫方式提交
作業時間一週

作業解析框架

讀懂需求

確認必須項目

• 實作一個收銀系統。
• 考慮三種不同的收費模式（A、B、C）。
• 收費模式需要能彈性調整。
• 新增的收費模式需考慮VIP折扣與點數折扣。

確認加分項目

• 支持多種活動和優惠。
• 系統能夠輕鬆擴充，添加新的收費模式或優惠。

規劃時程

設計時程 (2天)

• 了解和設計收銀系統的架構。
• 設計如何靈活地調整各種收費模式和活動優惠。

實作時程 (3天)

• 實作基本的收銀功能。
• 根據收費模式和優惠活動，加入相應的計費邏輯。
• 加入新的收費模式。

測試時程 (2天)

• 增加單元測試以確保每個功能正常運作。
• 執行測試，確認收費模式和優惠活動都正確計算。

重視Code的質量

SOLID原則:

• Single Responsibility Principle (SRP): 每個模組或類別只應該有一個原因引起變化。例如，不同的收費模式應該被分離成獨立的類別或方法，而不應該將它們混合在同一個模組中。
• Open-Closed Principle (OCP): 實體如類別、模組、函數等應該是可擴展的，但是不可修改的。考慮當您要增加新的收費模式或特殊優惠時，不需要修改現有的代碼，而是透過擴充來實現。
• Liskov Substitution Principle (LSP): 子類別必須能夠替換其父類別而不影響程式的正確性。使用繼承來實現不同的收費模式，確保子類別的實現不會破壞父類別的契約。
• Interface Segregation Principle (ISP): 不應該強迫使用者依賴他們不使用的接口。考慮為不同的收費行為提供不同的接口。
• Dependency Inversion Principle (DIP): 上游模組不應該依賴下游模塊，兩者都應該依賴抽象。使用介面或抽象類別來定義收費和優惠行為，並在上游模組中依賴這些抽象。

Gangs of Four (GoF)設計模式:

• 策略模式 (Strategy Pattern): 用於定義一系列的算法，將每一個算法封裝起來，並且使它們之間可以互換。這很適合實現不同的收費模式。
• 裝飾器模式 (Decorator Pattern): 用於動態地給一個物件增加一些額外的職責，適合實現不同的優惠折扣。
• 工廠模式 (Factory Pattern): 用於創建對象，適合於根據不同情況和活動創建不同的收費或折扣物件。
• 觀察者模式 (Observer Pattern): 如果您的系統需要對特定的活動或變更做出反應，例如當有新的優惠活動時，這個模式允許物件間建立一種依賴關係。
• 命令模式 (Command Pattern): 如果收銀系統支持如排程、撤銷或重做等操作，此模式允許將操作封裝成物件。

選擇合適的工具與技術

• 使用Golang的標準庫。
• 使用像GoMock這樣的模擬庫來寫單元測試。
• 使用Goland IDE

測試你的code

• 增加單元測試以確保收銀功能、各種收費模式和優惠活動都正確無誤。
• 考慮使用像Testify這樣的測試輔助來增強測試。

建立檢查清單

• [ ] 程式碼是否遵循SOLID原則。
• [ ] 所有的收費模式和活動優惠是否都被正確地實現。
• [ ] 是否所有功能都有單元測試。
• [ ] 確保新的收費模式不會破壞既有功能。
• [ ] 檢查是否所有測試都通過。