先講結論:
我反對原文的結論「OOP易學難精」
就我個人到現在的感受是「難學易精」
為什麼呢?
以下分享個人看法
不管是不是OOP，其實種種軟體層面的架構手段主要都是想解決一個問題
「讓一個龐大複雜的軟體專案變得更好維護」
這又可大概分為兩個方向
1. 可擴充性
面對新需求時會不會難以改動，是不是每次加功能都要改一堆地方?
常常動一個小地方，造成其他看似無關的模組壞掉?
2. 可維護性
程式碼的邏輯是不是很好理解
會不會一個新人來看幾個禮拜還是黑人問號
每一份檔案、類別、函式
甚至到每一行程式碼的目的，是不是都足夠明確
當然，以上兩點是有相關的
這兩點的重要性，就算是剛上班幾個月的新手，也是非常容易理解
而OOP裡面的什麼pattern、什麼SOLID原則
其實說穿了也都是在讓程式更好維護和擴充而已
「難學」，是因為一開始接觸OOP，因為其概念繁多
如果沒有掌握核心思想很容易就被各種各樣的名詞給唬住
「易精」，是因為那些繁雜的概念其實都只是手段，目的是很明確易懂的
OO的核心觀念：「抽象化」
是為了讓外面的使用者只看到必要的介面
不受內部細節的改動影響
而實作者只在乎如何滿足定制好的介面
至少80%的design pattern，都是在告訴你該怎麼把抽象化做好
factory pattern
告訴你創造物件的邏輯要抽象化，外面就不必在乎實作類別的改動
strategy pattern
告訴你行為的抽象化可以用組合，達成更好的解藕並可在runtime時更換
iterator pattern
告訴你聚合類的物件可以提供一個抽象的介面
讓使用者不須關心內部時做的資料結構就可以存取所有item
另外所謂好的程式碼，怎麼會是junior沒辦法分辨？
要是你用了很多OOP的手段，但是沒辦法輕易解釋得讓你們公司的新人聽懂這樣做好處是
什麼
那大概就是你認為的好code其實沒那麼好
沒有搞懂OOP在幹嘛，以為只是把code放在class內就算OOP
然後又看到原文這種似是而非的觀念，我是不認為會有什麼幫助
以原文提到的service object為例
的確這是一個有爭議的pattern
但要說他沒有內聚性是一件很奇怪的事情
service object其中一目的就是把domain相關的邏輯集中起來
這些邏輯本身就是緊密相關的
要用文章內提到CR值去說他沒有內聚性，真的是怎麼看怎麼怪
真的很講究OO，拆類別的時機也不應該是參數重複出現什麼的
而是現有class的職責太多吧
最後
其實軟體架構的名著Clean Architecture
就已經很豐富又很好懂了
每個階段看都有不同的感受
真的有想搞懂OOP應該去弄一本來讀讀
而不是在這邊算什麼CR值...