C ++和Java可能是計(jì)算機(jī)科學(xué)中最嚴(yán)重的錯(cuò)誤。OOP的創(chuàng)建者艾倫·凱(Alan Kay)和許多其他著名的計(jì)算機(jī)科學(xué)家都對(duì)兩者都提出了嚴(yán)厲的批評(píng)。然而，C ++和Java為最臭名昭著的編程范例-現(xiàn)代OOP鋪平了道路。

它的普及是非常不幸的，它對(duì)現(xiàn)代經(jīng)濟(jì)造成了巨大破壞，造成了數(shù)萬(wàn)億美元的間接損失。OOP導(dǎo)致數(shù)千人喪生。在過(guò)去的三十年中，沒(méi)有任何一個(gè)行業(yè)因潛在的OO危機(jī)而受到影響。

為什么OOP如此危險(xiǎn)?讓我們找出答案。

[[376179]]

想象一下，帶您的家人在一個(gè)美麗的星期天下午乘車兜風(fēng)。外面很好，陽(yáng)光明媚。所有人都進(jìn)入了汽車，行駛了與上百萬(wàn)次完全相同的高速公路。

但是這次卻有所不同–即使您放開油門踏板，汽車仍會(huì)繼續(xù)不受控制地加速行駛。剎車也不起作用，似乎它們失去了動(dòng)力。為了挽救局勢(shì)，您緊急拉了緊急制動(dòng)器。在您的汽車撞到路邊的路堤之前，這會(huì)在道路上留下150英尺長(zhǎng)的防滑痕跡。

聽(tīng)起來(lái)像一場(chǎng)噩夢(mèng)?但這正是2007年9月讓·布克特(Jean Bookout)駕駛豐田凱美瑞(Camry)時(shí)發(fā)生的事情。這不是唯一的此類事件。這是與所謂的"意外加速"有關(guān)的眾多事件之一，該事件困擾了豐田汽車十多年，造成近100人死亡。汽車制造商很快就將手指對(duì)準(zhǔn)了"粘性踏板"，駕駛員失誤甚至地板墊。但是，一些專家長(zhǎng)期以來(lái)一直懷疑有問(wèn)題的軟件可能正在發(fā)揮作用。

為了解決這個(gè)問(wèn)題，美國(guó)宇航局的軟件專家已被征召入伍，一無(wú)所獲。僅僅幾年后，在對(duì)Bookout事件進(jìn)行調(diào)查的過(guò)程中，真正的罪魁禍?zhǔn)资怯闪硪粋€(gè)軟件專家團(tuán)隊(duì)發(fā)現(xiàn)的。他們花了將近18個(gè)月的時(shí)間來(lái)研究豐田代碼。他們將Toyota代碼庫(kù)描述為"意大利面條代碼"，這是一種用于纏結(jié)代碼的程序員術(shù)語(yǔ)。

軟件專家已經(jīng)演示了超過(guò)1000萬(wàn)種豐田軟件導(dǎo)致意外加速的方法。最終，豐田被迫召回了超過(guò)900萬(wàn)輛汽車，并支付了超過(guò)30億美元的和解費(fèi)和罰款。

[[376180]]

意大利面條代碼有問(wèn)題嗎?

某些軟件故障造成的100條生命是太多了。真正令人恐懼的是，豐田代碼的問(wèn)題不是唯一的。

兩架波音737 Max飛機(jī)墜毀，造成346人死亡，損失超過(guò)600億美元。都是由于軟件錯(cuò)誤，由意大利細(xì)面條代碼引起的100%的確定性。

在全球范圍內(nèi)，意大利面條式代碼困擾著太多的代碼庫(kù)。機(jī)載計(jì)算機(jī)，醫(yī)療設(shè)備，在核電站上運(yùn)行的代碼。

程序代碼不是為機(jī)器編寫的，而是為人類編寫的。正如馬丁·福勒(Martin Fowler)所說(shuō)："任何傻瓜都可以編寫計(jì)算機(jī)可以理解的代碼。好的程序員編寫人類可以理解的代碼。"

如果代碼沒(méi)有運(yùn)行，則說(shuō)明它已損壞。但是，如果人們不理解該代碼，那么它將被破壞。不久。

