一，前言

網(wǎng)上經(jīng)常看到編程語言之爭，大伙兒皈依到不同門派，各自懷抱信仰，時不時還發(fā)生點兒“沖突”。

這其中，C++和Java的優(yōu)劣，十多年前就常吵的火熱。然而時代在進(jìn)步，技術(shù)在發(fā)展，滿街早已是“云大智”了，現(xiàn)在還討論C++ vs Java這個話題，似乎早已經(jīng)過時了。

家鴿資質(zhì)魯鈍學(xué)的慢，熱門的知識沒掌握，只能拿這個老話題炒炒冷飯。

參加工作的前兩年，主要寫Java；近些年由于工作需要，主要寫C/C++了。也算是敝帚自珍吧，常覺得之前學(xué)會兒點兒東西不容易，舍不得丟掉。總會自覺不自覺的拿現(xiàn)在用的相互對比，也就粗略的總結(jié)了些東西，又怕記性不好以后忘了，就寫個文字形式的記下來。

這個系列不敢說兩種語言孰優(yōu)孰劣，只妄圖達(dá)成一個具體的目標(biāo)：認(rèn)真看過這些文字的人，以前寫主寫C/C++的，也能夠?qū)慗ava了；以前主做Java的，也可以嘗試做C/C++了。這當(dāng)然僅限于語言本身這個層面，框架與應(yīng)用領(lǐng)域等范疇不在此列。與此同時，要是家鴿能夠略微傳達(dá)出一些觀念，那就更好了。

二，形而上

形而上謂之道。人在道中而不知道，如同魚在水中卻不知水一樣。

本節(jié)以下為家鴿自己看法的總結(jié)，純屬一家之言，有不同意見歡迎拍磚。

語言層面的“道”，是它的設(shè)計理念與發(fā)展思路。先看一下C++。它就是一個實用主義的大雜燴，有點兒吸星大法的感覺。

