由於第一份作業Refactor的時間會比較久一點，加上這份作業新版的有指定語言(TypeScript, NodeJS)，現在會先分析review完所有作業再來做refactor。

Candle Stick Reconciliation

作業需求：

Task: Crypto.com API Reconciliation
Given Candle Stick API , please design and develop a Java Application with JUnit5 unit test cases to verify the consistency of the output of Trade API

Time for completion: 24 Hours

Hints for the Task

1. What is candlestick

2. An example candlestick, visually

3. At minimum, we would like your solution to verify the consistency of the candlesticks in terms of
   its attributes: O, H, L, C. Be careful on number handling. To verify consistency between a
   1-minute Candle Stick Vs Trade, for a given minute:
   a. If the minute has only 1 trade, expect O, H, L, C to be the same as the price of the trade.
   b. If the minute has only 2 trades, expect that
   i. O is the price of the first trade
   ii. C is the price of the last trade
   iii. H is the highest price from the 1st trade and 2nd trade
   iv. L is the lowest price from the 1st trade and 2nd trade

4. To get started, you can start verifying the consistency of a 1-minute candlestick of BTC_USDT,
   think about what the required data are to verify the consistency of the candlestick, and how to
   obtain the data. To save time, you can verify the most recent verifiable few bars from the
   candlestick.

5. You can think about how to generalize the program to handle different instruments / time-periods,
   e.g. (5-minute chart, 15-minute chart, etc).

6. You are expected to handle / judge whether incomplete data is a real issue or you need to handle it.
   Hints for the Code

7. Please focus on reusability, readability, scalability, and clean coding principles.

8. Provide sufficient comments where necessary.

9. Please feel free to use any third-party libraries.
   Deliverables
   Code and documentation, into a single zip file named <your_name>_software_engineer_exercise.zip
   ● Design and test cases
   ● Sample test run output
   ● Readme for installation / setup guide: Please use maven / gradle.
   ● Source code
   ● JDK 11 or above is required

作業解析框架

讀懂需求:

建立一個Java應用程式來確認Trade API的輸出與Candle Stick API的一致性。
使用JUnit5進行單元測試。

確認必須項目:

• 程式必須檢查蠟燭圖的一致性，包括O, H, L, C屬性。
• 能夠對不同時間範圍的蠟燭圖進行一致性檢查。
• Code必須是可讀的、可擴展的、可重用的，並遵循良好的編碼原則。

確認加分項目:

• 程序的廣泛性，例如能夠處理不同的金融工具/時間段。
• 處理不完整或缺失的數據。

規劃時程:

設計時程 (5小時):

• data model設計。
• 定義API呼叫的邏輯和方法。
• 定義測試策略。

實作時程 (12小時):

• 實現核心功能。
• 實現API呼叫功能。
• 實現data一致性檢查功能。

測試時程 (5小時):

• 單元測試。
• 整合測試。
• 錯誤修復。

重視Code的質量:

SOLID原則:

• Single Responsibility Principle (SRP): 服務應該將API呼叫、資料一致性檢查和測試功能分開。例如，API呼叫和資料一致性檢查分成不同類別。
• Open/Closed Principle (OCP): 當增加新的金融工具或時間段時，服務應該容易擴展，而不需要修改現有程式。
• Liskov Substitution Principle (LSP): 如果有多種一致性檢查策略，則它們應該可以互換使用，不影響服務的執行。
• Interface Segregation Principle (ISP): 如果服務有多個功能，應為每個功能創建獨立的接口，而不是一個包含所有方法的大接口。
• Dependency Inversion Principle (DIP): 服務應依賴於抽象，而不是具體的實現。例如，對API呼叫或資料存儲的具體實現進行抽象。

Gangs of Four (GoF)設計模式:

• Strategy Pattern: 由於有多種一致性檢查策略（例如，當一分鐘內只有一次交易時，或當一分鐘內有兩次交易時），可以使用策略模式來選擇合適的一致性檢查方法。
• Factory Pattern: 當需要基於不同的金融工具或時間段來創建對象時，可以使用工廠模式。
• Observer Pattern: 如果將來要在檢測到不一致性時觸發某些操作或通知，可以使用觀察者模式。
• Decorator Pattern: 如果需要在基本的一致性檢查之上增加額外的功能或行為，例如日誌記錄或錯誤處理，可以使用裝飾器模式。

選擇合適的工具與技術:

• 使用JUnit5進行單元測試。
• 使用Retrofit或OkHttp進行API呼叫。

測試你的code:

• 單元測試: 測試單一功能或方法的行為。
• 整合測試: 測試整個系統或其部分的集合。

建立檢查清單:

• [ ] API呼叫功能。
• [ ] 資料一致性檢查。
• [ ] 處理不同時間範圍的蠟燭圖。
• [ ] 處理不完整或缺失的數據。
• [ ] 程式質量。
• [ ] 測試覆蓋率。