讓我們快速繞道，談?wù)撊说拇竽X。人腦是世界上最強(qiáng)大的機(jī)器。但是，它有其自身的局限性。我們的工作記憶是有限的，人腦一次只能思考5件事。這意味著，程序代碼的編寫方式不應(yīng)使人的大腦不知所措。

意大利面條代碼使人腦無(wú)法理解代碼庫(kù)。這產(chǎn)生了深遠(yuǎn)的影響-無(wú)法看到某些變化是否會(huì)破壞其他東西。對(duì)缺陷進(jìn)行詳盡的測(cè)試變得不可能。沒(méi)有人甚至不能確定這樣的系統(tǒng)是否正常工作。如果確實(shí)有效，那為什么還要有效呢?

是什么導(dǎo)致意大利面條代碼?

為什么隨著時(shí)間的流逝，代碼變成意大利面條式代碼?由于熵-宇宙中的一切最終變得混亂無(wú)序，混亂。就像電纜最終將變得混亂一樣，我們的代碼最終也將變得混亂不堪。除非有足夠的約束。

為什么我們?cè)诘缆飞嫌兴俣认拗?是的，有些人會(huì)永遠(yuǎn)恨他們，但它們可以防止我們墜毀甚至死亡。為什么在路上有標(biāo)記?為了防止人們走錯(cuò)路，防止事故發(fā)生。

在編程時(shí)，類似的方法將完全有意義。這樣的約束不應(yīng)留給程序員來(lái)擺放。它們應(yīng)該通過(guò)工具自動(dòng)實(shí)現(xiàn)，或者理想情況下通過(guò)編程范例本身來(lái)實(shí)現(xiàn)。

為什么OOP是萬(wàn)惡之源?

[[376181]]

> Photo by NeONBRAND on Unsplash

我們?nèi)绾螆?zhí)行足夠的約束來(lái)防止代碼變成意大利面條?兩個(gè)選項(xiàng)-手動(dòng)或自動(dòng)。手動(dòng)方法容易出錯(cuò)，人類總是會(huì)犯錯(cuò)誤。因此，自動(dòng)執(zhí)行此類約束是合乎邏輯的。

不幸的是，OOP并不是我們一直在尋找的解決方案。它沒(méi)有提供任何約束來(lái)幫助解決代碼糾纏問(wèn)題。一個(gè)人可以精通各種OOP最佳實(shí)踐，例如依賴注入，測(cè)試驅(qū)動(dòng)的開發(fā)，域驅(qū)動(dòng)的設(shè)計(jì)等(確實(shí)有幫助)。但是，這些都不是由編程范例本身來(lái)強(qiáng)制執(zhí)行的(并且不存在可以強(qiáng)制執(zhí)行最佳實(shí)踐的此類工具)。

內(nèi)置的OOP功能都無(wú)法幫助防止意大利面條式代碼-封裝只是在程序中隱藏和分散狀態(tài)，這只會(huì)使情況變得更糟。繼承增加了更多的混亂。OOP多態(tài)性再次使事情變得更加混亂-不知道程序在運(yùn)行時(shí)將采用哪種確切的執(zhí)行路徑?jīng)]有任何好處。特別是在涉及多個(gè)繼承級(jí)別時(shí)。

OOP進(jìn)一步加劇了意粉代碼問(wèn)題

缺乏適當(dāng)?shù)募s束(以防止代碼變得混亂)不是OOP的唯一缺點(diǎn)。

在大多數(shù)面向?qū)ο蟮恼Z(yǔ)言中，默認(rèn)情況下所有內(nèi)容都是通過(guò)引用共享的。有效地將一個(gè)程序變成一個(gè)龐大的全球狀態(tài)。這與OOP的原始思想直接沖突。OOP的創(chuàng)建者Alan Kay具有生物學(xué)背景。他想到了一種語(yǔ)言(Simula)，可以用類似于生物細(xì)胞的方式編寫計(jì)算機(jī)程序。他希望有獨(dú)立的程序(單元)通過(guò)相互發(fā)送消息進(jìn)行通信。獨(dú)立程序的狀態(tài)永遠(yuǎn)不會(huì)與外界共享(封裝)。