1979，Bjarne等人試圖去分析UNIX的內(nèi)核的時候，誕生了這門語言。它初期的目標(biāo)，首先是在兼容C的前提下，引入“面向?qū)ο蟆彼枷搿?984年，“C with class”才改名為“C++”。當(dāng)時面向?qū)ο笏枷雱偝鰜頉]多久，炒的火熱，也確實能解決很多問題。“兼容C”這個大前提不光是兼容，顯然是當(dāng)時出于復(fù)用與實用性的考慮。導(dǎo)致它近乎完全吸納了C的風(fēng)格，可以面向過程，又能面向?qū)ο?這個對象顯然不純，不如稱之為基于對象)，于是語言特性和寫法不可避免的增加了不少，相對而言顯得有些復(fù)雜。面向?qū)ο笫荂++編程思想的一個重要的部分，但不是它最核心的思想，從來也不是。STL也于1979年創(chuàng)立，于1993年成為C++標(biāo)準(zhǔn)的一部分。泛型思維是STL的基礎(chǔ)。當(dāng)前的STL就是個以高度復(fù)用為目標(biāo)的，以泛型思維為基礎(chǔ)的，高層次的，系統(tǒng)化的，類別分明的C++庫。早期的C++并不支持template，而是用宏來構(gòu)建復(fù)雜的結(jié)構(gòu)。但很快就引入了template，又有了新的風(fēng)格與寫法。如果去分析不同版本的STL源碼，會發(fā)現(xiàn)其中沒多少面向?qū)ο?#xff0c;都是在泛型思維指導(dǎo)下，使用template實現(xiàn)的具有高復(fù)用性低時間復(fù)雜度的精巧代碼。早期的Java沒有泛型，后來也有了(雖然二者機制與地位并不等同)。可以看到語言之間常常會相互學(xué)習(xí)各自的語言特性。性能的考量以及直接而靈活的資源操控與系統(tǒng)調(diào)用，是這門語言設(shè)計的又一目標(biāo)。它本來就為分析與實現(xiàn)操作系統(tǒng)而誕生的語言，操作系統(tǒng)內(nèi)核里不會講什么面向?qū)ο?#xff0c;主要是各種資源操控與管理的策略及算法。在從始至終的發(fā)展過程中，所有新特性的引入，都不會違背這個性能與資源操控這個前提。由于這個原因，這門語言靈活而強大。有這么一個說法，C++的靈活與強大不在于它能實現(xiàn)多高層的抽象，而恰恰在于它可以不抽象，以及可以自如的控制自己抽象的程度，要是覺得C/C++語言本身這一層抽象也礙事，甚至可以在里面嵌入?yún)R編。在C++的世界里，既可以面向?qū)嶋H問題的結(jié)構(gòu)，建立抽象模型，又可以看到解決問題時基于的計算機的結(jié)構(gòu)，實際項目研發(fā)過程中一個重要的設(shè)計，就是建立二者之間的映射關(guān)系，這個過程需要不菲的成本。在更高層面抽象的語言誕生之后(比如Java)，依項目類型和需求而定，這種映射關(guān)系的充分建立也許就不是必要的了。也是由于這些原因，使得C++不容易掌握，更難以精通，不易維護(hù)，開發(fā)效率低下，容易引入嚴(yán)重的內(nèi)存泄漏和宕機等問題。于是實際工作中也就有了各種版本的開發(fā)規(guī)范。11版本及之后的C++吸取了現(xiàn)代語言的新思想，譬如有人說lamda和std::function std::bind讓它能夠進(jìn)行函數(shù)式編程，能支持高階函數(shù)和鏈?zhǔn)秸{(diào)用。也許在正統(tǒng)函數(shù)式編程語言的支持者看來，這個“函數(shù)式編程”未必純正。但對新思想的吸納，給C++帶來很多新的語言特性。活用種種新特性與新風(fēng)格寫的代碼，看起來似乎成了一種新的編程語言。C++委員會一方面想讓這門語言長盛不衰，給開發(fā)者提供更加便捷，安全的語言特性；另一方面必須保持它在已有領(lǐng)域的優(yōu)勢，能夠相對靈活自由的操作底層資源；當(dāng)然必須保持對歷史代碼的兼容，以前的特性不能丟。這中間免不了權(quán)衡取舍綜合折中，就成了我們現(xiàn)在看到的C++。這種權(quán)衡與引入，形成了當(dāng)前一個重要的趨勢：在提高(至少保持)對資源靈活控制能力的前提下，提高抽象程度，提升編程的方便與程序安全性。但在語言快速發(fā)展的過程中，對舊特性老式風(fēng)格的兼容，legacy代碼的維護(hù)，大部分一知半解的程序員，以及各種編程范式與新老風(fēng)格在實際研發(fā)中的無原則的混用，都如同重重迷霧一般，掩蓋了這種趨勢，C++項目看起來反而愈加復(fù)雜，甚至有些讓人望而生畏。總體上，C++是面向過程、基于對象、泛型思維和新思想并重，還在不斷發(fā)展的一門編程語言。Java的設(shè)計者看到了(當(dāng)時)C++的各種問題，總結(jié)實際項目的研發(fā)需求，形成了一套高度抽象與精煉的語言特性體系集合，從研發(fā)的源頭就規(guī)避掉這些問題(與此同時也限制了自身在底層的能力)。這個精煉集合寫出來的代碼未必精煉了，有不少人評價它的語言風(fēng)格有些啰嗦，但相對而言這種問題就無傷大雅了。

Java的語言特性相當(dāng)精煉，容易掌握，以至于很大一部分Java程序員相對的不怎么討論語言特性本身，能更多的面向?qū)嶋H問題，將主要精力放在各種框架，API，設(shè)計模式中。你當(dāng)然可以說，C++項目那些問題是由于編程人員水平不夠，而不是語言本身的問題。但在Java這一套新的語言體系中，更多的人經(jīng)過短期學(xué)習(xí)，更容易高效的寫出問題很少的代碼，何樂而不為呢？

高度抽象，是Java的設(shè)計原則。Java本身就是抽象而完備的；并且基于它可以進(jìn)行更高層面的抽象。這使得代碼量少，維護(hù)性好，研發(fā)工作高效，安全性容易得到保證。純粹的面向?qū)ο笫荍ava語言核心的思想與原則，在Java的王國里“一切都是對象”，連基本類型都有對應(yīng)的包裝類。它的復(fù)用也是更多基于面向?qū)ο髞韺崿F(xiàn)的。更完備的抽象，完全的面向?qū)ο?#xff0c;意味著更完全的封裝，程序員不再需要知道細(xì)節(jié)就可以完成任務(wù)，也可以把無關(guān)他人的細(xì)節(jié)更好的隱藏起來。當(dāng)然在一些情況下，掌控底層成為一種必要，它就無能為力了。在Java的設(shè)計思想中，開發(fā)效率的重要性高于程序運行效率本身，這在計算資源不是主要約束的實現(xiàn)需求中，顯然有很大優(yōu)勢。

