編程為什麼要用物件導向？為什麼不用面向過程？

寫的一個分頁效果 我用50行代碼就寫出來了 然後把他們包在一個函數裡面 用到分頁的地方就調用一下這個函數 而我在網上搜的用物件導向寫的分頁類都300行了 而且又看不懂 為什麼物件導向用了這麼多代碼寫？ 那麼用面向過程寫不是挺好的嗎？為什麼還要用物件導向呢？又費事又不易讀

回複內容：

寫的一個分頁效果 我用50行代碼就寫出來了 然後把他們包在一個函數裡面 用到分頁的地方就調用一下這個函數 而我在網上搜的用物件導向寫的分頁類都300行了 而且又看不懂 為什麼物件導向用了這麼多代碼寫？ 那麼用面向過程寫不是挺好的嗎？為什麼還要用物件導向呢？又費事又不易讀

共用女朋友

• 代碼界加班多，沒有時間陪女朋友逛街、旅遊、買衣服。

• 甚至等不起還在上幼兒園的她。

• new GirlFriend() 是不是很簡單。

• 擼一會爽了就行了，不用自己哄她開心(維護)呀。

隨插即用

• 女孩心思難猜，隔壁大神寫的代碼看不懂

• 工期緊，節奏快，我只想外部配置下就能使用

減少人員傷亡

• 你為什麼改My Code，你改了My Code就跟碰了我的老婆你知道嗎？

• 我不在這插功能怎麼實現。

• 你不會告訴我來插嗎？

世界越來越大，你能做的相對越來越少

• 單打獨鬥的時代已經過去了

• 你要和別人合作才能更大的事情

人讀的詩，機器吃的屎

• 為什麼不直接彙編?

三種效率的價值權衡

• 運行效率

• 開發效率

• 維護效率

• 三種效率，什麼效率都是成本，那種組合配比才能使開支最小？

• 在嘗試階段使用的是解釋型語言。

• 把穩定被需求需要更快運算的改為C開發，節約的是使用者的時間

• 世界級運行效率且不變的需求用了彙編，因為彙編快到了極致節約的是世界人民的錢。

一個巨大的陰謀家，策劃創造一個毀滅世界層級的機器怪物，但是複製你們的代碼粘貼到他的程式裡顯得太LOW。

如果一個東西封裝成函數就夠了，就不應該封裝成類。你遇到的是恰好能封裝成函數的情況。

真正適合物件導向的代碼，你拆成一個一個函數，你會發現參數多了就分散了，傳遞起來麻煩，找起來更麻煩。那還不如弄到一起寫成類的形式。

就比如說，封裝一個http請求，需要傳遞url、方法、參數、cookie、代理，還有一些雜七雜八的配置，等等。你如果封裝成函數，每個函數都需要有將近十個參數，如果封裝成類，只需要傳遞需要設定的參數就行，不需要頻繁設定的參數，就在構造器中賦上預設值。這不就省事了嗎。

我覺得樓上說的太複雜啦，其實並沒有那麼複雜。物件導向的優點是什嗎？好維護，有利於項目的維護擴充。我是做PHP的，PHP面向過程的代碼難以維護，使用物件導向則不然，文檔齊全的情況下，維護擴充起來都挺方便。儘管PHP的物件導向犧牲部分效能，但是相對於項目的可維護性可擴充性而言，不足為慮！

那是因為你沒有開發一個大項目 在大項目開發中 ,物件導向編程,會讓你的代碼寫的更少 更抽象 更容易維護
你可以看看網上的這個解釋http://zhidao.baidu.com/question/2265557081512828548.html

這個一言難盡。對於大型程式，物件導向方法的優點是不容置疑的；但對於一個功能簡單的小程式來說，兩種方法哪個更好還真不能一概而論。

但是300行代碼的分頁程式很可能比你的50行代碼的功能要豐富，可配置性可能也要高一些。而不是說功能完全一樣的情況下，結果卻是50 vs 300。如果真是這樣，那就該打那個人的屁股了。