艾倫·凱(Alan Kay)從未打算讓"細(xì)胞"直接進(jìn)入其他細(xì)胞的內(nèi)部進(jìn)行更改。但這正是現(xiàn)代OOP中發(fā)生的事情，因?yàn)樵诂F(xiàn)代OOP中，默認(rèn)情況下，所有內(nèi)容都是通過(guò)引用共享的。這也意味著回歸成為必然。更改程序的一部分通常會(huì)破壞其他地方的功能(這在其他編程范例(如功能編程)中很少見(jiàn))。

我們可以清楚地看到，現(xiàn)代OOP從根本上來(lái)說(shuō)是有缺陷的。每天都會(huì)在工作中折磨您的"怪物"。而且它也會(huì)在晚上困擾您。

讓我們談?wù)効深A(yù)測(cè)性

[[376182]]

> Photo by samsommer on Unsplash

意大利面條代碼是個(gè)大問(wèn)題。面向?qū)ο蟮拇a特別容易意大利化。

意大利面條代碼使軟件無(wú)法維護(hù)。但這只是問(wèn)題的一部分。我們還希望軟件可靠。但是，這還不夠，軟件(或與此相關(guān)的任何其他系統(tǒng))可以預(yù)見(jiàn)。

任何系統(tǒng)的用戶無(wú)論如何都應(yīng)具有相同的可預(yù)測(cè)的體驗(yàn)。踩下汽車油門踏板始終會(huì)導(dǎo)致汽車加速。踩剎車總是會(huì)導(dǎo)致汽車減速。用計(jì)算機(jī)科學(xué)術(shù)語(yǔ)來(lái)說(shuō)，我們希望汽車具有確定性。

汽車表現(xiàn)出隨機(jī)行為是非常不希望的，例如加速器無(wú)法加速或制動(dòng)器未能制動(dòng)(豐田問(wèn)題)。即使此類問(wèn)題僅在一萬(wàn)億次發(fā)生一次。

然而，大多數(shù)軟件工程師的心態(tài)是"該軟件應(yīng)足以讓我們的客戶繼續(xù)使用它"。我們真的可以做得更好嗎?當(dāng)然可以，我們應(yīng)該做得更好!最好的起點(diǎn)是解決我們程序的不確定性。

非確定性101

如果上述Wikipedia上關(guān)于非確定性的說(shuō)法對(duì)您來(lái)說(shuō)聽(tīng)起來(lái)不太好，那是因?yàn)榉谴_定性沒(méi)有任何好處。讓我們看一下僅調(diào)用函數(shù)的代碼示例：

我們不知道該函數(shù)的功能，但是在給定相同輸入的情況下，該函數(shù)似乎總是返回相同的輸出?，F(xiàn)在，讓我們看一下另一個(gè)示例，該示例調(diào)用另一個(gè)函數(shù)computeb：

這次，函數(shù)為同一輸入返回了不同的值。兩者有什么區(qū)別?給定相同的輸入，前一個(gè)函數(shù)總是產(chǎn)生相同的輸出，就像數(shù)學(xué)中的函數(shù)一樣。換句話說(shuō)，功能是確定性的。后一種功能可能會(huì)產(chǎn)生期望值，但這不能保證。換句話說(shuō)，函數(shù)是不確定的。

是什么使函數(shù)具有確定性或不確定性?

• 不依賴外部狀態(tài)的功能是100%確定性的。
• 僅調(diào)用其他確定性函數(shù)的函數(shù)是確定性的。

在上面的示例中，computea是確定性的，并且在給定相同輸入的情況下，將始終提供相同的輸出。因?yàn)槠漭敵鰞H取決于其參數(shù)x。

另一方面，computeb是不確定性的，因?yàn)樗{(diào)用了另一個(gè)不確定性函數(shù)Math.random()。我們?nèi)绾沃繫ath.random()是不確定的?在內(nèi)部，它取決于系統(tǒng)時(shí)間(外部狀態(tài))來(lái)計(jì)算隨機(jī)值。它還不帶任何參數(shù)-依賴于外部狀態(tài)的函數(shù)的無(wú)用贈(zèng)品。

確定性與可預(yù)測(cè)性有什么關(guān)系?確定性代碼是可預(yù)測(cè)的代碼。非確定性代碼是不可預(yù)測(cè)的代碼。

從確定論到非確定論

