Composite pattern
邊看 golang 邊把 DP 再複習一遍…QQ
references:
簡單來說：「目錄可以包含很多檔案，每個檔案也可以是個目錄。」算是 Composite Pattern 最直覺的 case 。
目錄是 Composite class，檔案是 Leaf class ；Component 是共同抽象出來的「介面」。(Java 可以用 abstract class 或 interface 來實作)
teddy 寫的 concept 裡面有提到 transparency & safety 的問題(不過他用 clip 的例子不是很好…然後我在 DP 原書裡面並沒有看到這個 o_o)，以 檔案-目錄 的關係來說，目錄可以 add() 其他子目錄或是檔案，在強型別的語言中， add 可接受的型別必定是 Component 。(弱型別像 Python 就其實不用管XDD)
transparency 的意思是， Component 定義了只有 Composite 可用的 methods (像是 add(), remove() 之類的)，這樣在 nested add() 的時候就不用轉換型別。(be treated atomically)
safety 的考量是 add()/remove() 對 Leaf 來說是無效的(refuse)，實作上不是引發例外就是裝作沒這回事(silent failed, usually bug here lol)，這樣的行為對 client 來說是不安全的。
golang 的兩個版本剛好體現了這個問題。
這邊的 trick 是 transparency & safety 到底該選哪個才對？
以 Refactor 的想法，不要有 bad smell 的情況下 add(), remove() 等 methods 必然只該出現在 Composite 裡面，但這樣的實作對強型別的語言來說就會有轉型的消耗。
(印象中 Java 轉型還蠻耗資源的, Python 不用轉型科科)
