Athenz 基本運作概念與相關名詞

在 Athenz 權限系統中，有幾個比較重要的基本概念和名詞，簡單記錄一下。不過在那之前，因為 Athenz 的結構幾乎跟 AWS IAM 一樣，所以可以先討論一下 AWS IAM 的運作方式 [1]，再回來看 Athenz 對應的概念。而且其實我覺得 AWS 的文件整體來說寫得比較好 XD。

Athenz 的授權流程

Athenz 是 Yahoo 開源的權限系統 [1]，基於 X.509 Certificate 的架構來提供權限認證的功能。運作上跟 AWS IAM 蠻類似的，是以 Role 為基礎，透過指定某個 Role 對某個 Resource 允許或拒絕某些 Action 來達成授權行為。

plugin execution not covered by lifecycle configuration

公司的 Maven Plugin 在 eclipse 上會跑出標題的錯誤訊息，實際上問題好像是出在 m2e plugin。幾種不同的解法可以參考 [1]。比較完整的做法似乎應該在 dependencyManagement 上追加設定，不過因為在公司裡只有我用 eclipse，其他同事都用 Intellij....所以目前是直接從 eclipse 的 Maven 設定處把這個錯誤忽略掉 XD。

具體來說，就是從 Preferences → Maven → Errors/Warnings → 在 plugin execution not covered by lifecycle configuration 處選擇 “ignore”。

參考資料

1. Maven —— Plugin execution not covered by lifecycle configuration 错误

(書籤) Factory 的比較

參考資料

1. Design Patterns: Factory vs Factory method vs Abstract Factory
2. 白話 Design Pattern (二) Simple Factory, Factory Method
3. Design Pattern 比對(2) Factory Method和 Abstract Factory的異同

繼承（Inheritance）與合成（Composition）

在 Design Pattern 的書裡，大概都會提到「多用合成、少用繼承」，不過具體來說到底繼承會產生什麼問題、合成又能解決什麼問題，一直到現在才有比較明確的感覺。但由於不太擅長描述這種有些抽象的問題，所以這裡就簡單地紀錄一些感覺到的重點，細節就請參閱底下的參考資料吧 XD。

首先，一切的源頭都是為了 OCP（Open-Closed Principle），也就是要盡可能滿足「對擴充開放、對修改封閉」這樣的準則。不過要滿足這個準則，其實會讓程式碼變得複雜，所以在選擇的過程也必須謹慎小心，盡可能只在真正需要的地方去滿足，而不要把這個準則套用到整個系統的每個角落 [1]。

在考量 OCP 的前提之下，由於繼承是屬於在編譯期間的關聯，因此很容易會導致使用繼承時，擴充會需要修改既有的程式碼。這就會導致違反了 OCP 當中的「對修改封閉」的要件。

另外繼承在可能性眾多的情況，也很容易導致子類別的數量爆炸，造成日後維護的困難。

反過來說，合成是屬於在執行期間的關聯，因此較有機會可以避免上述的問題。不過依據狀況的不同，合成也有可能形成子類別較多的現象，雖然不至於到數量爆炸的程度，但往往也會使得 API 變得難以掌握。這類的問題就得複合多種 Design Pattern 來隱藏問題，讓呼叫者不需要對細節有太多的了解。

不過同時也需要注意的是，雖然說概念上提到「少用繼承」，但使用合成其實並不表示完全不使用繼承。關鍵在於「不繼承行為」，但合成常常會需要「繼承型別」（然而這或許只限定在像是 Java 這類強型別的語言上）。

參考資料

1. 深入淺出設計模式
2. 物件導向程式設計：為何說composition優於inheritance？
3. 請問，為什麼要『多用合成，少用繼承』? (java程式語言)
4. 省思物件導向設計 第2回－ 物件導向設計方法面臨的問題