[[376183]]

> Photo by Annie Spratt on Unsplash

讓我們看一下附加功能：

我們始終可以確定，給定(2，2)的輸入，結(jié)果將始終等于4。我們?cè)趺茨苓@么確定?在大多數(shù)編程語(yǔ)言中，加法運(yùn)算是在硬件上實(shí)現(xiàn)的，換句話說(shuō)，CPU負(fù)責(zé)計(jì)算結(jié)果始終保持不變。除非我們要處理浮點(diǎn)數(shù)的比較，否則(但這是另一回事，與不確定性問(wèn)題無(wú)關(guān))?，F(xiàn)在，讓我們關(guān)注整數(shù)。硬件非?？煽?，可以安全地假定加法結(jié)果始終正確。

現(xiàn)在，讓我們將值2裝箱：到目前為止，功能是確定的!

現(xiàn)在，我們對(duì)函數(shù)主體進(jìn)行一些小的更改：

• 發(fā)生了什么?突然函數(shù)的結(jié)果不再可預(yù)測(cè)!第一次運(yùn)行良好，但是在隨后的每次運(yùn)行中，其結(jié)果開始變得越來(lái)越不可預(yù)測(cè)。換句話說(shuō)，該功能不再是確定性的。
• 為什么突然變成不確定的?該函數(shù)通過(guò)修改超出其范圍的值而引起了副作用。

讓我們回顧一下

確定性程序可確保2 + 2 == 4。換句話說(shuō)，給定輸入(2，2)，函數(shù)add始終應(yīng)得到4的輸出。無(wú)論您調(diào)用該函數(shù)多少次，無(wú)論您是否并行調(diào)用該函數(shù)，以及該函數(shù)外部的外觀如何。

非確定性程序正好相反。在大多數(shù)情況下，對(duì)add(2，2)的調(diào)用將返回4。但是有時(shí)，該函數(shù)可能會(huì)返回3、5甚至1004。不確定性在程序中是非常不可取的，我希望您現(xiàn)在可以理解為什么。

非確定性代碼的后果是什么?軟件缺陷或通常被稱為"錯(cuò)誤"的缺陷。錯(cuò)誤使開發(fā)人員浪費(fèi)了寶貴的調(diào)試時(shí)間，并且如果將其投入生產(chǎn)，則會(huì)大大降低客戶體驗(yàn)。

為了使我們的程序更可靠，我們應(yīng)該首先解決不確定性問(wèn)題。

副作用

[[376184]]

> Photo by Igor Yemelianov on Unsplash

這給我們帶來(lái)了副作用的問(wèn)題。

什么是副作用?如果您因頭痛而服用藥物，但這種藥物使您惡心，那么惡心是一種副作用。簡(jiǎn)而言之，這是不可取的。

想象一下，您已經(jīng)購(gòu)買了一個(gè)計(jì)算器。您將其帶回家，開始使用它，然后突然意識(shí)到這不是一個(gè)簡(jiǎn)單的計(jì)算器。您自己有了一個(gè)扭曲的計(jì)算器!您輸入10 * 11，它將輸出110作為輸出，但同時(shí)還會(huì)向您大喊一百和十。這是一個(gè)副作用。接下來(lái)，輸入41 + 1，它打印42，并注釋" 42，生命的意義"。副作用也一樣!您感到困惑，然后開始與您想訂購(gòu)披薩的重要對(duì)象進(jìn)行交談。計(jì)算器會(huì)偷聽(tīng)對(duì)話，大聲說(shuō)"好"，然后下達(dá)比薩訂單。副作用也一樣!

讓我們回到加法功能：

是的，該函數(shù)執(zhí)行了預(yù)期的操作，將a添加到b。但是，這也會(huì)帶來(lái)副作用。對(duì)a.value + = b.value的調(diào)用導(dǎo)致對(duì)象a發(fā)生更改。函數(shù)參數(shù)a引用對(duì)象2，因此two.value不再等于2。第一次調(diào)用后，其值變?yōu)?，第二次調(diào)用后，其值為6，依此類推。

純度

[[376185]]

> Photo by yann bervas on Unsplash

在討論了確定性和副作用之后，我們準(zhǔn)備討論純度。純函數(shù)是既具有確定性又沒(méi)有副作用的函數(shù)。

