建站
咨詢
售后
建站咨詢
新聞中心
C++語言實際上是幾種不同語言的聚集地，你可以把他看成一種語言，也可以把他看成一種語言，要進行對C++程序地開發(fā)，那么復(fù)雜性會大幅度地增加，這就是C++在實踐中難于控制的一個主要原因。
創(chuàng)新互聯(lián)是一家集網(wǎng)站建設(shè),千陽企業(yè)網(wǎng)站建設(shè),千陽品牌網(wǎng)站建設(shè),網(wǎng)站定制,千陽網(wǎng)站建設(shè)報價,網(wǎng)絡(luò)營銷,網(wǎng)絡(luò)優(yōu)化,千陽網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強企業(yè)競爭力?？沙浞譂M足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時我們時刻保持專業(yè)、時尚、前沿，時刻以成就客戶成長自我，堅持不斷學(xué)習(xí)、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實用型網(wǎng)站。
混合使用不同風(fēng)格，就好像在一個源文件里混合使用多種不同的語言，復(fù)雜和不一致性必然暴露。當(dāng)然，C++獨特的魅力正在于混合風(fēng)格編程的強大威力。這正是一把雙刃劍，雖然具有潛在的強大威力，但是通常來說也是導(dǎo)致項目混亂的重要原因。
我認(rèn)為以下面的原則進行實際開發(fā)，將可以在一定程度上規(guī)避風(fēng)險：
1). 在任何一個單個的時間點，只使用一種編程風(fēng)格。
2). 以一種風(fēng)格為主風(fēng)格，用它來組織整體模塊的開發(fā)。
3). 在遇到特別適合另一種風(fēng)格的典型場景，可以用一個子模塊包裝該場景，然后在該子模塊中使用該風(fēng)格，但記住遵循要求1，避免混合風(fēng)格。此外，必須通過封裝手段將該模塊包裝起來，以符合主體風(fēng)格的要求。比如說，主風(fēng)格是better C，在某個子模塊中用到了面向?qū)ο?，則應(yīng)當(dāng)使這個子模塊從整體上看來像是一個普通的C過程。
4). 在個別場合，混合風(fēng)格的確有很大的好處。但是，這種情形是比較少見的，一般來說比較成功的實踐已經(jīng)總結(jié)成patterns，所以在工程實際中，可以強行規(guī)定，只有在符合某個patterns的情況下才可以謹(jǐn)慎地使用混合風(fēng)格，嚴(yán)禁擅自創(chuàng)造新的混合用法。
現(xiàn)在來討論一下究竟應(yīng)當(dāng)如何劃分C++風(fēng)格。Stroustrup對C++風(fēng)格的分類是從語言開發(fā)者的角度進行的。如果我們以下面的原則進行分類，我認(rèn)為會得出不同的結(jié)果：
1) 每一種風(fēng)格必須構(gòu)成一個完整的子語言，具有完備性，可以單獨使用這一子語言開發(fā)任何軟件系統(tǒng)，有經(jīng)過歷史驗證的成功經(jīng)驗。
2) 每一種風(fēng)格必須相對簡單，有一致的、簡單的、得到認(rèn)可和驗證的原則。
3) 每一種子語言必須能夠在現(xiàn)實世界中找到相對應(yīng)的其他語言。
依據(jù)以上原則，我將C++語言劃分為三個半子語言：
1) Better C, 只增加函數(shù)重載、引用類型、缺省參數(shù)等簡單特性的類C子集。對應(yīng)ANSI C語言。
2) ADT C++，即C with Class，整個程序由平面化的具體類(concrete class)對象構(gòu)成，無繼承，無多態(tài)。對應(yīng)Ada 83語言。
3) IDL C++，我稱之為Interface-Oriented，典型范例是COM組件模型。
3.5) GP C++, 利用模板技術(shù)形成了一種庫和組件的實現(xiàn)語言。這不是一種完整子語言，一方面因為可以把它看成是ADT C++的一種延伸，另一方面它必須依附于其他風(fēng)格而發(fā)揮作用。
顯然，我這里遺留了一個最重要的風(fēng)格，也就是我們通常所說的“傳統(tǒng)面向?qū)ο蟆憋L(fēng)格，由Smalltalk，Java等語言所展示的。由MFC等類庫經(jīng)過多年實踐論證了的一種風(fēng)格：靠龐大的繼承樹抽象和組織各種數(shù)據(jù)類型，靠繼承和組合實現(xiàn)代碼復(fù)用。這種風(fēng)格為什么沒有被我提及呢？
因為我認(rèn)為這種風(fēng)格實際上是一種混合風(fēng)格！可以認(rèn)為是在試圖融合上述第2、3和3.5種風(fēng)格。在前述的三條原則里，它嚴(yán)重地違背了第二條。由于C++的靜態(tài)本質(zhì)，由于C++缺乏天然的類庫和垃圾收集機制，使得在C++語言中進行Smalltalk風(fēng)格的編程非常非常困難，以至于為了克服這些困難，C++語言實際上發(fā)展出了一套不同于Smalltalk、Java風(fēng)格的獨特的“面向?qū)ο蟆本幊田L(fēng)格。
這套風(fēng)格歷經(jīng)近15年實踐，應(yīng)該說有成功有失敗，雖然出版了大量的著作，至今沒有形成簡單的、一致的、可仿效的風(fēng)格指導(dǎo)。從某種意義上說，如此多的C++面向?qū)ο缶幊讨笇?dǎo)書籍十幾年常盛不衰，恰恰說明這種風(fēng)格的困難程度和難以仿效性。
就我個人而言，我已經(jīng)不再以這種風(fēng)格為指導(dǎo)思想了。我不會再拼命地構(gòu)造繼承樹，思考哪些函數(shù)應(yīng)該是虛函數(shù)這類問題了。你可以認(rèn)為“為了復(fù)用代碼而進行的繼承”是這種風(fēng)格的標(biāo)志。
請注意，ADT C++允許組合，對于繼承則應(yīng)該想盡一切辦法避免。而IDL C++的典型代表COM，根本就不支持這種繼承，它支持的只是接口的復(fù)用。當(dāng)然，這并不是要否定十幾年來C++語言在面向?qū)ο蠓矫姘l(fā)展的成績。但是，如果你現(xiàn)在從頭開始規(guī)劃一個完整的項目，那么我認(rèn)為如果選擇這種雜合風(fēng)格，是不太明智的。但是這種風(fēng)格也有兩個典型的使用場景：
1) 有一個完整的框架支持。比如MFC。雖然這種風(fēng)格本身有很多技術(shù)難點，但是MFC這樣的框架已經(jīng)幫你克服了一部分，給你營造了一個類似Smalltalk那樣的、相對舒適環(huán)境，這時候可以使用這種風(fēng)格。但是通常要認(rèn)識到，這類框架在克服不少技術(shù)難點的同時，引入了一些新的問題，有時是更加難以對付的問題，所以要明智，并且做好充分準(zhǔn)備。
2) 符合經(jīng)典模式。如果遇到某個典型的“面向?qū)ο蟆眻鼍?，已?jīng)有了成熟的、優(yōu)秀的、現(xiàn)成的、文檔化了的設(shè)計解決方案，則可以有選擇的、謹(jǐn)慎地使用之。我指的主要就是GoF和其他一些設(shè)計模
這里所謂的“經(jīng)典模式”數(shù)量絕對不會太多，但是卻大量地、反復(fù)地出現(xiàn)在設(shè)計中，并且往往復(fù)合出現(xiàn)。這樣的情況用已經(jīng)經(jīng)過驗證的設(shè)計方案來解決是非常合適我個人在這里有一些實踐，覺得應(yīng)該注意幾個問題。***是要謹(jǐn)慎，我遇到過大量的情形，看上去很適合用某個模式來解決，但是真的用了才發(fā)現(xiàn)并不是這么回
在不適合的地方套用了錯誤的模式，會把事情弄得一團糟；二是***將設(shè)計方案局部化，包裝起來，從外面看不出你使用了什么模式。三是注意內(nèi)存問題。使用OO風(fēng)格的***障礙其實就是內(nèi)存問題。
當(dāng)前題目：C++語言僅僅是面對對象的語言嗎
標(biāo)題鏈接：http://m.fisionsoft.com.cn/article/dhghsss.html
