一切皆是對象

    一門語言若是是另外一個語言的超集的話，那麼這麼語言就要向後者兼容，會變得臃腫，在某些方面的顯得過於複雜，如c++

    2.引用是能夠獨立的存在的，當給一個引用進行初始化的時候，就是給這個引用添加了關聯 如 string  a;和string a="as"

    3.常量的使用一般都是放在程序的內部，但也可放在非rom存儲器中（只讀存儲器）。

   4.越是簡單的事物，其可塑性就很強，能夠在此基礎上作出各類修飾；對於複雜的事物，確實相反，要改變所付出的代價很大，效果達不到預期。封閉性適合複雜，簡單對應抽象。上層建築依賴底層所存在，但要求要隨着時間變化，作出不一樣的響應，所肩負的職責愈來愈多。上層的建築的職能都是依賴底層，要想其賦予不一樣職責，故要改變底層，添加知足新的最小單位（只賦予一個職責）職能。故在上層和基礎層之間映入抽象層，使上層依賴一個抽象層，在抽象層能夠選擇的添加新的最小單位，高層依賴抽象。

 6.五大原則：

單一職責原則SRP：Single Responsibility Principle

開放封閉原則OCP：Open－Close Principle

Liskov替換原則LSP：Liskov Substitution Principle

依賴倒置原則DIP：Dependency Invertion Principle

接口隔離原則ISP：Interface Separate Principle

 

　　在面向對象設計中，如何經過很小的設計改變就能夠應對設計需求的變化，這是令設計者極爲關注的問題。爲此很多OO先驅提出了不少有關面向對象的設計原則用於指導OO的設計和開發。下面是幾條與類設計相關的設計原則。

 

1. 開閉原則（the Open Closed Principle OCP）

　 　一個模塊在擴展性方面應該是開放的而在更改性方面應該是封閉的。所以在進行面向對象設計時要儘可能考慮接口封裝機制、抽象機制和多態技術。該原則一樣適合 於非面向對象設計的方法，是軟件工程設計方法的重要原則之一。咱們以收音機的例子爲例，講述面向對象的開閉原則。咱們收聽節目時須要打開收音機電源，對準 電臺頻率和進行音量調節。可是對於不一樣的收音機，實現這三個步驟的細節每每有所不一樣。好比自動收縮電臺的收音機和按鈕式收縮在操做細節上並不相同。所以， 咱們不太可能針對每種不一樣類型的收音機經過一個收音機類來實現（經過重載）這些不一樣的操做方式。可是咱們能夠定義一個收音機接口，提供開機、關機、增長頻 率、下降頻率、增長音量、下降音量六個抽象方法。不一樣的收音機繼承並實現這六個抽象方法。這樣新增收音機類型不會影響其它原有的收音機類型，收音機類型擴 展極爲方便。此外，已存在的收音機類型在修改其操做方法時也不會影響到其它類型的收音機。 

 

2. 替換原則 (the Liskov Substitution Principle LSP)

　　子類應當能夠替換父類並出如今父類可以出現的任何地方。這個原則是Liskov於1987年提出的設計原則。它一樣能夠從Bertrand Meyer 的DBC (Design by Contract) 的概念推出。

　　咱們以學生爲例，夜校生爲學生的子類，所以在任何學生能夠出現的地方，夜校生都可出現。這個例子有些牽強，一個可以反映這個原則的例子時圓和橢圓，圓是橢圓的一個特殊子類。所以任何出現橢圓的地方，圓都可以出現。但反過來就可能行不通。 

　　運用替換原則時，咱們儘可能把類B設計爲抽象類或者接口，讓C類繼承類B（接口B）並實現操做A和操做B，運行時，類C實例替換B，這樣咱們便可進行新類的擴展（繼承類B或接口B），同時無須對類A進行修改。

 

3. 依賴原則 (the Dependency Inversion Principle DIP)

　　在進行業務設計時，與特定業務有關的依賴關係應該儘可能依賴接口和抽象類，而不是依賴於具體類。具體類只負責相關業務的實現，修改具體類不影響與特定業務有關的依賴關係。

　　在結構化設計中，咱們能夠看到底層的模塊是對高層抽象模塊的實現（高層抽象模塊經過調用底層模塊），這說明，抽象的模塊要依賴具體實現相關的模塊，底層模塊的具體實現發生變更時將會嚴重影響高層抽象的模塊，顯然這是結構化方法的一個"硬傷"。

　　面向對象方法的依賴關係恰好相反，具體實現類依賴於抽象類和接口。

　　爲此，咱們在進行業務設計時，應儘可能在接口或抽象類中定義業務方法的原型，並經過具體的實現類（子類）來實現該業務方法，業務方法內容的修改將不會影響到運行時業務方法的調用。 

 

4. 接口分離原則（the Interface Segregation Principle ISP）

    採用多個與特定客戶類有關的接口比採用一個通用的涵蓋多個業務方法的接口要好。

　　ISP原則是另一個支持諸如COM等組件化的使能技術。缺乏ISP，組件、類的可用性和移植性將大打折扣。

　　這個原則的本質至關簡單。若是你擁有一個針對多個客戶的類，爲每個客戶建立特定業務接口，而後使該客戶類繼承多個特定業務接口將比直接加載客戶所需全部方法有效。

 

以 上四個原則是面向對象中經常用到的原則。此外，除上述四原則外，還有一些經常使用的經驗諸如類結構層次以三到四層爲宜、類的職責明確化（一個類對應一個具體職 責）等可供咱們在進行面向對象設計參考。但就上面的幾個原則看來，咱們看到這些類在幾何分佈上呈現樹型拓撲的關係，這是一種良好、開放式的線性關係、具備 較低的設計複雜度。通常說來，在軟件設計中咱們應當儘可能避免出現帶有閉包、循環的設計關係，它們反映的是較大的耦合度和設計複雜化。