再一次，確定性意味著可預(yù)測(cè)的—給定相同的輸入，該函數(shù)將始終返回相同的結(jié)果。而且沒(méi)有副作用意味著該函數(shù)除了返回值外什么也不做。這樣的功能是純粹的。

純函數(shù)有什么好處?正如我已經(jīng)說(shuō)過(guò)的，它們是可以預(yù)測(cè)的。這使得它們非常易于測(cè)試(無(wú)需模擬和存根)。關(guān)于純函數(shù)的推理很容易-與OOP不同，無(wú)需牢記整個(gè)應(yīng)用程序狀態(tài)。您只需要擔(dān)心當(dāng)前正在使用的功能。

純函數(shù)可以輕松組成(因?yàn)樗鼈儾粫?huì)在其范圍之外進(jìn)行任何更改)。純函數(shù)對(duì)于并發(fā)非常有用，因?yàn)楹瘮?shù)之間沒(méi)有共享狀態(tài)。重構(gòu)純函數(shù)是純粹的樂(lè)趣-只需復(fù)制和粘貼，無(wú)需復(fù)雜的IDE工具。

簡(jiǎn)而言之，純函數(shù)將歡樂(lè)帶回到編程中。

面向?qū)ο缶幊痰募兌热绾?

為了舉例說(shuō)明，我們來(lái)討論一下OOP的兩個(gè)功能：getter和setter。

吸氣劑的結(jié)果取決于外部狀態(tài)-對(duì)象狀態(tài)。多次調(diào)用getter可能會(huì)導(dǎo)致不同的輸出，具體取決于系統(tǒng)的狀態(tài)。這使得吸氣劑本質(zhì)上是不確定的。

現(xiàn)在，二傳手。設(shè)置器用于更改對(duì)象的狀態(tài)，從而使它們固有地具有副作用。

這意味著OOP中的所有方法(除了靜態(tài)方法之外)都是不確定性的，或者會(huì)帶來(lái)副作用，但每種方法都不是好方法。因此，面向?qū)ο缶幊滩皇羌兇獾臇|西，它與pure完全相反。

有一個(gè)銀彈。

但是我們很少有人敢嘗試。

[[376186]]

> Photo by Mohamed Nohassi on Unsplash

在令人沮喪的軟件故障世界中，存在著一線希望，這將解決大多數(shù)(如果不是全部)問(wèn)題。真正的銀彈。但是只有當(dāng)您愿意學(xué)習(xí)和應(yīng)用時(shí)，大多數(shù)人才不會(huì)。

銀彈的定義是什么?可以用來(lái)解決我們所有問(wèn)題的東西。數(shù)學(xué)是靈丹妙藥嗎?如果有的話，它幾乎是銀彈。

我們要?dú)w功于成千上萬(wàn)的千百年來(lái)為我們提供數(shù)學(xué)知識(shí)的聰明才智的男女。歐幾里得，畢達(dá)哥拉斯，阿基米德，艾薩克·牛頓，萊昂哈德·歐拉，阿隆佐教堂等等。

如果不確定性(即不可預(yù)測(cè))的東西成為現(xiàn)代科學(xué)的支柱，您認(rèn)為我們的世界將會(huì)走多遠(yuǎn)?可能不會(huì)很遠(yuǎn)，我們會(huì)留在中世紀(jì)。這實(shí)際上在醫(yī)學(xué)界已經(jīng)發(fā)生過(guò)-過(guò)去，沒(méi)有嚴(yán)格的試驗(yàn)來(lái)證實(shí)特定治療或藥物的功效。人們依靠醫(yī)生的意見(jiàn)來(lái)治療自己的健康問(wèn)題(不幸的是，這種問(wèn)題在俄羅斯等國(guó)家仍然存在)。過(guò)去，無(wú)效的技術(shù)(例如放血)已廣為流行。像砷一樣不安全的東西被廣泛使用。

不幸的是，當(dāng)今的軟件行業(yè)與過(guò)去的醫(yī)學(xué)太相似了。它不是基于堅(jiān)實(shí)的基礎(chǔ)。取而代之的是，現(xiàn)代軟件行業(yè)主要基于脆弱的搖擺不定的基礎(chǔ)，即所謂的面向?qū)ο缶幊獭Ｈ绻祟惖纳钪苯尤Q于軟件，那么就像放血和其他不安全的做法一樣，面向?qū)ο蟮牟僮鲗⒃缫严Р⒈贿z忘。

