PTT職涯區 / Soft_Job (軟體人)

Re: [請益] 比物件導向更先進的程式設計思想？

看板Soft_Job (軟體人)作者 (流水貫通)時間3年前 (2020/10/08 16:21), 3年前編輯推噓10(14推 4噓 48→)
留言66則, 26人參與, 3年前最新討論串2/15 (看更多)
※ 引述《dharma (達)》之銘言： : 現在很多新出來的程式語言，(如Swift)，從本質上說，都是物件導向語法，這是因為近 : 幾十年來，從來沒有比物件導向實現更先進的程式設計實現在新程式語言中全面取代物件 : 導向思想。 : 上面是某程式語言教學書看到的 : 他說的符合實情現況嗎？ 這當然是唬爛，聽過愚民教育嗎？ 聽過蓄奴嗎？ 物件導向就是大公司的陰謀 方便它們做一些黑箱框架，以及騙一些人進來，當它們框架的依賴者 物件導向的語法設計，會讓你很難去挖掘框架後面的東西 用的人只會越來越沒有思想，越來越依賴框架 最後變成離不開框架，任大公司宰割的韭菜 : 一直沒有更先進的東西嶄露頭角 : 可能取而代之 : thanks 就看 A公司跟 G公司彼此要殺到什麼時候了 G 公司的保護費最近也漲成跟A公司一樣了，都是 30% 的抽成 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 218.32.249.24 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1602145295.A.198.html
→
10/08 16:31, 3年前 , 1F
所以更先進的設計是什麼
10/08 16:31, 1F
不在語法的層次，在架構觀念的層次 等你有了架構觀念，看OO就是一坨屎
推
10/08 16:34, 3年前 , 2F
怎麼OOP講著講著遷怒到框架去了@@
10/08 16:34, 2F
不用框架，那用OO就沒意義了
推
10/08 16:43, 3年前 , 3F
要這樣講的話 依賴高階語言但不懂組語和編譯器不也算嗎
10/08 16:43, 3F
高階語言本來是沒有OO的，高階語言與OO是兩回事 你一定沒有分清楚那些功能性語法，那些是編輯性語法
→
10/08 16:56, 3年前 , 4F
不會用0跟1寫程式的都自殺好惹 嗚嗚
10/08 16:56, 4F
噓
10/08 17:04, 3年前 , 5F
好久沒看到 此id必推 推爆
10/08 17:04, 5F
我知道版上 有些教JAVA的補教業者很討厭我
→
10/08 17:06, 3年前 , 6F
所以你寫扣都不用物件導向?
10/08 17:06, 6F
我寫過MCU的FW，Linux 跟 Windows Device driver，EC, Bios, Web 前端跟後端 從來不用OO。除非接別人的BSP，那還是會看一下
噓
10/08 19:04, 3年前 , 7F
Linux 的 VFS 不是很 OO 嗎
10/08 19:04, 7F
Linux 的 VFS 是各式檔案系統的對上層的統一介面，干OO什麼事？
→
10/08 19:04, 3年前 , 8F
所以更先進的架構觀念是什麼
10/08 19:04, 8F
→
10/08 19:22, 3年前 , 9F
改用 oh oh p啦
10/08 19:22, 9F
推
10/08 19:30, 3年前 , 10F
linux沒很oo吧
10/08 19:30, 10F
→
10/08 19:34, 3年前 , 11F
看起來，你覺得oop不好的原因是隱藏實作，只依賴抽象
10/08 19:34, 11F
→
10/08 19:34, 3年前 , 12F
介面，這樣很糟糕，我有理解的樓主的意思嗎？
10/08 19:34, 12F
所有的 Api 都是隱藏實作，讓使用者以一種比較抽象簡化的概念來調用它 OO的問題不在這裡，Class將資料與函式綁在一起，基本上是違反人的思維模式的 由於違反人的思維模式，所以人就無法賦予它一個清楚的抽象簡化概念 調用的時候，就會感到不知道在做什麼，說穿了，Class語法就是個黑箱妖怪製造機 那些基於OO的框架，就是會讓調用者搞不清楚在調用什麼，只能用使用經驗來熟悉它 無法推理及創新，這就是那些大公司要的結果，你只能依賴它，卻難以解析、評論它 當有人說它好棒棒，你也無法判斷是真是假
→
10/08 20:27, 3年前 , 13F
class我覺得分成純資料跟物件，物件的method強調抽象
10/08 20:27, 13F
→
10/08 20:27, 3年前 , 14F
行為，這點跟api介面有不同嗎？還是說你指的是，有人
10/08 20:27, 14F
→
10/08 20:27, 3年前 , 15F
把class弄成，半資料半物件的形式？這樣的話當然很糟糕
10/08 20:27, 15F
→
10/08 20:31, 3年前 , 16F
如果是基於fp的框架，使用者難道就可以知道他們在調用
10/08 20:31, 16F
→
10/08 20:31, 3年前 , 17F
什麼嗎？跟oo或fp有關係嗎？
10/08 20:31, 17F
→
10/08 20:32, 3年前 , 18F
有點微妙，api就是高階抽象隱藏實作，oo變成黑箱妖怪，
10/08 20:32, 18F
→
10/08 20:32, 3年前 , 19F
這兩者的差異是？
10/08 20:32, 19F
差異在於人腦對抽象這件事運作方式 人腦可以對動作認知(吃飯、睡覺)的作抽象， 人腦可以對資料包裹(表單、身分證)的認知作抽象 但是人腦無法對「動作+表單」這個不知所云的東西作抽象 抽象這個動作，能將一堆東西，簡化成一個很小的點， 所以抽象這件事，對於人腦在分析一個大系統的時候，非常重要，也是唯一的手段 當人腦無法作抽象的時候，麻煩就大了，萬事都要從細節裡去找答案，那就完蛋了
推
10/08 20:36, 3年前 , 20F
同樓上 我上面推文意思就是高階語言隱藏了實作
10/08 20:36, 20F
→
10/08 20:36, 3年前 , 21F
像是registor隱藏了電路實作 driver隱藏了registor實作
10/08 20:36, 21F
電腦的周邊裝置就是機器設備的概念，它就是一個對於人腦來說， 一個很好處理的抽象概念 Register 就是周邊裝置的控制鈕，也是一個很好處理的抽象概念 這邊沒有OO的Class，抽象概念很好處理
→
10/08 21:30, 3年前 , 22F
為什麼我有一種感覺叫做 我認定可以抽象的才是抽象
10/08 21:30, 22F
→
10/08 21:31, 3年前 , 23F
如果覺得表格+動作 對你來說不好抽象 可以換一種表達
10/08 21:31, 23F
→
10/08 21:32, 3年前 , 24F
表格+動作 有種資料庫驅動設計的感覺 試試 DDD ?
10/08 21:32, 24F
→
10/08 21:32, 3年前 , 25F
領域驅動設計
10/08 21:32, 25F
抽象本來就是人腦的主觀，人腦的運作模式 人腦好處理的東西，就是好東西；人腦不好處理的東西，就是爛東西 你們不是愛講什麼「內聚性」、「耦合性」嗎？ 那是來自人腦的感覺，還是電腦的感覺 「內聚性」、「耦合性」不好的程式也是會動呀！ 問題是看程式的人，腦子會燒壞呀！ 好笑的是Class本身就是一個在破壞體系「內聚性」、「耦合性」的妖怪 除非你的腦袋真的異於常人，那我也只能認了 DDD 是通例，還是特例？如果是 Corner scenario 那或許有可能 如果一體適用，那就是災難的開始
→
10/08 21:45, 3年前 , 26F
看不懂在講認真的還是在反串.....
10/08 21:45, 26F
→
10/08 21:46, 3年前 , 27F
東西好不好不是就看用的人怎樣用，過分使用或者斥之
10/08 21:46, 27F
→
10/08 21:46, 3年前 , 28F
以鼻不是都是最糟糕的行為嗎。
10/08 21:46, 28F
→
10/08 21:50, 3年前 , 29F
今天我只是要輸出一個a+b=c
10/08 21:50, 29F
→
10/08 21:50, 3年前 , 30F
拿OOP的東西來用，那就叫神經病。
10/08 21:50, 30F
→
10/08 21:50, 3年前 , 31F
今天有繼承封裝的需求，訂定規範框架或者是特殊的需
10/08 21:50, 31F
→
10/08 21:50, 3年前 , 32F
求，那他就是很好的工具，不就是這樣而已嗎？
10/08 21:50, 32F
你說的很對，這就是我最上面說的「大公司的陰謀」呀！ 如果你是Code Owner，Code 的領主，你希望有一堆農奴來使用你的code 但又不希望這些碼農奴來了解你的Code，批評你的Code，改你的code，最後取而代之 OO不就是個最完美的解決方案嗎？ 我最初的發言是以碼農奴的立場來看的，我只是在說明這個產業的生態 你也可以說它就是個工具啦！只是不要忘了它後面還是有商業目的存在的 它需要農奴，它需要有人為它抬轎 看看對面的華為，不就是這樣進了圈套，那一天領主翻臉，就被搞死的嗎？
推
10/08 23:29, 3年前 , 33F
好久不見的ID耶 哈哈
10/08 23:29, 33F
推
10/09 00:07, 3年前 , 34F
出桶了？
10/09 00:07, 34F
推
10/09 00:19, 3年前 , 35F
看起來像陰謀而已吧 我覺得比較像工程圈追求傳統工廠般的
10/09 00:19, 35F
→
10/09 00:20, 3年前 , 36F
生產模式 用oop的觀念比較可以接近多請一個人生產效率就會
10/09 00:20, 36F
→
10/09 00:21, 3年前 , 37F
增加 在沒有軟體設計方法的上古時代 常常有技術上數學上
10/09 00:21, 37F
→
10/09 00:22, 3年前 , 38F
可行的產品 但請再多人加再多硬體都完成不了的狀況
10/09 00:22, 38F
→
10/09 00:22, 3年前 , 39F
現代不只oop還有各類開發方法被提出 一般應用型產品從無到
10/09 00:22, 39F
→
10/09 00:23, 3年前 , 40F
有常常就只是工作人數和開機器的問題
10/09 00:23, 40F
推
10/09 00:26, 3年前 , 41F
高階到一定程度的人一定知到oop並不萬用啦 只是在老闆和
10/09 00:26, 41F
→
10/09 00:26, 3年前 , 42F
金主的壓力下大多會選擇商業界慣用的方法來處理
10/09 00:26, 42F
商業利益與邏輯理想的衝突，知道這個情況就好，不用全押下去
推
10/09 00:33, 3年前 , 43F
商業考量啦 沒你講的那麼黑暗
10/09 00:33, 43F
推
10/09 01:25, 3年前 , 44F
把一塊memory space當成object，到處都見山
10/09 01:25, 44F
推
10/09 02:27, 3年前 , 45F
聽起來問題不是OOP，而是你用OOP的方法跟目的？
10/09 02:27, 45F
→
10/09 02:45, 3年前 , 46F
複製貼上大師又出現啦
10/09 02:45, 46F
→
10/09 09:27, 3年前 , 47F
明白樓主的想法 就是在說明不直觀又注重細節 框架中
10/09 09:27, 47F
→
10/09 09:27, 3年前 , 48F
耦合又非常嚴重
10/09 09:27, 48F
→
10/09 09:29, 3年前 , 49F
個人也不愛 只是某勢力實在太龐大
10/09 09:29, 49F
→
10/09 09:40, 3年前 , 50F
不過還是算了吧 如此free style的東西還是用在自己的
10/09 09:40, 50F
→
10/09 09:40, 3年前 , 51F
產品上最好 給人打工free time有就好
10/09 09:40, 51F
→
10/09 23:35, 3年前 , 52F
完全沒用到一丁點OO概念的web前後端喔....呵 這邊也流行
10/09 23:35, 52F
→
10/09 23:35, 3年前 , 53F
幻想文是ㄇ
10/09 23:35, 53F
噓
10/10 01:53, 3年前 , 54F
不管甚麼領域都有這種抱持陰謀論的人出現
10/10 01:53, 54F
陰謀論其實是帶有一種臆測的意味存在 曾經待過某大IT外商，以技術部門的角色與 Marketing 部門的人開會 聽過很多次它們這樣說 它們需要的是可以讓客戶產生依賴性，並且無法轉台離開他們的產品 這樣夠明顯了吧！ 以商業的法則來說這樣沒錯，或許我應該改口說，這根本就是一種陽謀 要不然為什麼A公司跟G公司要各搞各的App框架呢？(就是不想讓你轉台呀！) 為什麼兩家不統一一下，這樣大家都省事，不是很好嗎？ 大陸那邊都開始搞自己的App Store了，為的是什麼？打破控制及壟斷呀！
→
10/10 06:58, 3年前 , 55F
基本上樓主講的開發方式本來就存在 自私且壯大到一定
10/10 06:58, 55F
→
10/10 06:59, 3年前 , 56F
程度確實可以稱作是陰謀沒錯
10/10 06:59, 56F
→
10/10 12:47, 3年前 , 57F
10/10 12:47, 57F
推
10/10 22:13, 3年前 , 58F
今天簡單的架構不能快速解決，框架複雜化是必然結果
10/10 22:13, 58F
→
10/10 22:15, 3年前 , 59F
原po可以給不用oo然後很好看懂的github repo嗎？想瞭解
10/10 22:15, 59F
老實說，我不太相信 你不知道那邊有，但還是隨便貼兩個給你 https://github.com/torvalds/linux https://chromium.googlesource.com/chromiumos/platform/ec/+/refs/heads/master
推
10/10 22:19, 3年前 , 60F
產生依賴性就表示簡易操作解決了複雜問題，這是oo的概念
10/10 22:19, 60F
不懂這句話的意思 ※ 編輯: csfgsj (36.229.5.174 臺灣), 10/10/2020 22:34:16
→
10/11 10:21, 3年前 , 61F
10/11 10:21, 61F
→
10/11 10:24, 3年前 , 62F
其實 Linux kernel 也是會用 OO
10/11 10:24, 62F
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是什麼，別人也沒有什麼依據說它不是什麼
推
10/11 18:29, 3年前 , 63F
原PO你說的應該是封裝的部分吧… 有些機器也不會讓你知道
10/11 18:29, 63F
→
10/11 18:29, 3年前 , 64F
裡面長怎樣 這很正常
10/11 18:29, 64F
這邊我們習慣用「包裹」「包裝」，而不用「封裝」 「封裝」的「封」有阻絕、封閉，不給人觸及，不給人看的意思 「包裹」「包裝」是有需要時，還可以打開來看的意思 有些機器也不會讓你知道 => 更多的機器是要讓人知道構造原理，讓人可以打開維修的 OO用的詞彙，總是偏向隱晦、黑箱 對於「認知」這件事，OO總是要刻意的不友善 正常、不正常 就看你怎麼看 以我工程師的立場，我是不喜歡隱晦、黑箱啦！ ※ 編輯: csfgsj (36.229.5.174 臺灣), 10/11/2020 23:13:25
→
10/12 00:43, 3年前 , 65F
黑箱有時候是必要的...
10/12 00:43, 65F
噓
10/12 01:50, 3年前 , 66F
爛文一篇
10/12 01:50, 66F
‣ 更多 csfgsj 的文章
文章代碼(AID): #1VVimF6O (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 2 之 15 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共15篇)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 csfgsj 的文章
文章代碼(AID): #1VVimF6O (Soft_Job)