質(zhì)量與安全性也是重要的考慮，除了規(guī)避掉容易引入問題的語言特性，Java風(fēng)格中的異常處理機制非常完善。很多時候同一段邏輯，Java的寫法也相對單一，不夠自如靈活，但安全性與質(zhì)量更高。在自由與安全中，Java選擇了安全。

Java的語言特性相對精煉，但它也有C++不具備的語言特性。這些語言特性或者更加面向?qū)ο?#xff0c;比如接口。或者使它更能適用于Web，并發(fā)(C++也引入了)等領(lǐng)域當(dāng)中。本節(jié)的描述有些抽象，不易理解，至少不容易有切身體會。為了說明問題，后文中家鴿會用自己寫的一些代碼示例，C++代碼用黑背景，Java用淺綠。這些示例僅為突出演示某些語言特性的“玩具例子”，盡可能的簡短易懂，但并不適用于實際工程。

三、 形而下

形而上謂之道，形而下謂之器。舍器而近道者，幾稀！

器，可以簡單的理解為工具。編程語言本來就是工具，工具的區(qū)別在于使用方法。上圖中，C++，C，Pascal都類似瑞士軍刀，是用來做細(xì)活的工具。C語言的刀上有個USB，說明是可以做硬件操作的。C++刀是什么都有，說明C++是一種特性(過分)繁多的語言。Python是把電鋸，面對大型的物體的修整，威力很大，人擋殺人，佛招殺佛，比C++/C/Java什么的得心應(yīng)手得多得多，但是相對并不適合一些精細(xì)的調(diào)優(yōu)工作。Java/C#是一把單刃工具刀，相對來說，其語法和使用相并不復(fù)雜。

不太關(guān)注技術(shù)細(xì)節(jié)的朋友，這一節(jié)后面的文字可以略過，直接看下一節(jié)。

這一節(jié)從語言具體的用法出發(fā)，來分析一下C++與Java二者的區(qū)別。可以粗分為三類：

• Java不支持的C++特性

• C++不支持的Java特性

• C++和Java都有但是卻不相同的特性

限于篇幅，本文只闡述前兩種情況，第三種情況后續(xù)系列中再行闡述。

Java不支持的C++的特性

• Java不支持指針；

• Java不支持預(yù)處理，也不再支持預(yù)處理指令(宏等等都沒有了)；

• Java不支持typedef；

• Java不支持goto語句；

• Java不支持結(jié)構(gòu)體與聯(lián)合體；

• Java不支持操作符重載(比如Java中的<>不再重載I/O操作)；

• Java不支持全局變量或全局函數(shù)；

• Java不支持默認(rèn)參數(shù)。

• Java不支持析構(gòu)函數(shù)。(Java增加了finalize()函數(shù))；

• Java不支持delete操作符；

• Java中，參數(shù)傳遞的方式只能是傳值(“傳值”這個說法有爭議，且看后文詳細(xì)解釋。C++中可以傳值、傳指針或傳引用)；

• Java不支持多重繼承，即不允許一個子類繼承多個父類。

• ............

下面挑幾條典型的詳細(xì)分析一下。

• 指針

  最顯然的區(qū)別是，C++支持指針，而Java不支持。

  下面這個例子，將平面一個點，移動到與它原點對稱的位置。

下面的這個例子，將一個數(shù)組的內(nèi)容拷貝給另一個數(shù)組。

上面例子的寫法都有些笨拙。比如可以用STL的copy()函數(shù)也許會清爽一些。這里只為比較"指針"這一點。

可以看到，C++有了指針，靈活的多也自由的多，在細(xì)節(jié)操作方面有更多掌控力；但代碼也復(fù)雜了。比如*p++這種寫法，不熟悉的話，總會糾結(jié)優(yōu)先級結(jié)合方式之類。指針操作不當(dāng)也有相當(dāng)?shù)娘L(fēng)險，加之可讀性下降，一般說來開發(fā)效率是有所降低的。

