作者csfgsj (流水贯通)
看板Soft_Job
标题Re: [请益] 比物件导向更先进的程式设计思想？
时间Thu Oct 8 16:21:31 2020
※ 引述《dharma (达)》之铭言：
: 现在很多新出来的程式语言，(如Swift)，从本质上说，都是物件导向语法，这是因为近
: 几十年来，从来没有比物件导向实现更先进的程式设计实现在新程式语言中全面取代物件
: 导向思想。
: 上面是某程式语言教学书看到的
: 他说的符合实情现况吗？
这当然是唬烂，听过愚民教育吗？ 听过蓄奴吗？
物件导向就是大公司的阴谋
方便它们做一些黑箱框架，以及骗一些人进来，当它们框架的依赖者
物件导向的语法设计，会让你很难去挖掘框架後面的东西
用的人只会越来越没有思想，越来越依赖框架
最後变成离不开框架，任大公司宰割的韭菜
: 一直没有更先进的东西崭露头角
: 可能取而代之
: thanks
就看 A公司跟 G公司彼此要杀到什麽时候了
G 公司的保护费最近也涨成跟A公司一样了，都是 30% 的抽成
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 218.32.249.24 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1602145295.A.198.html
1F：→ stkoso: 所以更先进的设计是什麽 10/08 16:31
不在语法的层次，在架构观念的层次 等你有了架构观念，看OO就是一坨屎
2F：推 ataraxia: 怎麽OOP讲着讲着迁怒到框架去了@@ 10/08 16:34
不用框架，那用OO就没意义了
3F：推 chuegou: 要这样讲的话 依赖高阶语言但不懂组语和编译器不也算吗 10/08 16:43
高阶语言本来是没有OO的，高阶语言与OO是两回事
你一定没有分清楚那些功能性语法，那些是编辑性语法
4F：→ sniper2824: 不会用0跟1写程式的都自杀好惹 呜呜 10/08 16:56
5F：嘘 goldflower: 好久没看到 此id必推 推爆 10/08 17:04
我知道版上 有些教JAVA的补教业者很讨厌我
6F：→ shooter555: 所以你写扣都不用物件导向? 10/08 17:06
我写过MCU的FW，Linux 跟 Windows Device driver，EC, Bios, Web 前端跟後端
从来不用OO。除非接别人的BSP，那还是会看一下
7F：嘘 plsmaop: Linux 的 VFS 不是很 OO 吗 10/08 19:04
Linux 的 VFS 是各式档案系统的对上层的统一介面，干OO什麽事？
8F：→ stkoso: 所以更先进的架构观念是什麽 10/08 19:04
9F：→ leo5916267: 改用 oh oh p啦 10/08 19:22
10F：推 kingofsdtw: linux没很oo吧 10/08 19:30
11F：→ x246libra: 看起来，你觉得oop不好的原因是隐藏实作，只依赖抽象 10/08 19:34
12F：→ x246libra: 介面，这样很糟糕，我有理解的楼主的意思吗？ 10/08 19:34
所有的 Api 都是隐藏实作，让使用者以一种比较抽象简化的概念来调用它
OO的问题不在这里，Class将资料与函式绑在一起，基本上是违反人的思维模式的
由於违反人的思维模式，所以人就无法赋予它一个清楚的抽象简化概念
调用的时候，就会感到不知道在做什麽，说穿了，Class语法就是个黑箱妖怪制造机
那些基於OO的框架，就是会让调用者搞不清楚在调用什麽，只能用使用经验来熟悉它
无法推理及创新，这就是那些大公司要的结果，你只能依赖它，却难以解析、评论它
当有人说它好棒棒，你也无法判断是真是假
13F：→ x246libra: class我觉得分成纯资料跟物件，物件的method强调抽象 10/08 20:27
14F：→ x246libra: 行为，这点跟api介面有不同吗？还是说你指的是，有人 10/08 20:27
15F：→ x246libra: 把class弄成，半资料半物件的形式？这样的话当然很糟糕 10/08 20:27
16F：→ x246libra: 如果是基於fp的框架，使用者难道就可以知道他们在调用 10/08 20:31
17F：→ x246libra: 什麽吗？跟oo或fp有关系吗？ 10/08 20:31
18F：→ x246libra: 有点微妙，api就是高阶抽象隐藏实作，oo变成黑箱妖怪， 10/08 20:32
19F：→ x246libra: 这两者的差异是？ 10/08 20:32
差异在於人脑对抽象这件事运作方式
人脑可以对动作认知(吃饭、睡觉)的作抽象，
人脑可以对资料包裹(表单、身分证)的认知作抽象
但是人脑无法对「动作+表单」这个不知所云的东西作抽象
抽象这个动作，能将一堆东西，简化成一个很小的点，
所以抽象这件事，对於人脑在分析一个大系统的时候，非常重要，也是唯一的手段
当人脑无法作抽象的时候，麻烦就大了，万事都要从细节里去找答案，那就完蛋了
20F：推 chuegou: 同楼上 我上面推文意思就是高阶语言隐藏了实作 10/08 20:36
21F：→ chuegou: 像是registor隐藏了电路实作 driver隐藏了registor实作 10/08 20:36
电脑的周边装置就是机器设备的概念，它就是一个对於人脑来说，
一个很好处理的抽象概念
Register 就是周边装置的控制钮，也是一个很好处理的抽象概念
这边没有OO的Class，抽象概念很好处理
22F：→ x246libra: 为什麽我有一种感觉叫做 我认定可以抽象的才是抽象 10/08 21:30
23F：→ x246libra: 如果觉得表格+动作 对你来说不好抽象 可以换一种表达 10/08 21:31
24F：→ x246libra: 表格+动作 有种资料库驱动设计的感觉 试试 DDD ? 10/08 21:32
25F：→ x246libra: 领域驱动设计 10/08 21:32
抽象本来就是人脑的主观，人脑的运作模式
人脑好处理的东西，就是好东西；人脑不好处理的东西，就是烂东西
你们不是爱讲什麽「内聚性」、「耦合性」吗？
那是来自人脑的感觉，还是电脑的感觉
「内聚性」、「耦合性」不好的程式也是会动呀！
问题是看程式的人，脑子会烧坏呀！
好笑的是Class本身就是一个在破坏体系「内聚性」、「耦合性」的妖怪
除非你的脑袋真的异於常人，那我也只能认了
DDD 是通例，还是特例？如果是 Corner scenario 那或许有可能
如果一体适用，那就是灾难的开始
26F：→ lovez04wj06: 看不懂在讲认真的还是在反串..... 10/08 21:45
27F：→ lovez04wj06: 东西好不好不是就看用的人怎样用，过分使用或者斥之 10/08 21:46
28F：→ lovez04wj06: 以鼻不是都是最糟糕的行为吗。 10/08 21:46
29F：→ lovez04wj06: 今天我只是要输出一个a+b=c 10/08 21:50
30F：→ lovez04wj06: 拿OOP的东西来用，那就叫神经病。 10/08 21:50
31F：→ lovez04wj06: 今天有继承封装的需求，订定规范框架或者是特殊的需 10/08 21:50
32F：→ lovez04wj06: 求，那他就是很好的工具，不就是这样而已吗？ 10/08 21:50
你说的很对，这就是我最上面说的「大公司的阴谋」呀！
如果你是Code Owner，Code 的领主，你希望有一堆农奴来使用你的code
但又不希望这些码农奴来了解你的Code，批评你的Code，改你的code，最後取而代之
OO不就是个最完美的解决方案吗？
我最初的发言是以码农奴的立场来看的，我只是在说明这个产业的生态
你也可以说它就是个工具啦！只是不要忘了它後面还是有商业目的存在的
它需要农奴，它需要有人为它抬轿
看看对面的华为，不就是这样进了圈套，那一天领主翻脸，就被搞死的吗？
33F：推 okd: 好久不见的ID耶 哈哈 10/08 23:29
34F：推 CoNsTaR: 出桶了？ 10/09 00:07
35F：推 ldkrsi: 看起来像阴谋而已吧 我觉得比较像工程圈追求传统工厂般的 10/09 00:19
36F：→ ldkrsi: 生产模式 用oop的观念比较可以接近多请一个人生产效率就会 10/09 00:20
37F：→ ldkrsi: 增加 在没有软体设计方法的上古时代 常常有技术上数学上 10/09 00:21
38F：→ ldkrsi: 可行的产品 但请再多人加再多硬体都完成不了的状况 10/09 00:22
39F：→ ldkrsi: 现代不只oop还有各类开发方法被提出 一般应用型产品从无到 10/09 00:22
40F：→ ldkrsi: 有常常就只是工作人数和开机器的问题 10/09 00:23
41F：推 ldkrsi: 高阶到一定程度的人一定知到oop并不万用啦 只是在老板和 10/09 00:26
42F：→ ldkrsi: 金主的压力下大多会选择商业界惯用的方法来处理 10/09 00:26
商业利益与逻辑理想的冲突，知道这个情况就好，不用全押下去
43F：推 qscesz1456: 商业考量啦 没你讲的那麽黑暗 10/09 00:33
44F：推 iiiii: 把一块memory space当成object，到处都见山 10/09 01:25
45F：推 yyhsiu: 听起来问题不是OOP，而是你用OOP的方法跟目的？ 10/09 02:27
46F：→ sorryla: 复制贴上大师又出现啦 10/09 02:45
47F：→ superpandal: 明白楼主的想法 就是在说明不直观又注重细节 框架中 10/09 09:27
48F：→ superpandal: 耦合又非常严重 10/09 09:27
49F：→ superpandal: 个人也不爱 只是某势力实在太庞大 10/09 09:29
50F：→ superpandal: 不过还是算了吧 如此free style的东西还是用在自己的 10/09 09:40
51F：→ superpandal: 产品上最好 给人打工free time有就好 10/09 09:40
52F：→ strlen: 完全没用到一丁点OO概念的web前後端喔....呵 这边也流行 10/09 23:35
53F：→ strlen: 幻想文是ㄇ 10/09 23:35
54F：嘘 w0005151: 不管甚麽领域都有这种抱持阴谋论的人出现 10/10 01:53
阴谋论其实是带有一种臆测的意味存在
曾经待过某大IT外商，以技术部门的角色与 Marketing 部门的人开会
听过很多次它们这样说
它们需要的是可以让客户产生依赖性，并且无法转台离开他们的产品
这样够明显了吧！
以商业的法则来说这样没错，或许我应该改口说，这根本就是一种阳谋
要不然为什麽A公司跟G公司要各搞各的App框架呢？(就是不想让你转台呀！)
为什麽两家不统一一下，这样大家都省事，不是很好吗？
大陆那边都开始搞自己的App Store了，为的是什麽？打破控制及垄断呀！
55F：→ superpandal: 基本上楼主讲的开发方式本来就存在 自私且壮大到一定 10/10 06:58
56F：→ superpandal: 程度确实可以称作是阴谋没错 10/10 06:59
58F：推 wulouise: 今天简单的架构不能快速解决，框架复杂化是必然结果 10/10 22:13
59F：→ wulouise: 原po可以给不用oo然後很好看懂的github repo吗？想了解 10/10 22:15
老实说，我不太相信 你不知道那边有，但还是随便贴两个给你
https://github.com/torvalds/linux
https://chromium.googlesource.com/chromiumos/platform/ec/+/refs/heads/master
60F：推 wulouise: 产生依赖性就表示简易操作解决了复杂问题，这是oo的概念 10/10 22:19
不懂这句话的意思
※ 编辑: csfgsj (36.229.5.174 台湾), 10/10/2020 22:34:16
62F：→ RumiManiac: 其实 Linux kernel 也是会用 OO 10/11 10:24
Linus Torvalds 听你这样说，一定会吐血
这是一种概念的曲解，你说它是OO，我说不是呀！
VFS 是针对不同的档案系统，赋予一个统一的操作介面
上层的调用者，可以用同一套操作的概念method，来操作不同的档案系统(Volume)
不要忘了，在操作这些概念method时，FS type 也是要事先指定清楚的
实际指到的实作Function，也是FS type specific的
这种函式指标包裹的struct，就像是棒球队的守备名单一样
虽然守备位置(捕手、投手、一垒手、外野手等)是固定的(function pointer name)
但是每一个棒球队都守备人员是不同的(function)
在棒球开赛前，每一队教练就要上缴队员守备名单给裁判(register struct)
这样的作法在Device Driver 里到处可见
开赛前，上缴队员守备名单给裁判，就是所谓的初始化过程(init)
你可以去挖Linux kernel的main() 的来看，一堆这样的东西
如果你有这样的抽象概念，就不会想去用OO这种不沦不类的东西来去套它了
你的这种说法，其实也是很多OO宣传者常用的诡辩技巧之一
因为它们从来没解释清楚OO是什麽(事实上是他们自己也不知道)
所以当它们说OO是什麽，别人也没有什麽依据说它不是什麽
63F：推 mdkn35: 原PO你说的应该是封装的部分吧… 有些机器也不会让你知道 10/11 18:29
64F：→ mdkn35: 里面长怎样 这很正常 10/11 18:29
这边我们习惯用「包裹」「包装」，而不用「封装」
「封装」的「封」有阻绝、封闭，不给人触及，不给人看的意思
「包裹」「包装」是有需要时，还可以打开来看的意思
有些机器也不会让你知道 => 更多的机器是要让人知道构造原理，让人可以打开维修的
OO用的词汇，总是偏向隐晦、黑箱
对於「认知」这件事，OO总是要刻意的不友善
正常、不正常 就看你怎麽看
以我工程师的立场，我是不喜欢隐晦、黑箱啦！
※ 编辑: csfgsj (36.229.5.174 台湾), 10/11/2020 23:13:25
65F：→ viper9709: 黑箱有时候是必要的... 10/12 00:43
66F：嘘 feveral: 烂文一篇 10/12 01:50