面向對象編程會被拋棄嗎

㈠ 三大編程語言

此圖中，排名前5的分別是：

java、C、Python、C++和C#

佔比分別為：

17.253%、16.086%、10.308%、6.196%、4.801%

㈡ java和c++在面向對象設計方面的不同點和相同點

Java採用了C及C++的語法格式，對於學習過C及C++的程序設計者來說，學習Java將有可能很輕松。但是，如果仔細檢查Java語言的許多細節，就會發現Java取消了不少C及C++的特性，並且加入了一些新的特性。這些差異包括：

不再有指針（Pointer）的概念。

這是Java和C/C++在語法上的主要區別之一。在C及C++中，指針的靈活運用將會給程序設計帶來極大的便利，但是其靈活性也成為了導致程序不穩定的一個主要因素。配合C及C++的內存管理策略，編程人員必須親自跟蹤自己向系統申請到的內存，最後確認交還給系統。並且在使用指針時，要隨時注意是否超過合法的內存空間，造成Segmentation Fault或General Protection Fault這樣的問題。

Java提供了一種引用（Reference）類型用來替代指針，通過引用去訪問申請到的內存空間，可以確保不會訪問不屬於自己的內存空間，同時，程序的執行系統也可以動態地做內存垃圾回收工作，將那些被取消引用的內存空間回收給系統使用。這種動態內存分配機制，通過犧牲一定的靈活性，保證了內存分配一定程度上的安全性。

不再有函數（Function）的概念。

Java編程語言中，取消了結構化語言中最重要的部分——函數。在面向對象程序設計的概念里，對象的數據才是真正的主題，而處理對象數據的方法則必須依附在對象內才有意義。因此函數概念完全是不必要的。這強化了面向對象的開發策略。

不再使用structure、union和typedef.

事實上，在C++中就可以去掉C中的structure和union等對復雜數據的自定義結構類型了，因為類（Class）的定義方式完全可以做到這項功能。而typedef的功能也可以由類來實現。雖然C++這樣的設計是為了和C兼容，但是這些畢竟是多餘的語言特點，在Java語言中便被拋棄了。

不再有類的多重繼承（Multiple Inheritance）。

在C++中，多重繼承是一項很強的功能，但也是較難掌握的。取消多重繼承降低了Java語言的功能，但它使Java看起來更為簡潔。同時，Java也提供了介面（Interface）的方式，可以實現部分多重繼承的作用。和多重繼承的不同之處在於介面並不會定義類方法的內容，以及類中的數據。

不再有操作符重載（Operator Overloading）。

操作符重載被看作是C++的一個特色。在C++中，利用操作符重載，程序設計者通過對現有運算符賦予自己的定義，可以使程序看起來更為自然。但是，如果使用不當，也會使整個程序的可讀性大受影響。同時，這一功能的存在也並非必要，程序設計者可以定義類中的方法來達到同樣的目的。

取消了自動類型轉換。

Java是一種強類型檢查的編程語言，對於諸如浮點型變數賦值給整型變數這樣的情況而言，在C++的語法中是允許的，最多隻是在編譯時給出警告信息。但是，在Java中，除非寫明強制類型轉換，否則編譯無法通過。

不再有預處理器（preprocessor）功能。

利用C/C++中提供的#define、#include等預處理指令，厲害的程序設計人員可以自己開發一套只有自己才看得懂的宏指令集。從軟體工程的角度上看，這對團隊開發軟體和整個軟體的維護都是十分不利的。同時，預編譯後的程序代碼和程序設計者看到的程序代碼是不同的。如果宏指令集有錯，編譯器產生的錯誤信息將不會是編程人員所預期的，這增加了程序調試的難度。

取消了goto語句。

在C++中，goto語句已經不被建議使用了，保留goto只是為了和C語法兼容。在Java中goto語句被完全拋棄了，與此同時，Java又擴大了break語句和continue語句的功能，通過使用break和continue，程序流程被允許在多層循環中跳轉。

可以這樣說，Java編程語言是一種簡潔而有效的純面向對象的編程語言。而C++語言因為要與C兼容（C++語言是作為C語言的一個超集被定義的），所以在面向對象的特性方面不如Java好。

㈢ 面向對象編程為什麼沒有在計算科學領域獲得普及

面向對象編程（OOP）具有多方面的吸引力。對管理人員， 它實現了更快和更廉價的開發與維護過程。對分析與設計人員，建模處理變得更加簡單，能生成清晰、易於維護的設計方案。對程序員，對象模型顯得如此高雅和淺 顯。此外，面向對象工具以及庫的巨大威力使編程成為一項更使人愉悅的任務。每個人都可從中獲益，至少表面如此。如果說它有缺點，那就是掌握它需付出的代價。思考對象的時候，需要採用形象思維，而不是程序化的思維。與程序化設計相比，對象的設計過程更具挑戰性——特別是在嘗試創建可重復使用（可再生）的對象時。

㈣ 為什麼面向對象的編程會在軟體開發領域造成如此震憾的影響