Java在設(shè)計之初，就把安全性與開發(fā)效率作為考慮的重要因素。在語法上去除指針，從根本上就避免了一些可能的質(zhì)量問題。而且語法相對簡單，容易上手，不用太過小心翼翼規(guī)避問題，開發(fā)效率相對也會高些。

• 對象的生命周期? ?

標(biāo)號為(1)的C++構(gòu)造函數(shù)調(diào)用中，我們可以把u本身當(dāng)作一個User對象。實際是在棧空間中構(gòu)造的對象。這種構(gòu)造方法Java中并不支持(基本類型除外)。標(biāo)號為(2)的C++構(gòu)造函數(shù)調(diào)用中，使用一個指針p指向堆空間中構(gòu)造的對象。類似Java中引用q的作用。

也許在C++程序員看來，這沒什么區(qū)別，只是悄悄的把指針藏起來了。換成了“引用”這一語法糖，底層還是用指針實現(xiàn)的。事實上，Java的引用與C++的引用有重要的不同(具體下一段中分析)，“引用的底層也是指針”這一說法，也僅僅是對內(nèi)部實現(xiàn)的一種假設(shè)模型，對理解某些問題更加方便，但把它理解為“別名”更為恰當(dāng)。至于析構(gòu)函數(shù)與finalize()函數(shù)，它們在機制上有著本質(zhì)的區(qū)別。下面這個例子中，假設(shè)資源有限，該類型對象只能創(chuàng)建有限個，需要計數(shù)控制。

C++棧空間的對象會及時析構(gòu)并釋放空間(堆空間的對象則可在主動delete時釋放)，Java的finalize()只能在系統(tǒng)進(jìn)行自動垃圾回收時調(diào)用。程序運行時報錯的原因是每次f()返回時垃圾回收并不出現(xiàn)。因此，沒有調(diào)用finalize()方法，count的值也沒有減少。在5次調(diào)用方法后，count到達(dá)其最大值。C++有析構(gòu)函數(shù)，可以自主決定堆中對象的析構(gòu)時機。Java沒有這個機制。析構(gòu)的時機不能自主掌控，代碼優(yōu)化空間相對有限。因而內(nèi)存占用率等指標(biāo)無法與精心優(yōu)化過的C++代碼相比較，性能也會多少受影響。視具體軟硬件運行情況，垃圾回收時可能會出現(xiàn)若干毫秒的延遲，不能適用于一些資源有限或高度實時的應(yīng)用場景。但Java寫法簡單，容易掌握。而且不容易出錯。C++中忘記析構(gòu)導(dǎo)致內(nèi)存泄露，重復(fù)析構(gòu)引發(fā)崩潰等問題，Java中極少遇到。讓C++程序員飽受折磨的內(nèi)存問題，在JAVA的GC機制下不再是什么問題了。質(zhì)量與安全性有了保證。

• 參數(shù)傳遞

這是有一定代表性的一個區(qū)別，看似平常，真相卻藏的比較深。家鴿比較喜歡的說法是：C++中可以傳值、傳指針或傳引用；Java參數(shù)傳遞的方式只能是“傳值”。這個說法是有爭議的，而且這么說更不容易理解。比如《Java編程思想》里就不贊成。爭議的原因在于對“引用”“傳值”這些概念本身，大家的認(rèn)識就是不一樣的(雖然用了一樣的詞，但表達(dá)了不同的意思或側(cè)重了不同的方面)。Bruce當(dāng)然是理解這個問題的，但家鴿認(rèn)為寫書與教學(xué)的人，更傾向于選擇更多讀者容易理解和接受的說法，但心里明白這樣并沒有真正說清楚，于是又加了這一大串注解(瞧瞧頁腳這一大坨注解吧，不管你主寫Java還是C++，保準(zhǔn)讓你一遍看不明白)。

更容易讓人理解與接受的說法是，Java傳參，對于基本類型是傳值，對于“對象”，則是傳引用。然鵝，這么簡單理解的C++程序員來寫Java，遲早會寫出類似下面這種Bug。

