2008年前後，我去一家金融公司參加面試。面試人員要求我為動物或狗或貓設計課程並且設計出類似動物說話這樣的方法來。我認為這是典型的面向物件程式設計，所以我試著向他們解釋可以嘗試採用面向物件的程式設計方法。但是如果有好幾千個物件的話，更合理的做法是採用面向資料開發和過程程式設計，因為它們的執行速度更快，執行緒設計也更合理。結果，面試失敗了。我得到的反饋是，他們認為我不懂面向物件程式設計。我大笑一通，愉快地去其他公司上班了。我以前做的是遊戲開發。在這個行業，面向資料程式設計已經成為了一種新的趨勢。如果你希望自己的遊戲能像PS3一樣快，你就必須考慮自己的資料結構。你必須把資料切分成每次能夠處理的最小資料流，以避免資料佔滿整個記憶體。過程程式設計和麵向資料程式設計有異曲同工之妙。比起面向物件程式設計，採用這種方式編寫的程式碼更容易並行執行。

我認為，面向資料程式設計和過程程式設計不會成為新的發展趨勢。它們從來都不是主流的開發方式，因為99%的應用程式都不需要如此突出的表現。

話說回來，也只有面向資料程式設計才可以取代面向物件程式設計。如果你對高效能計算感興趣，我強烈建議你對面向資料程式設計和過程程式設計進行深入瞭解。

雖然我腦子裡一直想的是面向資料程式設計，但剛開始打出來的時候卻變成了資料驅動設計，兩者的英語縮寫很接近，但其實不是一回事……

OOP只不過是一種解決問題的程式設計思想，解決不同問題可以用不同的思想。很多需求明確而又需要快速開發的小型專案其實僅僅用面向過程就解決，根本不用面向物件。如果小專案非得套上OOP反而沒必要的複雜了。

程式碼不能僅僅追求效率，沒有不存在bug的程式碼，在寫程式碼的同時我們還要考慮其可維護性，程式碼不可能只有一個人寫，當然，除非你只想一個人幹，否則我們還要考慮其可讀性，然後根據實際需求的不同，程式是在不斷變化的，所以我們還要考慮其可擴充套件性。而面向物件的思想更符合人類實際的思考方式，在可讀性，可擴充套件性，可維護行上來說，都是更符合實際需求的。當然，這只是當前，未來的世界，誰又說得準呢。