面向對象編程（OOP）具有多方面的吸引力。對管理人員，它實現了更快和更廉價的開發與維護過程。對分析與設計人員，建模處理變得更加簡單，能生成清晰、易於維護的設計方案。對程序員，對象模型顯得如此高雅和淺顯。此外，面向對象工具以及庫的巨大威力使編程成為一項更使人愉悅的任務。每個人都可從中獲益，至少表面如此。
抽象的進步
所有編程語言的最終目的都是提供一種「抽象」方法。一種較有爭議的說法是：解決問題的復雜程度直接取決於抽象的種類及質量。這兒的「種類」是指准備對什麼進行「抽象」？匯編語言是對基礎機器的少量抽象。後來的許多「命令式」語言（如FORTRAN，BASIC和C）是對匯編語言的一種抽象。與匯編語言相比，這些語言已有了長足的進步，但它們的抽象原理依然要求我們著重考慮計算機的結構，而非考慮問題本身的結構。在機器模型（位於「方案空間」）與實際解決的問題模型（位於「問題空間」）之間，程序員必須建立起一種聯系。這個過程要求人們付出較大的精力，而且由於它脫離了編程語言本身的范圍，造成程序代碼很難編寫，而且要花較大的代價進行維護。由此造成的副作用便是一門完善的「編程方法」學科。
為機器建模的另一個方法是為要解決的問題製作模型。對一些早期語言來說，如LISP和APL，它們的做法是「從不同的角度觀察世界」——「所有問題都歸納為列表」或「所有問題都歸納為演算法」。PROLOG則將所有問題都歸納為決策鏈。對於這些語言，我們認為它們一部分是面向基於「強制」的編程，另一部分則是專為處理圖形符號設計的。每種方法都有自己特殊的用途，適合解決某一類的問題。但只要超出了它們力所能及的范圍，就會顯得非常笨拙。
面向對象的程序設計在此基礎上則跨出了一大步，程序員可利用一些工具表達問題空間內的元素。由於這種表達非常普遍，所以不必受限於特定類型的問題。我們將問題空間中的元素以及它們在方案空間的表示物稱作「對象」（Object）。當然，還有一些在問題空間沒有對應體的其他對象。通過添加新的對象類型，程序可進行靈活的調整，以便與特定的問題配合。所以在閱讀方案的描述代碼時，會讀到對問題進行表達的話語。與我們以前見過的相比，這無疑是一種更加靈活、更加強大的語言抽象方法。總之，OOP允許我們根據問題來描述問題，而不是根據方案。然而，仍有一個聯系途徑回到計算機。每個對象都類似一台小計算機；它們有自己的狀態，而且可要求它們進行特定的操作。與現實世界的「對象」或者「物體」相比，編程「對象」與它們也存在共通的地方：它們都有自己的特徵和行為。 Alan Kay總結了Smalltalk的五大基本特徵。這是第一種成功的面向對象程序設計語言，也是Java的基礎語言。通過這些特徵，我們可理解「純粹」的面向對象程序設計方法是什麼樣的：(1) 所有東西都是對象。可將對象想像成一種新型變數；它保存著數據，但可要求它對自身進行操作。理論上講，可從要解決的問題身上提出所有概念性的組件，然後在程序中將其表達為一個對象。
(2) 程序是一大堆對象的組合；通過消息傳遞，各對象知道自己該做些什麼。為了向對象發出請求，需向那個對象「發送一條消息」。更具體地講，可將消息想像為一個調用請求，它調用的是從屬於目標對象的一個子常式或函數。
(3) 每個對象都有自己的存儲空間，可容納其他對象。或者說，通過封裝現有對象，可製作出新型對象。所以，盡管對象的概念非常簡單，但在程序中卻可達到任意高的復雜程度。
(4) 每個對象都有一種類型。根據語法，每個對象都是某個「類」的一個「實例」。其中，「類」（Class）是「類型」（Type）的同義詞。一個類最重要的特徵就是「能將什麼消息發給它？」。
(5) 同一類所有對象都能接收相同的消息。這實際是別有含義的一種說法，大家不久便能理解。由於類型為「圓」（Circle）的一個對象也屬於類型為「形狀」（Shape）的一個對象，所以一個圓完全能接收形狀消息。這意味著可讓程序代碼統一指揮「形狀」，令其自動控制所有符合「形狀」描述的對象，其中自然包括「圓」。這一特性稱為對象的「可替換性」，是OOP最重要的概念之一。

一些語言設計者認為面向對象的程序設計本身並不足以方便解決所有形式的程序問題，提倡將不同的方法組合成「多形程序設計語言」（注釋②）。

②：參見Timothy Budd編著的《Multiparadigm Programming in Leda》，Addison-Wesley 1995年出版。

1.2 對象的介面
亞里士多德或許是認真研究「類型」概念的第一人，他曾談及「魚類和鳥類」的問題。在世界首例面向對象語言Simula-67中，第一次用到了這樣的一個概念：
所有對象——盡管各有特色——都屬於某一系列對象的一部分，這些對象具有通用的特徵和行為。在Simula-67中，首次用到了class這個關鍵字，它為程序引入了一個全新的類型（clas和type通常可互換使用；注釋③）。

