回憶需求可以參考 Day 16. 來做個 TypeScript 專案吧

今日重點：

• review 我們這個小專案做了什麼

<20230928> 日記，教師節快樂

這個鐵人賽的初衷是想要藉機整理之前學習 TypeScript 時所做的個人筆記

每天要寫的時候才在想今天應該寫到哪邊比較合適，除了一天不能放太多內容之外還要考慮當天的精神狀況，如果那天真的超累，那天的文章就會像是開著自動導航完成，有些現在回去 Review 都有點羞恥，下次參賽還是先規劃好要發的文章結構比較合適

講上面那些是因為發現我做的這個 TypeScript 小專案的筆記已經到頭了耶，我都沒發現，原來已經結束了呢！

但如果要把後面筆記下一個規模比較大的範例專案拿出來寫的話，到最後一天前大概是寫不完

所以從明天開始後面內容應該會回歸初衷，回到這篇鐵人賽的主題：
Rayeee 的 TypeScript 的學習日記

簡介有提到

日記為主，TypeScript 為輔，面向自我挑戰的 30 天鐵人賽。

明明是日記為主，阿日記呢？從第 10 天開始好像就消失了，每天產出文章也太累了吧，誰要每天寫日記阿

所以後面我會找回這篇鐵人賽的初衷，把一些對於工作、對於程式、對於有興趣的事情寫成一些日記，也看到這行字的人，我們一起走到最後一天吧

今天來把這個 <TS 專案> 做個收尾

目前的內容
<20230917> Day 16. 來做個 TypeScript 專案吧
<20230918> Day 17. <TS 專案 01> 小小的專案結構
<20230919> Day 18. <TS 專案 02> 還是無情的環境建置
<20230920> Day 19. <TS 專案 03> 番外篇. 手把手引入 Google Maps API
<20230921> Day 20. <TS 專案 04> Type definition file
<20230922> Day 21. <TS 專案 05> 開始進入 class + 來讀個文件吧
<20230923> Day 22. <TS 專案 06> 完善所有的 class 吧
<20230924> Day 23. <TS 專案 07> 將地圖加上標記功能吧！
<20230925> Day 24. <TS 專案 08> 隱藏功能！
<20230926> Day 25. <TS 專案 09> 秀出彈窗吧！Showing Popup Windows！
<20230926> Day 26. <TS 專案 10> 來做個小優化吧

這個 TypeSript 小專案我們就這樣默默進行了 11 天

在這個 TypeScript 小專案中，我們除了 TypeScript 的基本用法之外，我們還學到了

• 建置一個 TypeScript 環境
• 如何在專案中使用 Google Maps API
• TypeScript 專案中可以使用 JavaScript Library，但是需要有 Type definition file，Type definition file 可以想像是定義那個 Library 的 Type，除了給 TypeScript 看懂型別之外，我們開發者也可以藉由 Type definition file 更了解 Library 的用法

快速 Review 我們的 TypeScript 小專案

1. Hide on Functionality！

對於 class 來說，我們會希望可以限制外部人士 (包括你同事) 可以使用的 class 屬性和方法，外部人士能使用的都是經由我們設計或有審閱過可行的方法。

就算我們專案本身有引入第三方模組像是 Google Maps，我們也一樣不希望其他同事能使用 Googoe Maps 中，我們沒有審閱過、用了不確定會不會影響到專案其他地方的方法

所以我們會像這天用的方法一樣 <20230925> Day 24. <TS 專案 08> 隱藏功能！ ，把那些方法隱藏起來

但，這些方法只要是開發者當然還是看的到，點到我們檔案就看到了，但會建議還是這個限制做好，讓這個檔案、這個 class 什麼屬性、methods 該用什麼不該用可以讓其他人知道就好。

2. 自定義 interface 的依賴關係

<20230924> Day 23. <TS 專案 07> 將地圖加上標記功能吧！ 這天我們在地圖 class Map 加入了比較直覺的方法 addUserMaker 和 addCompanyMaker 方法

然後在 來優化相似方法吧 這個段落把它們合併起來變成 addMaker ，最後因為傳入參數除了是 User 或 Company 未來還可能越加越長，所以把傳入參數寫成一個規格 interface Mappable

interface Mappable { 
    location: {
        lat: number;
        lng: number;
    };
}

這邊的重點是：不是 interface 去滿足各個 class，而是 interface 告訴其他 class 說，嘿！你們要使用我的方法嗎？那你就要滿足甚麼規格、這些是你要做的

我們的 interface 告訴其他 class 必須做甚麼才能成為能夠傳入 addMaker 的一個參數
如果這個想法成功的話，我們就可以低耦合的重用 code

3. 我們希望能在正確的地方看到 TypeScript 的錯誤提示

在這天 <20230926> Day 26. <TS 專案 10> 來做個小優化吧 ，我們在 class 裡面導入 interface，告訴 TypeScript 我們希望 class User 實例能夠與 interface Mappable 兼容，使用了 implements 語法

這個又更不一定要使用了，只是一種優化建議，可以幫助我們或其他開發者直接的知道，我們希望這個 class 滿足甚麼型別格式，並可以快速的定位錯誤位置