見鬼，Java的對象傳參，不是傳的引用么？為啥沒交換過來啊？難道是值傳遞？在Java中，如果參數(shù)是通過傳遞引用的方式傳遞的，那么程序中的swap函數(shù)應(yīng)該導(dǎo)致兩個對象的內(nèi)容交換，但是實際上卻沒有發(fā)生這種情況。應(yīng)該用下面的話嚴(yán)謹(jǐn)?shù)恼f明這個過程，Java的對象傳參方式只有一種，即使用傳值的方式傳遞了一個引用。而C++的引入傳參方式，是傳入了對象的一個別名。Java的引用更像是傳了個指針，而指針本身是值傳遞的。理解了這句話，在你眼里，各種資料上的不同說法的出入，或者爭議啥的就不再是問題了。詳細(xì)說來，C++程序員眼中，Java的“傳值調(diào)用模式”，調(diào)用函數(shù)向被調(diào)用函數(shù)傳遞對象引用的一份拷貝，而不是對象本身的一份拷貝。在C++中根據(jù)傳引用方式傳遞參數(shù)(在Java中沒有這種方式)，意味著被調(diào)用函數(shù)中的引用形參作為調(diào)用函數(shù)所提供的實參對象的別名。那“正確”的寫法呢？逼的我沒辦法了，似乎只能啰里啰嗦寫這么一灘：

不過Java程序員，貌似不會用這么蹩腳的寫法，他們可能更加面向?qū)ο笠恍１热缡褂冒b類來傳參，把要交換的對象，封裝在另一個對象中進(jìn)行操作。在自己也不知情的情況下，完美的躲開了傳值啊傳引用啊這些坑。

另一方面，對于基本類型，C++與Java都是傳值。傳參類型中，二者只有在這一點上是相同的。也可以拿C++的值傳遞與Java的對象傳遞方式做個對比。也許從表面語法形式上來看，二者更為類似。但實際差別很大。

在Java程序中是通過“傳值語法”傳遞了一個對象的引用，而在C++程序中是通過“傳值語法”傳遞了一個對象的拷貝，內(nèi)部調(diào)用了拷貝構(gòu)造函數(shù)。因此C++規(guī)范中更多強調(diào)如何使用const引用來提高性能。(順帶提一下，例子中C++的string，用法上更像是基本類型，而Java的String，則是貨真價實的類對象，基于對象與面向?qū)ο蟮膮^(qū)別可見一斑。)

家鴿喜歡的所謂“Java一切皆傳值”的說法，對于基本數(shù)據(jù)類型，指的便是變量值的拷貝，而對于對象(或String、Integer等包裝基本類型)，指的是對象地址的拷貝，可以理解為所傳遞的值是對象的地址。

C++的參數(shù)傳遞有傳值，傳引用，傳指針的用法，還可以傳多重指針，搭配上const和參數(shù)的析構(gòu)問題，相對復(fù)雜很多；C++程序員始終面臨著什么情況下什么樣的用法比較好這個問題，大神可以寫出簡明易用的代碼，令人嘆為觀止，而大部分程序員工作多年也搞不清楚，導(dǎo)致項目代碼混亂不堪，慘不忍睹。這些在Java程序員眼中都不是問題，沒有引用指針等方式反而簡單，用JavaBean之類的包裝類傳參輕松愉快不出問題，中規(guī)中矩，雖然有時候包裝類太多也會顯得不夠簡潔。

• 其他

前面說過，C++的很多特性，Java都不支持。比如默認(rèn)參數(shù)。

有了默認(rèn)參數(shù)，可以靈活而簡潔的實現(xiàn)功能，提高代碼復(fù)用性，用的好會上癮。但也容易引入很多問題。首先，默認(rèn)參數(shù)搭配函數(shù)重載與重寫，不易閱讀和維護(hù)。其次，多處位置聲明時，不同位置的默認(rèn)值可以不同，調(diào)用方還可以通過使用自己的聲明來“篡改”默認(rèn)參數(shù)，造成混亂，大型項目中這種問題很難排查(你碰上幾次就深有體會了)。再次，在未來需要修改默認(rèn)值時，所有調(diào)用的地方都需要一一找出并修改，如果默認(rèn)值已經(jīng)在接口中發(fā)布，再想要修改幾乎是不可能的，這在團隊協(xié)作研發(fā)中是很麻煩的問題(不信可以試一試)。因而有些開發(fā)規(guī)范(如google規(guī)范)中，明確禁止使用默認(rèn)參數(shù)。Java干脆去除這個語法特性了。多重繼承、操作符重載、預(yù)處理與typedef都不再支持，也是基于類似的原因或考慮。Java更加符合面向?qū)ο蟮乃枷?#xff0c;goto語句，結(jié)構(gòu)體與聯(lián)合體等等不再需要了。全局變量與全局函數(shù)也沒有了，所謂“一切都是對象”，都在類或?qū)ο笾袑崿F(xiàn)。

