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

※ 引述《dharma (達)》之銘言：
: 現在很多新出來的程式語言，(如Swift)，從本質上說，都是物件導向語法，這是因為近: 幾十年來，從來沒有比物件導向實現更先進的程式設計實現在新程式語言中全面取代物件: 導向思想。
: 上面是某程式語言教學書看到的
: 他說的符合實情現況嗎？

這當然是唬爛，聽過愚民教育嗎？ 聽過蓄奴嗎？

物件導向就是大公司的陰謀

方便它們做一些黑箱框架，以及騙一些人進來，當它們框架的依賴者

物件導向的語法設計，會讓你很難去挖掘框架後面的東西

用的人只會越來越沒有思想，越來越依賴框架

最後變成離不開框架，任大公司宰割的韭菜

: 一直沒有更先進的東西嶄露頭角
: 可能取而代之
: thanks

就看 A公司跟 G公司彼此要殺到什麼時候了
G 公司的保護費最近也漲成跟A公司一樣了，都是 30% 的抽成

--

不在語法的層次，在架構觀念的層次 等你有了架構觀念，看OO就是一坨屎

不用框架，那用OO就沒意義了

高階語言本來是沒有OO的，高階語言與OO是兩回事 你一定沒有分清楚那些功能性語法，那些是編輯性語法

我知道版上 有些教JAVA的補教業者很討厭我

我寫過MCU的FW，Linux 跟 Windows Device driver，EC, Bios, Web 前端跟後端 從來不用OO。除非接別人的BSP，那還是會看一下

Linux 的 VFS 是各式檔案系統的對上層的統一介面，干OO什麼事？

所有的 Api 都是隱藏實作，讓使用者以一種比較抽象簡化的概念來調用它 OO的問題不在這裡，Class將資料與函式綁在一起，基本上是違反人的思維模式的 由於違反人的思維模式，所以人就無法賦予它一個清楚的抽象簡化概念 調用的時候，就會感到不知道在做什麼，說穿了，Class語法就是個黑箱妖怪製造機 那些基於OO的框架，就是會讓調用者搞不清楚在調用什麼，只能用使用經驗來熟悉它 無法推理及創新，這就是那些大公司要的結果，你只能依賴它，卻難以解析、評論它 當有人說它好棒棒，你也無法判斷是真是假

差異在於人腦對抽象這件事運作方式 人腦可以對動作認知(吃飯、睡覺)的作抽象， 人腦可以對資料包裹(表單、身分證)的認知作抽象 但是人腦無法對「動作+表單」這個不知所云的東西作抽象 抽象這個動作，能將一堆東西，簡化成一個很小的點， 所以抽象這件事，對於人腦在分析一個大系統的時候，非常重要，也是唯一的手段 當人腦無法作抽象的時候，麻煩就大了，萬事都要從細節裡去找答案，那就完蛋了

電腦的周邊裝置就是機器設備的概念，它就是一個對於人腦來說， 一個很好處理的抽象概念 Register 就是周邊裝置的控制鈕，也是一個很好處理的抽象概念 這邊沒有OO的Class，抽象概念很好處理

抽象本來就是人腦的主觀，人腦的運作模式 人腦好處理的東西，就是好東西；人腦不好處理的東西，就是爛東西 你們不是愛講什麼「內聚性」、「耦合性」嗎？ 那是來自人腦的感覺，還是電腦的感覺 「內聚性」、「耦合性」不好的程式也是會動呀！ 問題是看程式的人，腦子會燒壞呀！ 好笑的是Class本身就是一個在破壞體系「內聚性」、「耦合性」的妖怪 除非你的腦袋真的異於常人，那我也只能認了 DDD 是通例，還是特例？如果是 Corner scenario 那或許有可能 如果一體適用，那就是災難的開始

你說的很對，這就是我最上面說的「大公司的陰謀」呀！ 如果你是Code Owner，Code 的領主，你希望有一堆農奴來使用你的code 但又不希望這些碼農奴來了解你的Code，批評你的Code，改你的code，最後取而代之 OO不就是個最完美的解決方案嗎？ 我最初的發言是以碼農奴的立場來看的，我只是在說明這個產業的生態 你也可以說它就是個工具啦！只是不要忘了它後面還是有商業目的存在的 它需要農奴，它需要有人為它抬轎 看看對面的華為，不就是這樣進了圈套，那一天領主翻臉，就被搞死的嗎？

商業利益與邏輯理想的衝突，知道這個情況就好，不用全押下去

陰謀論其實是帶有一種臆測的意味存在 曾經待過某大IT外商，以技術部門的角色與 Marketing 部門的人開會 聽過很多次它們這樣說 它們需要的是可以讓客戶產生依賴性，並且無法轉台離開他們的產品 這樣夠明顯了吧！ 以商業的法則來說這樣沒錯，或許我應該改口說，這根本就是一種陽謀 要不然為什麼A公司跟G公司要各搞各的App框架呢？(就是不想讓你轉台呀！) 為什麼兩家不統一一下，這樣大家都省事，不是很好嗎？ 大陸那邊都開始搞自己的App Store了，為的是什麼？打破控制及壟斷呀！

老實說，我不太相信 你不知道那邊有，但還是隨便貼兩個給你

不懂這句話的意思

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是什麼，別人也沒有什麼依據說它不是什麼

這邊我們習慣用「包裹」「包裝」，而不用「封裝」 「封裝」的「封」有阻絕、封閉，不給人觸及，不給人看的意思 「包裹」「包裝」是有需要時，還可以打開來看的意思 有些機器也不會讓你知道 => 更多的機器是要讓人知道構造原理，讓人可以打開維修的 OO用的詞彙，總是偏向隱晦、黑箱 對於「認知」這件事，OO總是要刻意的不友善 正常、不正常 就看你怎麼看 以我工程師的立場，我是不喜歡隱晦、黑箱啦！