Clients should not be forced to depend on methods that they do not use.

昨天定義好的函式，可以當作變數來使用。

一樣要考古一下原文：

Subtypes must be substitutable for their base types.

大家在使用 Laravel 或是其他套件時，相信都用的非常開心。

但是否有想過，為何這些套件會這麼好用？新增功能，加個檔案就行了；修改功能，加個檔案就行了；移除功能，改個設定就行了。怎麼會這麼簡單？

而為何自己做的共用套件卻是常常被人嫌？該要有的功能都實作出來了呀，一樣都是共用，為何命運大不同？

這些套件會有這麼多 Star，當然是有原因的。

首先，套件是需要精心設計的。它們會遵守物件導向設計原則，做出適合擴展的設計，大家才能順利寫出客製化功能。

再來，不僅要有設計，也要有夠完整的測試。測試除了測功能，確保套件行為正常之外，還會測「身為開發者，會如何使用程式」；同時，測試也會是最好的範例文件。

最後還要有簡單易懂的說明文件，才能讓路過的開發者，在最短的時間理解套件的功能，並可以知道套件是否適用於自己的專案上。

以開發者為本

無論是設計、測試或是文件，都是針對多數開發者需求而做的，也因此，大家才能夠愉快地開發。身為一個開發者，先對所有開源作者致上十二萬分的敬謝之意。

往後的日子裡，會開始研究套件的設計，了解巨人的肩膀是如何實作出來的，期望自己在提升設計能力之後，有朝一日也能成為開源作者的一員。

在我們 Hello World 的練習裡，曾提到一點點函式的定義，今天要來詳解它。

原文定義是這樣子的：

Software entities (class, modules, functions, etc.) should be open for extension, but closed for modification.

許多語言都有提供 key-value 存放方法的 map 結構，Go 使用內建型態 map 實作。

map 型態的表示方法為：map[keyType]valueType，map 是關鍵字，keyType 必須是可比較（Comparable）的型態，如 string、int 等，valueType 則是內容形態。

雖然軟體量測很方便，也能找到很多可能有問題的程式碼，但最終還是需要人工檢查程式的設計。這時就需要原則（principle），讓檢視過程能有正確的方向。

Slice 跟陣列使用起來很像，而最大的不同是，陣列是值，Slice 是參考到一個陣列。

寫出好維護的程式要靠經驗累積的，初學程式經驗少，因此容易寫出有壞味道的程式。而有經驗的開發者，看到壞味道一定很敏感。但是檢查原始碼的狀況，也是得看人品。運氣不好，一個 commit 上千行，味道千奇百怪，依賴錯縱複雜，想提修改建議也不知從何講起。