小菜也鬥膽回答一下這種上升到CS哲學層次的問題.
首先二者並沒有誰厲害誰不厲害之區別,都一樣,沒有高低之說,不然linux kernel那上萬行的C代碼豈不是low爆了?
第二是,程式規模上去了,要求多人團隊高度協同容易維護,似乎,物件導向更適合些
最後是,無論是面向過程還是物件導向,都要做到高度模組化,抽象化,易維護擴充,否則就是給自己挖坑.

反對非黑即白的二元論思想

你只能說：在你接觸過的大多數項目中，為什麼物件導向被普遍使用

而原因是：大部分程式處理的對象繁多、關係複雜，如果用類比現實世界的方法去組織代碼，更容易讓人理解，也更容易維護。

不要為了物件導向而物件導向，因為它並不是普適的範式。合適的才是最好的。

只有面向過程不容易複用代碼。
物件導向方便了對代碼和邏輯的管理。

便於拆分封裝模組。
同時做好架構後，聲明式編程會比指令式編程直觀得多。

拿C語言來說，語言層面根本就不支援C++、Java那種性質的物件導向，但像PHP、Apache、Nginx、Linux這些C程式，不一樣能做到良好的模組化嗎？像Go和Rust這兩門極具代表性的新生代語言，都沒有採用Java/C++那種類型的物件導向和異常處理，由此可見，這兩個東西的確存在缺陷。所以，在PHP編程中不要盲目像Java那樣教條主義地使用物件導向和異常處理。從Linux C庫的API和PHP內建的庫函數其實都可以看出，其組織形式並不是Java類庫那種“物件導向”的方式，但使用起來卻非常方便，所以說封裝成函數，一樣是能夠實現代碼重用的。

拿人吃飯來說:
面向過程強調的是"吃飯","人"只是一個參數.比如mysqli_connect產生的連線物件作為mysqli_系列函數的一個參數.
物件導向強調的是"人","吃飯"只是一個動作.比如new mysqli產生的連線物件,可以直接調用mysqli類的方法和變數.
不是什麼時候都必須要用物件導向的，哪個方便就用哪個。

王垠看待物件導向編程:
http://www.yinwang.org/blog-cn/2015/04/03/paradigms/
王垠這篇文章中關於OOP的見解,提到了,物件導向=過程式+抽象,同時指出了完全物件導向導致過度抽象的問題,過度抽象反而會增加耦合.

“對象思想”作為資料訪問的方式，是有一定好處的。
然而“物件導向”（多了“面向”兩個字），就是把這種本來良好的思想東拉西扯，牽強附會，發揮過了頭。很多物件導向語言號稱“所有東西都是對象”，把所有函數都放進所謂對象裡面，叫做“方法”，把普通的函數叫做“靜態方法”。實際上只有極少需要抽象的時候，需要使用內嵌於對象之內，跟資料緊密結合的“方法”。其他的時候，你其實只是想表達資料之間的變換操作，這些完全可以用普通的函數表達，而且這樣做更加簡單和直接。把所有函數放進對象的做法是本末倒置的，因為函數本身並不屬於對象，它們只是對象上面的變換操作。絕大部分函數是獨立於對象的，它們不能被叫做“方法”。強制把所有函數放進它們本來不屬於的對象裡面，把它們全都作為“方法”，導致了物件導向代碼邏輯過度複雜。很簡單的想法，非得繞好多道彎子才能表達清楚。很多人至今不知道自己所用的“物件導向語言”裡面的很多優點，都是從過程式語言繼承來的。

大多數的物件導向語言裡都缺乏正確的實現一等函數的機制。Java語言是一個極致，它完全不允許將函數當作資料來傳遞。你需要將全部的函數都封裝進類，然後稱它們為“方法”，但就像我說的，這是綁架。缺乏一等函數是為什麼Java裡需要這麼多“設計模式”的主要原因。一旦有了一等函數，你將不再需要大部分的這些設計模式。

