先讲结论:
我反对原文的结论“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值...