pansz2021-04-25 11:28:18

我說點其它的。

面向物件提供了工程上的便利，大幅度降低了程式設計師門檻。

因為，所必須的技能，從以前的查閱語言手冊變成了現在的依賴IDE程式設計。

我舉個例子：

obj

。

method

（

B

）

method

（

obj

，

B

）

本質上，面向物件的方法跟把物件作為函式第一個引數沒啥不同。以上兩者看起來似乎是等價的，然而實際上，上面一種方案，輸入A。的時候，IDE會給出提示，告訴你有method這個方法，使得程式設計師不需要再去查語言手冊。

而下面一種方案，程式設計師首先必須學會查閱語言手冊才能找到函式列表，否則不記得有哪些函式。

可能上面的例子還不明顯，我把這個例子擴充套件一下你就會更加明白了。

obj

。

method

（

B

）。

func2

（

C

）。

func3

（

D

）

func3

（

func2

（

method

（

obj

，

B

），

C

），

D

）

鏈式呼叫的情況下，上面這種用法，每一個環節，IDE都能夠提示可用的方法名稱。

下面那種用法，就是把面向物件的呼叫轉化為非面向物件呼叫之後的結果。嗯。。。每一個函式你恐怕都得查手冊，而且所有函式位於同一個名稱空間。查起來可不簡單。——就算你覺得查起來簡單，但這種呼叫方式很明顯，與直觀的順序不同。最先寫的那個函式需要最後被呼叫。

所以比較一下，哪個程式碼更簡單更清晰？

本質上來講，所有面向物件的機制都能夠在面向過程的C語言裡面實現。但是一方面是實現起來不好看，二方面是，即便實現了，實際用起來的時候，也大幅度依賴程式設計師查閱手冊的能力。

徐欣2021-04-25 11:41:54

在團隊搞OOP最大的優點就是迅速區分出那些腦子裡全是水的害群之馬

讓他們畫個UML，他們鐵定是要糊弄的，單純是因為大腦注水

至於其他的東西 ，我團隊裡要是人均程式碼天才，搞不搞OOP有什麼區別

程顯通2021-04-26 11:19:05

個人理解，OOP提供瞭解耦和的能力，這種解耦和的能力增強了程式碼的可複用性，提高了多名程式設計師合作時的可並行性，同時給系統設計人員在不同尺度上進行設計的可能。

OOP的三個特性是封裝、繼承、多型，而一些程式語言中繼承有時也會被組合一定程度上取代，所以這裡主要討論封裝和多型。同時出於我自身能力考慮，這裡的比較物件侷限於指令式程式設計。

封裝遮蔽了他人程式碼的細節，將這些細節抽象為了介面。對於他人的程式碼，現在無法輕易知道其真正的內容，也就很容易讓人寫出實現無關的程式碼，而利於程式碼的複用。同時，也限制程式設計師能進行修改的範圍，減少了多個程式設計師同時修改一個內容的可能。

多型則提供了共用的介面，簡化了心智模型，減少了程式設計師在判斷xxxIsSuccess上面花費的時間，和錯誤的機率。同時使對於頂層設計者而言，只需設計頂層的介面，而不用設計多個介面，以應對巨量的型別。

王不賤2021-04-26 15:39:38

本質上這是一個對軟體工程思想的問題

由於現代程式語言的發展，伴隨著教育方式的改善

初學者踏入這門學科之初，接觸到的便是{函式思想，物件思想}

應用於這些思想之上就是面向物件程式設計了

所以說這一種程式設計方式，或者說解決問題的思考方式對於現在的學生來說

有點理所應當的感覺，“世界本來就該如此，談何價值與優點嘛”

至於具體OOP有什麼有點，動動手百度百科上都能查得到。

賈森2021-04-26 17:06:28

沒有對比就沒有傷害，沒經歷過風雨，就不知道彩虹的美好。沒受過以前有點規模的軟體專案的折磨，就沒法領悟面向物件的優點。