物件導向不是計算機程式設計的基本原子

　　在過去的25年裡，程式設計世界發生了巨大的變化，如今，我們有大量的有用的、靈活的資料型別可以使用，但在25年前，你需要花大量的額外時間自己去構造這些型別。

　　C和Pascal語言——當時的標準語言——提供了少量的面向機器的資料型別：數字，指標，陣列，形式上的字串，以及把多種資料組合到一起的結構體或record。重要的是，以這些基本的型別為基石，我們可以構造出更多有趣的型別，例如棧，樹，連結表，雜湊表，可變陣列等。

　　在Perl或Python，或Erlang語言裡，我不需要考慮這些東西。我在使用list、string或array時，根本不關心它們能容納多少元素，或放在記憶體的什麼地方。最常使用的還有字典，同樣，根本不擔心它的容量或雜湊衝突是如何避免的細節內容。

　　除此外，我仍然需要一些新的資料型別，但它們更多的是現有型別的一種變換，而不是重新構造。任意維度的vector實際就是array。一個RGB顏色值實際上一個3元tuple。一個多項式既可以是一個tuple，也可以說list。我驚奇於這些array，tuple，list，dictionary等資料型別大大的消除了我在大學課程裡學到的那些基本資料型別上的不便。在實現一個平衡二叉樹時，你的注意力放在如何讓二叉樹平衡，而不是痛苦的糾結於亂如麻的指標操作。

　　將已有的小方塊搭建成一個新的建築，這將會引起比小方塊出現帶來的更大的變化。這些小方塊是如何出現的已經不是人們關心的重點。在很多的程式設計課程和教材中，本來很好的教學中突然出現了一批新詞彙：物件，構造器，抽象基礎類，以及私有方法。於是，下一次作業中，用簡單的三元tuple來表達的RGB顏色值變成了由一個具有get、set方法，多高構造器的類來代替，更要命的，出現了大量的程式碼。

　　這就是為什麼有人會不停的呼籲、解釋為什麼物件導向不是個好東西、會使程式設計失去樂趣的原因。但很少奏效。

　　並不是物件導向不好，或含有什麼缺陷。而是物件導向不是計算機程式設計的基本原子，它們不是人們想象的天生就存在的。不設門檻的任意使用物件導向來解決問題會讓程式碼變得臃腫和過度技術化，然而，很多人還是堅持鍥而不捨的用物件來解決所有問題。這非常糟糕，因為這樣做讓人們辨不清物件導向風格的做法是否真的產生了使問題簡化並易於理解的效果。

　　原文連結：OOP Isn't a Fundamental Particle of Computing