C++不支持的Java特性

• 包

Java有“包”這個概念，而C++沒有。C++使用"名字空間"這一機制來完成部分“包”的功能。但相較而言，“包”起了組織程序結(jié)構(gòu)的作用，也提高了程序的組件化程度及復(fù)用性。“名字空間”更多則只是防止重名的含義，家鴿個人認(rèn)為不如“包”用起來方便。

上面這個程序展示了在程序中使用Java所提供的程序包。這個程序首先定義和初始化了一個整形數(shù)組，然后調(diào)用java.uitl程序包的Array類所定義的sort方法對這個數(shù)組進(jìn)行排序。

上面這個程序中定義了一個名為Module的名字空間，為了在main函數(shù)中使用名字空間中所定義的方法，使用using指令。

Java有現(xiàn)成的“包”，而C++程序的模塊組織結(jié)構(gòu)，更多需要自己設(shè)計與實現(xiàn)。不同項目的結(jié)構(gòu)不一定相同。這在帶來自由度的同時，也變的不及Java方便。

• 接口

接口這一詞匯有多重含義，這里指的是狹義上的接口，即公開暴露函數(shù)調(diào)用約定。Java在語言層面支持接口interface，C++則不支持，家鴿認(rèn)為這是C++語言設(shè)計的一個缺憾。在開發(fā)大型項目時，高度抽象的接口設(shè)計是不可或缺的。使用C++開發(fā)的項目中，多使用抽象類來模擬(或自己實現(xiàn))接口的機制，借用虛函數(shù)表(或由自己實現(xiàn))接口-實現(xiàn)對應(yīng)機制，比如微軟COM規(guī)范中接口的概念與實現(xiàn)。雖然可以根據(jù)項目需求來設(shè)計與實現(xiàn)自己版本的“接口”，但不同系統(tǒng)的實現(xiàn)不盡相同會帶來混亂；實現(xiàn)與使用接口的細(xì)節(jié)繁多，并不是很方便。

與接口相關(guān)的一個概念是抽象類。C++語言本身不提供接口，實際中使用抽象類來模擬接口(或當(dāng)接口用)。抽象類這一概念，Java與C++是基本對等的，但具體細(xì)節(jié)不同，形成了不同的風(fēng)格。下面這個例子，兩種語言對應(yīng)的類圖是一樣的。

? ? ? ?C++中的抽象類，是通過純虛函數(shù)實現(xiàn)的，讀起來相對不那么明確。而且有不為人知的用法，比如與大部分人的理解不同，雖然抽象類不可實例化，但純虛函數(shù)其實是可以有對應(yīng)的實現(xiàn)的，并且還有方法調(diào)用純虛函數(shù)的實現(xiàn)(不要驚訝，家鴿這里沒寫錯)，而且這種寫法也是有適用場合的。限于篇幅，這里不做深入描述。后續(xù)會專寫一篇探究虛表的文章。這里只是舉例，看一下C++語法的隱晦與詭秘。

Java中，抽象類和抽象方法必須用abstract關(guān)鍵字修飾，語法標(biāo)志清晰明確。規(guī)定很明白也很容易理解：

• 一旦類中包含了abstract方法，那類該類必須聲明為abstract類；

• 抽象類不一定有抽象方法，有抽象方法的類一定是抽象類或者是接口；

• 抽象類不能實例化，只能被繼承；

• 抽象類的子類，要么是抽象類，要么重寫抽象類中的所有抽象方法。

? ? ?幾句話說明白，是不是很清楚，而且也藏不了什么特殊用法。二者的不同風(fēng)格在這個例子中也有所體現(xiàn)。

