C++設計目標和原則 (轉)
一、 C++的設計目標(C++ Design Aims)
C++的設計目標,就是要讓C++既具有適合於設計的C語言所具有的可適應性和高效性,又能在其程式組織結構方面具有像Simula那樣的語言設施(Simula所支援的這種程式組織結構通常被稱為面向程式設計風格)。在設計的時候,還做了很大的努力,使得引借自Simula的高層次的程式設計技術能夠應用於系統程式設計之中。這即是說,C++所提供的抽象機制能夠被應用於那些對和可適應性具有極高要求的程式設計任務之中。
上述的C++之設計目標可以小結如下:
對於要解決實際問題的程式設計師而言,C++使程式設計變得更有樂趣;
C++是一門通用目的的程式設計語言,它:
——是一個更好的C;
——支援資料抽象;
——支援物件導向程式設計;
——支援範型程式設計。
對範型程式設計的支援在C++設計的後期才被作為一個明確、獨立的目標來實現。而在C++演化過程的大部分時間裡,我一直把範型程式設計以及支援它的語言特性劃歸在“資料抽象”的大標題之下。
二、 C++的設計原則(Design Principles)
在[Stroustrup,1994]中,C++的設計規則被分為基本規則、基於設計的規則、語言的
技術性規則以及基於低層次程式設計的規則四個方面,分列在下文中。
[基本規則(General rules)]
A: C++的每一步演化和發展必須是由於實際問題所引起的;
B: C++是一門語言,而不是一個完整的系統;
C: 不能無休止的一味追求完美;
D: C++在其存在的“當時”那個時期必須是有用處的;
E: 每一種語言特性必須有一個有根據的、明確的實現方案;
F: 總能提供一種變通的方法;
G: 能為意欲支援的每一種程式設計風格提供易於理解的支援方法;
H: 不強制於人。
可以注意到,基本規則的最後三條暗示了兩點:對適用於真實世界中各種應用的便捷工具的強調;對程式設計師的技術和取向(偏好)的充分考慮。從一開始,C++面向的就是那些要做實際專案的程式設計師。所謂的“完美”被認為是不可能達到的,這是由於C++在需求、背景和待解決問題上存在著太大的不同。況且,在一門通用目的的程式設計語言的整個生存期之內,連對“完美”一詞的詮釋都可能會有極大的改變。由此可知,在語言的演化過程中,來自使用者的反饋和語言實現者們積累的才是最為重要的。
[基於設計的規則(Design-support rules)]
A: 支援良好的設計方案;
B: 提供用於程式組織的語言設施;
C: 心口如一(Say what you mean);
D: 所有的語言特性必須具有切實有效的承受能力;
E: 開啟一個有用的特性比避免所有的誤用更為重要;
F: 能將獨立開發的部件組合成完整的。
C++的一個目標就是提供更易用並具有一定承受能力的設計思想和程式設計技術,進一步提高程式的質量。這些技術中的絕大部分都源自Simula ,並通常被作為物件導向程式設計和麵向物件設計思想來討論。然而,C++的設計目標總還是在於要支援一定範圍內的各種程式設計風格和設計思想。這與一般在語言設計方面的觀點形成一定對比。一般在語言設計上總是試圖將所有系統內建於單獨一個被重點支援的、帶有強制性的程式設計風格之中(或稱典範paradigm)。
[語言的技術性規則(Language-technical rules)]
A: 與靜態型別系統(Static type system)沒有內在的衝突;
B: 像對內建(built-in)型別一樣對使用者自定義型別提供很好的支援;
C: 個異化(locality)行為是可取的;
D: 避免產生順序上的依賴關係;
E: 在對語言產生疑惑時,可以選取其特性中最易掌握的部分;
F: 可以因為不正當的語法使用而產生問題(Syntax matters (often in perverse
ways))
G: 削弱對預的使用。
當然,這些規則要具體結合更多關於基本目標的上下文環境來考慮。應該注意到的是,在“與C有較高的相容性”、“不損失效率”以及“具有便捷的可用性來解決實際問題”這三個方面的要求,與在“完整的型別性”、“完全的通用性”以及“完善的抽象之
美”這三個方面的要求形成對立。
C++從Simula中借鑑了使用者自定義型別和類層次機制。然而,在Simula及許多類似的語言中,其對使用者自定義型別的支援與其對內建型別的支援存在著根本上的不同。例如,Simula中不允許在棧中為使用者自定義型別的物件分配空間,並且只允許透過指標(這在Simula中稱為引用——reference)來對這些物件進行訪問。而相反的,內建型別的物件只在棧中被分配空間,不能在動態區中分配,而且不能使用指標指向它。這種在對待內建型別與對待使用者自定義型別上的差異,暗示著對效率問題的嚴格考慮。比如,當作為一個在動態儲存區中被分配的物件之引用時,如果該物件屬於自定義型別(比如complex),那麼就會為執行期及空間帶來負荷;而這些負荷在有些應用中被認為是不可接受的。這些正是C++意欲涉足解決的問題。同時,在用法上的不同也決定了:不可能在範型程式設計中統一對待那些語義上近似的型別。
在維護一個較龐大的程式時,一個程式設計師不可避免的會基於某些不完整的知識來對程式作一些修改,只關注全部程式程式碼中的一小部分。基於此,C++提供了class、namespace和訪問控制,使設計決策的各異化(locality)成為可能。
在基於一趟編譯(one-pass compilation)的語言中,某些順序上的依賴性是不可避免的。例如在C++中,一個變數或者在其被宣告之前是無法使用的。然而,C++中類成員的名字規則和過載解析(overload resolution)的規則還是在獨立於宣告順序的原則下被制定出來,以便將發生混亂和錯誤的可能性降至最低。
[基於低層次程式設計的規則(Low-level programming support rules)]
A: 使用傳統的(笨拙的)聯結器(linker);
B: 與C語言不存在無故的不相容性;
C: 不給C++之下層級的更低層語言留出餘地(語言除外);
D: 你不會為你所不使用的部分付出代價(零負荷規則);
E: 在產生疑惑時,能提供完全自主控制的途徑。
在C++的設計中只要在不嚴重影響其對強型別檢查(strong type checking)的支援的
地方,都儘量做到與C的“-link”方式相相容。C++與C的相容性使得C++程式設計師立刻就能有一個完整的語言和工具集可用。還有兩點也很重要,一是有大量關於C的高質量的教學素材已經存在,二是C++程式設計師可以利用C++與C的相容性而直接並有效的使用大量現成的程式庫。在決定將C作為C++的基礎的時候,C還沒有像後來那樣出類拔萃、炙手可熱,所以在考慮這個問題的時候,與C語言所提供的可適應性和高效性相比,C語言的流行程度只是個次要的考慮因素。
然而,與C的相容性也使得C++在某些語法和語義上保留了C的一些瑕疵之處。比如,C語言的宣告語法就實在遠不及優美;而其內建型別的隱式轉換規則也是混亂無章法的。還有另一個大問題,就是許多從C轉向C++的程式設計師並沒有認識到,程式碼質量上的顯著提高只能透過在程式設計風格上的顯著改變來達到。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/10752043/viewspace-997936/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 資料治理的目標和原則
- 3. 目標精通--用java寫設計模式:依賴倒轉原則Java設計模式
- C++設計模式的原則C++設計模式
- 設計原則-依賴反轉原則
- 淺談C++物理設計:設計原則C++
- 設計原則之【依賴反轉原則】
- 軟體設計原則—依賴倒轉原則
- 設計原則
- 設計原則:開閉原則(OCP)
- 設計原則 設計模式設計模式
- 設計模式 - 設計原則設計模式
- 【設計模式】設計原則設計模式
- 物件導向設計原則和模式物件模式
- Java中的設計模式和原則Java設計模式
- Angular 2.0 的設計方法和原則Angular
- 職場工作方法論:目標管理SMART原則
- 物件導向設計原則,以及包的設計原則物件
- 設計原則:介面隔離原則(ISP)
- 設計原則之【介面隔離原則】
- URI設計原則
- Hbase 設計原則
- 程式設計原則程式設計
- XP設計原則
- 安全設計原則
- 軟體六大設計原則和設計模式設計模式
- 設計模式的設計原則設計模式
- XML 程式設計思想: Harold 的高效 XML 設計原則(轉)XML程式設計
- 設計原則之【單一職責原則】
- 設計原則之【開放封閉原則】
- 設計原則之【裡式替換原則】
- 軟體設計原則—介面隔離原則
- 軟體設計原則—合成複用原則
- SOLID 設計原則Solid
- 系統設計原則
- 設計原則總結
- loc框架設計原則框架
- DDD聚合設計原則
- 微服務設計原則微服務