作者as30385438 (LCH)
看板Soft_Job
标题Re: [分享] 用一个简单的数学公式来帮忙设计OOP类别
时间Wed May 20 01:37:45 2020
先讲结论:
我反对原文的结论「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值...
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 58.114.218.170 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1589909867.A.FFC.html
1F：推 trojan: 很棒，言简意赅 05/20 01:53
2F：推 onegoman: 推 05/20 02:16
3F：推 bibo9901: 推，那个CR值跟本垃圾 05/20 02:25
4F：推 tmacmm: 不能同意更多了 05/20 03:08
5F：推 gn1943141: 认同本篇除了难学易精，很多设计大家都知到，但实作不 05/20 08:00
6F：→ gn1943141: 一定能写出漂亮的架构 05/20 08:00
7F：推 qrtt1: Clean Architecture 新手要看有点吃力，但随着经验增加会 05/20 08:44
8F：→ qrtt1: 越来越上手的。前阵子也试着练习了一下，还写了个记录 05/20 08:45
11F：推 t64141: 同意 05/20 09:45
12F：推 vi000246: 同意 oop是用来解决问题 不是制造问题的 05/20 09:45
13F：→ vi000246: 能解决问题的都是好OOP 05/20 09:46
14F：推 Masakiad: 如何把抽象做好比较接近SOLID，DP是延伸SOLID应用，如 05/20 10:09
15F：→ Masakiad: 何在遇到或设计初始选用适合的DP，背後包含整体架构上、 05/20 10:09
16F：→ Masakiad: Domain Knowlege、Force等等得考量。跟单纯探讨把抽象 05/20 10:09
17F：→ Masakiad: 做好算不同层次的概念。 05/20 10:09
18F：推 bnd0327: 大家可能被KPI压榨怕了，但我觉得拿来自己比较还好啦 05/20 11:02
19F：→ bnd0327: 另外推这篇观念清楚 05/20 11:02
20F：推 strlen: 另外提醒SOLID和DP都是要「看情况」用的 不要以为一直用一 05/20 11:56
21F：→ strlen: 直爽 OOP写过头是会有over design的症头的 而且这症头还不 05/20 11:56
22F：→ strlen: 地方有 甚至很多知名开源专案都是一堆没必要的design 05/20 11:57
23F：推 coder5566: 推，好文 05/20 12:23
24F：推 yyhsiu: 很同意「目标」，不要把教科书上的全部照搬就觉得是 clean 05/20 15:18
25F：推 genius945: 推，都是为了达成目标的手段 05/20 20:57
26F：推 alihue: 你的难学在指写，精在指读懂 05/20 21:11
27F：推 virgil246: 借串问 那clean code需要读吗？ 05/20 22:49
28F：推 fantasychese: 建议先读clean code就好 clean architecture去看 05/21 01:52
29F：→ fantasychese: Uncle Bob原始演讲 後来出的书其实写得不怎麽样 05/21 01:53
30F：→ electgpro: 你的精可能只是别人认为的初阶而已 05/21 06:34
31F：→ electgpro: 关於 clean code，我刚读完觉得很不错，现在觉得比较 05/21 06:36
32F：→ electgpro: 像心灵鸡汤 05/21 06:36
33F：→ abc01251: 同意～说穿了所有Pattern目的都一样 05/21 12:36
34F：推 paul7751: 推 好文 05/21 17:05
35F：推 art1: 看过高手写的 java 程式才第一次了解到 OOP 的威力，好读好 05/21 19:08
36F：→ art1: 懂好修改 05/21 19:09