另一個相關(guān)概念是繼承。C++支持多重繼承，因而有了菱形繼承的問題和虛繼承等等概念。這個用法很靈活，也有適用場合。比如需要適配的場景，可以用適配器模式解決問題。它分為兩種，類適配器和對象適配器，類適配器用多重繼承的方式比較合適。但多重繼承引來的問題會很多，一般的規(guī)范里都不推薦用。這里也不寫示例代碼了。Java干脆不支持多重繼承，但可以實現(xiàn)多個接口，可以通過實現(xiàn)多個接口模擬多重繼承，達(dá)到類似的效果。這一節(jié)舉例并在一些具體用法上進(jìn)行比較，但總體上來說，二者的相似之處還是多于不同之處的；理解并熟悉那些不同之處，可以讓你根據(jù)實際工作的需要，在二者之間自如切換，而不會在不知不覺中寫出問題代碼。限于篇幅，二者其他一些重要區(qū)別會在本系列后續(xù)展開分析。

四、多與少

少即是多

?前幾日的國慶閱兵，我們看到了陸軍，海軍，空軍，火箭軍，也看到了雷軍。中國互聯(lián)網(wǎng)史的元老人物雷軍，在改革開放民營企業(yè)家的彩車方陣中，站在花車的C位出席了慶典。

“專注，極致，口碑，快”是雷軍總結(jié)的產(chǎn)品經(jīng)驗。雷軍認(rèn)為的“專注"主要是一條，“少即是多”。

? ? ? 雷軍曾看到，傳統(tǒng)的軟件研發(fā)項目過于復(fù)雜，干著干著就干偏了方向，所以一定要把事情簡化到兩、三個月就能做完，而且，這兩、三個月做完可能就解決了某一些用戶的最核心的需求，然后這件事情就可以干了。

　　專注，是很重要的一件事情，是每天需要不斷地提醒自己的事情。“少就是多”，通常情況下，時間少，資源少，人也很不夠，只能盡可能少做事情，找到關(guān)鍵點，以少勝多。用手機舉例，在諾基亞和MOTO的時代，一個手機廠商一年要出60款，甚至100款手機，手機的型號都是很復(fù)雜的，沒有人記得住哪個產(chǎn)品的名字。

　　但從蘋果開始，產(chǎn)品型號簡單的要死，每個產(chǎn)品型號都特別的簡單，但是大家都記住了他的產(chǎn)品型號。“集中所有的精力做一款產(chǎn)品”的成功概率，肯定比“分散精力做100款產(chǎn)品”要高，所以，要集中所有的資源，認(rèn)認(rèn)真真做好一兩款產(chǎn)品，這就是“專注”。

于是雷軍認(rèn)為"砍掉90%，只做10%，認(rèn)認(rèn)真真把那10%做好就足夠好"。通常的產(chǎn)品經(jīng)理，是這個也想做，那個也想做，最后看起來花里胡哨，實際什么都沒做好。優(yōu)秀的產(chǎn)品經(jīng)理，不是把需求往多了搞，而是不斷的砍“需求”，專注于最核心的事情。

早期的建筑大師路德維希·密斯·凡德羅就提出：“Less is more。”這也是他堅持的哲學(xué)，他的設(shè)計作品中各個細(xì)部精簡到不可精簡的絕對境界，不少作品結(jié)構(gòu)幾乎完全暴露，但是它們高貴、雅致，已使結(jié)構(gòu)本身升華為建筑藝術(shù)。

老外說的的"architecture"來源于建筑領(lǐng)域。很多優(yōu)秀的產(chǎn)品，都是簡潔的代表。一款好的軟件，必然是在滿足需求的大前提下，擁有高適應(yīng)能力和低復(fù)雜度的產(chǎn)品。如何控制復(fù)雜度就是軟件工程的一個核心問題，不論業(yè)務(wù)架構(gòu)、功能架構(gòu)還是技術(shù)架構(gòu)。所謂”復(fù)雜“不是“深”，而是“多”。通常的軟件常常帶著太過繁多的功能項目，沒有分類整理，有著太過冗雜的交互。設(shè)計人員似乎為了彰顯功能的強大，恨不能讓屏幕上滿是按鈕，找個東西很難，仔細(xì)分析才發(fā)現(xiàn)未必有什么特別厲害的功能。技術(shù)實現(xiàn)中需要一次性考慮太多的對象，對象和對象之前的關(guān)系也繁多混雜，兩兩間都可能存在著關(guān)聯(lián)關(guān)系，如同一個滿是跳線的電路板，維護(hù)修改越來越困難，質(zhì)量也越來越難以保證，這樣顯然做出不好軟件。反觀Google的大神們，做的頁面只有一個logo和一個搜索框，卻可以在十幾毫秒內(nèi)中從全世界包羅萬象的海量web信息中獲取到相應(yīng)主題的內(nèi)容，并完成相關(guān)度計算排序等工作；其中的大數(shù)據(jù)存儲、處理與檢索技術(shù)高難艱深，架構(gòu)設(shè)計卻精巧清晰。是“少即是多”的典型代表。