堅(jiān)實(shí)的基礎(chǔ)

[[376187]]

> Photo by Zoltan Tasi on Unsplash

有其他選擇嗎?在編程世界中，我們可以擁有像數(shù)學(xué)一樣可靠的東西嗎?是!許多數(shù)學(xué)概念直接轉(zhuǎn)化為編程，并奠定了稱為函數(shù)式編程的基礎(chǔ)。

函數(shù)式編程是編程的數(shù)學(xué)-一個(gè)極其牢固和健壯的基礎(chǔ)，可用于構(gòu)建可靠和健壯的程序。是什么使它如此強(qiáng)大?它基于數(shù)學(xué)，尤其是Lambda微積分。

為了進(jìn)行比較，現(xiàn)代OOP是基于什么?是的，正確的Alan Kay OOP是基于生物細(xì)胞的。但是，現(xiàn)代的Java / C#OOP是基于一組荒謬的思想(例如類，繼承和封裝)的，它沒(méi)有Alan Kay的天才發(fā)明的原始思想。其余的只是一組創(chuàng)可貼，以解決其劣等思想的缺點(diǎn)。

函數(shù)編程呢?它的核心組成部分是一個(gè)函數(shù)，在大多數(shù)情況下是一個(gè)純函數(shù)。純函數(shù)是確定性的，這使它們可預(yù)測(cè)。這意味著由純函數(shù)組成的程序?qū)⑹强深A(yù)測(cè)的。他們會(huì)永遠(yuǎn)沒(méi)有錯(cuò)誤嗎?不會(huì)，但是如果程序中存在錯(cuò)誤，也將是確定性的-對(duì)于相同的輸入始終會(huì)發(fā)生相同的錯(cuò)誤，因此更易于修復(fù)。

我怎么到這里了?

過(guò)去，在過(guò)程/功能出現(xiàn)之前，goto語(yǔ)句已廣泛用于編程語(yǔ)言中。goto語(yǔ)句僅允許程序在執(zhí)行過(guò)程中跳至代碼的任何部分。這使得開發(fā)人員很難回答"我如何到達(dá)執(zhí)行點(diǎn)?"這一問(wèn)題。是的，這已導(dǎo)致大量錯(cuò)誤。

如今，一個(gè)非常相似的問(wèn)題正在發(fā)生。僅在這一次，困難的問(wèn)題是"我如何到達(dá)此狀態(tài)"而不是"我如何到達(dá)此執(zhí)行點(diǎn)"。

OOP(通常是命令式編程)回答"我如何達(dá)到這種狀態(tài)?"的問(wèn)題。硬。在OOP中，所有內(nèi)容均通過(guò)引用傳遞。從技術(shù)上講，這意味著任何對(duì)象都可以被任何其他對(duì)象所突變(OOP對(duì)此沒(méi)有任何約束)。封裝根本沒(méi)有幫助-調(diào)用一種方法來(lái)更改某些對(duì)象字段并不比直接對(duì)其進(jìn)行更改更好。這意味著程序很快就會(huì)變成一堆依賴關(guān)系，從而使整個(gè)程序成為全局狀態(tài)的一大塊。

有什么解決方案可以使我們停止問(wèn)"我如何到達(dá)此狀態(tài)"?您可能已經(jīng)猜到了函數(shù)式編程。

過(guò)去，許多人都拒絕了停止使用goto的建議，就像今天的許多人都反對(duì)函數(shù)式編程和不可變狀態(tài)的想法一樣。

但是等等，意大利面條代碼呢?

[[376188]]

> Photo by Andrea Piacquadio from Pexels

在OOP中，"優(yōu)先于繼承而不是繼承"被認(rèn)為是最佳實(shí)踐。從理論上講，此類最佳做法應(yīng)有助于意大利面條式代碼。不幸的是，這僅僅是"最佳實(shí)踐"。面向?qū)ο蟮木幊谭独旧韺?duì)執(zhí)行此類最佳實(shí)踐沒(méi)有任何限制。您的團(tuán)隊(duì)中的初級(jí)開發(fā)人員必須遵循此類最佳做法，并在代碼審查中強(qiáng)制實(shí)施(并非總是如此)。