③：有些人進行了進一步的區分，他們強調「類型」決定了介面，而「類」是那個介面的一種特殊實現方式。

㈤ 為什麼有這么多開發者討厭面向對象編程

關於面向對象編程，有人喜歡它，也有人討厭它。面向對象編程（OOP）已經存在了很長時間。它是一種編碼風格、一種思想流派、一種學校里的教授實踐。它的核心思想是將代碼組織成有意義的「對象」，這些「對象」是現實問題的模型，將描述模型各個「狀態」的變數和修改這些變數的方法（子常式或函數）捆綁在一起。

這一切都讓他相信「OOP 是危險的。OOP 程序固有的非確定性讓代碼變得不可靠」。程序在運行時會有很多不同的路徑，因為會有很多不同的對象，而且會不斷動態創建出新的對象。「這種看似無辜的編程範式對世界經濟造成的破壞性影響是人們難以理解的」。

㈥ 如果不用面向對象的編程會死掉嗎

不會死掉，適應的場合不一樣，有的比較接近底成的就用面向對象d的 就比較好一點，而像c++。java就是接近上層，脫離了硬體，還是比較有市場的

㈦ 既然java這種面向對象的編程思想已經很好的替代了C語言這種面向過程編程模式，請問為什麼還有那麼多人

java是高級編程語言，所謂高級就是越靠近人的思維方式，人的思維方式主要是面向對象的思維方式；
c語言是低級編程語言，所謂低級就是越靠近機器的思維方式，機器是面向過程的方式運行的，按部就班地先做什麼再做什麼的一步一步的運行；
一般情況下，同樣的功能，c語言編寫的程序比java編寫的執行效率高，因為c語言更懂底層負責執行的硬體，但是java的開發效率會比c語言搞，因為java的編程方式更接近編程人員的思維方式。
所以這兩種語言是不同級別的語言，不具可比性，所謂各有千秋。

㈧ 面向對象編程的弊端是什麼

面向對象原本要解決什麼（或者說有什麼優良特性）
似乎很簡單，但實際又很不簡單：面向對象三要素封裝、繼承、多態


（警告：事實上，從業界如此總結出這面向對象三要素的一剎那開始，就已經開始犯錯了！）。


封裝：封裝的意義，在於明確標識出允許外部使用的所有成員函數和數據項，或者叫介面。


有了封裝，就可以明確區分內外，使得類實現者可以修改封裝內的東西而不影響外部調用者；而外部調用者也可以知道自己不可以碰哪裡。這就提供一個良好的合作基礎——或者說，只要介面這個基礎約定不變，則代碼改變不足為慮。


繼承+多態：繼承和多態必須一起說。一旦割裂，就說明理解上已經誤入歧途了。

㈨ 面向對象編程為什麼沒有在科學計算領域獲得普及

兩方面原因，其一在於絕大部分科學計算領域中的演算法的是直接以面向過程來描述的，這很顯然，因為演算法就是對數據進行處理以得到所需要結果的過程。這一套邏輯是該領域研究人員所熟悉的，因此就算他們選擇了C/C++來進行編程，也很自然的就採用了面向過程的範式。其二在於科學計算領域的研究人員所受到的編程方面的訓練並不足以使他們足夠強地掌握面向對象的編程方法。當水平不足的時候，使用面向對象的方法寫出來的程序運行效率可能很差，這不滿足科學計算對於效率的高要求。
但是這並不絕對，比如在元胞自動機領域，可能多數程序都是面向對象的，因為該方法的描述與面向對象的方法是十分契合的，也因為這一領域最近才迅速發展，領域中已經有足夠多的研究人員具備使用C++進行面向對象開發的能力。
此外，尤其需要注意的是，進入新世紀之後，越來越多的人開始採用C/C++甚至最近的Python進行科學計算了，但是這並不表明面向對象在他們的程序架構中佔有優勢地位，多數科學計算的C/C++程序仍然是面向過程的，或者本質上是面向過程，只是基於對象在頂層上做了一些封裝。我注意到題目的標簽中加了Fortran項，我想大家須要將面向過程/面向對象這種編程範式與具體的語言(Fortran/C/ C++/Python)區分出來 。我自己比較熟悉的Python/C++都是支持面向過程/面向對象多種編程範式的。況且Fortran語言的運行效率並不比C/C++高，兩方陣營表現幾乎一致
最後，就我個人而言，我現在使用得更多的是以泛型編程技術為核心的多種范型並存的編程風格。前述已經給出定義「演算法就是對數據進行處理以得到所需要結果的過程」，因此泛型這種將數據類型與操作過程相分離，最大程度上提高代碼復用程度並且基本不損失運行效率的範式，在我看來，十分契合數值計算的需求。但是科學計算領域的研究人員中少有人具備熟練掌握並最大程度上利用該範式的能力。

㈩ 關於大家認為面向對象的編程方法是不是已經過時了

面向對象(Object Oriented,OO)是當前計算機界關心的重點，它是90年代軟體開發方法的主流。面向對象的概念和應用已超越了程序設計和軟體開發，擴展到很寬的范圍。如資料庫系統、互動式界面、應用結構、應用平台、分布式系統、網路管理結構