通過上面“形而下”一節(jié)的分析，C++和Java的區(qū)別，語言層面上歸結(jié)起來，C++是“多”，而Java是“少”。

C++的多，是有歷史原因的。從他誕生那一刻起，它必須兼容C，又要面向?qū)ο?或者說基于對象)。隨后的發(fā)展要求他支持泛型編程。為了保有市場占有率，確保已有領(lǐng)域的優(yōu)勢，它必須足夠貼近底層；為了保持活力，又必須吸收現(xiàn)代語言的新特性；與之同時還要保證對歷史代碼的兼容......搞到后來，語言特性越來越多，理論上什么都可以干；而且一段邏輯，可以用多種寫法或不同風(fēng)格來實現(xiàn)。

什么都可以干，注定了它的強大靈活，作為技術(shù)人員，掌握了這種語言，如同手握利器，知識類比遷移起來也容易。但什么都可以干常常意味著什么都容易干不好。就項目而言，針對自己的需求與所屬的領(lǐng)域，很多時候常常有更好的選擇。

語言特性就越來越多，初學(xué)者的門檻也越來越高，很少有人敢說自己“精通”C++。這嚴(yán)重影響了它的使用與推廣。

Java就是那個“少”。他的設(shè)計者吸取了C++語言在項目中遇到的問題，砍掉了容易引入出問題的語言特性，變的“少”起來；在語言層面，一些事情的做法也變的相對單一化了。讓開發(fā)、維護(hù)與質(zhì)量保證變得相對簡單，研發(fā)效率大幅提升。雖然這樣做也會損失一些性能，使之不再適合做一些領(lǐng)域的事情。但在它擅長的領(lǐng)域(網(wǎng)絡(luò)，Web, 企業(yè)級應(yīng)用等)，它成為經(jīng)久不衰的語言，并為后來者(如C#)所仿效。如果把語言當(dāng)成一種產(chǎn)品，從受歡迎程度和使用率上來說，Java顯然比C++要成功。不少C++程序員并沒有多喜歡C++，而是項目類型和需求決定，必須得使用它。

通常3年的Java程序員，多在討論各種框架，API，設(shè)計模式乃至架構(gòu)思想，可以引入使用成熟的包搭建大數(shù)據(jù)存儲與處理環(huán)境，進(jìn)行分布式與高并發(fā)編程。而通常3年的C++程序員，對開發(fā)規(guī)范還沒有充分理解，經(jīng)常碰到不明白的語法特性，在各種奇怪的問題中被考驗著細(xì)致與耐心。這就是“少即是多”。

對個人發(fā)展而言，藝不壓身，在能夠透徹而全面理解的前提下，“多”會有“多”的優(yōu)勢，但不能拿這個標(biāo)準(zhǔn)來要求所有人。對團隊而言，新同學(xué)需要從“少”開始學(xué)起。從這個角度說，“C++規(guī)范”起的作用就是：在充分考慮項目需求與具體情況的前提下，通過限制容易出問題的特性和寫法，讓風(fēng)格與特性由多變少，從而達(dá)到代碼復(fù)雜度控制與質(zhì)量保證的效果。在學(xué)習(xí)C++11及更新的標(biāo)準(zhǔn)時也可以看到，當(dāng)代C++會不斷的從其他語言中汲取思想和新特性。我們?nèi)绻袀€參照對比和宏觀視角，就會更容易學(xué)習(xí)與理解。而對于全新的項目，最好是完全摒棄老舊的寫法與特性，新同學(xué)更應(yīng)該從新標(biāo)準(zhǔn)學(xué)起，使用一個少而美的子集。To Be Continued......

總結(jié)

以上是生活随笔為你收集整理的java 析构函数_C++与Java的区别(一)的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。