函數(shù)編程呢?在函數(shù)式編程中，函數(shù)組合(和分解)是構(gòu)建程序的唯一方法。這意味著編程范例本身會(huì)強(qiáng)制執(zhí)行組合。正是我們一直在尋找的東西!

函數(shù)調(diào)用其他函數(shù)，較大的函數(shù)始終由較小的函數(shù)組成。就是這樣。與OOP不同，函數(shù)式編程中的組合是自然的。此外，這使得重構(gòu)等過(guò)程非常容易-只需剪切代碼，然后將其粘貼到新函數(shù)中即可。無(wú)需管理復(fù)雜的對(duì)象依賴項(xiàng)，也不需要復(fù)雜的工具(例如Resharper)。

可以清楚地看到，OOP是代碼組織的次等選擇。函數(shù)式編程的明顯勝利。

但是OOP和FP是互補(bǔ)的!

抱歉讓您失望。它們不是互補(bǔ)的。

面向?qū)ο缶幊膛c功能編程完全相反。說(shuō)OOP和FP是互補(bǔ)的，就等于說(shuō)放血和抗生素是互補(bǔ)的……是嗎?

OOP違反了許多基本的FP原則：

• FP提倡純凈，而OOP提倡雜質(zhì)。
• FP代碼從根本上講是確定性的，因此是可預(yù)測(cè)的。OOP代碼本質(zhì)上是不確定的，因此是不可預(yù)測(cè)的。
• 組合在FP中是自然的，在OOP中不是自然的。
• OOP通常導(dǎo)致錯(cuò)誤的軟件和意大利面條代碼。FP生成可靠，可預(yù)測(cè)和可維護(hù)的軟件。
• FP很少需要調(diào)試，而不是簡(jiǎn)單的單元測(cè)試會(huì)更多。另一方面，OOP程序員住在調(diào)試器中。
• OOP程序員花費(fèi)大部分時(shí)間來(lái)修復(fù)錯(cuò)誤。FP程序員花費(fèi)大部分時(shí)間來(lái)交付結(jié)果。

最終，函數(shù)式編程是軟件界的數(shù)學(xué)。如果數(shù)學(xué)為現(xiàn)代科學(xué)奠定了非常堅(jiān)實(shí)的基礎(chǔ)，那么它也可以以函數(shù)式編程的形式為我們的軟件奠定堅(jiān)實(shí)的基礎(chǔ)。

采取行動(dòng)，為時(shí)已晚

[[376189]]

> Image source: https://www.pexels.com/photo/blue-sky-161148/

OOP是一個(gè)非常大且代價(jià)非常高的錯(cuò)誤。讓我們最終都承認(rèn)這一點(diǎn)。

知道我乘坐的汽車運(yùn)行的是用OOP編寫的軟件，這使我感到害怕。知道帶我和家人休假的飛機(jī)使用面向?qū)ο蟮拇a并不能使我感到更安全。

現(xiàn)在我們?cè)摬扇∽罱K行動(dòng)的時(shí)候了。我們所有人都應(yīng)該開始采取一些小步驟，以認(rèn)識(shí)到面向?qū)ο缶幊痰奈ｋU(xiǎn)，并開始努力學(xué)習(xí)函數(shù)式編程。這不是一個(gè)快速的過(guò)程，至少我們需要十年才能做出轉(zhuǎn)變。我相信，在不久的將來(lái)，那些繼續(xù)使用OOP的人將被視為"恐龍"，類似于今天的COBOL程序員已過(guò)時(shí)。C ++和Java將會(huì)消亡。C#將死亡。TypeScript也將很快成為歷史。

我希望您立即采取行動(dòng)-如果您還沒(méi)有這樣做，請(qǐng)開始學(xué)習(xí)函數(shù)式編程。變得真正擅長(zhǎng)，并廣為傳播。F#，ReasonML和Elixir都是入門的絕佳選擇。

大型軟件革命已經(jīng)開始。您會(huì)加入還是落伍?

原文鏈接：https://suzdalnitski.medium.com/oop-will-make-you-suffer-846d072b4dce