1.概念：

面向對象基于對象的概念，對具體的事物、非具體的規則、計劃或者事件等需求進行狀態和行為分析。然后進行一系列的抽象，以對象為中心，以類和繼承為構造機制，充分利用接口和多態提供靈活性，來認識、理解、刻劃客觀世界和設計、構建相應的軟件系統。

面向對象編程即使用面向對象的設計語言，采用面向對象的編程思想和面向對象的設計模式來實現軟件編程。

2.發展歷程：

從發展歷程上看，計算機編程語言經歷了面向機器、面向過程、結構化編程、面向對象四個發展階段，

a) 面向機器： 初期計算機只能識別特定的指令，工程師們所思考的是計算機能接收哪些指令

b) 面向過程：隨著計算機的飛速發展，計算機能處理的事情越來越多，偉大的工程師們為了簡化自己的編程負擔，為了使編程更加符合人類的思維邏輯。就發明了符合人類思維方式的編程模式（即遇到一件事情，該怎么去完成，中間可能出現什么情況，需要處理幾次等思維方式。所以計算機語言中的if else where switch等都是符合人正常思維邏輯的）。所以符合人類思維邏輯的編程被我們稱之為面向過程編程

c) 結構化編程：對程序進行結構化的分析和設計。例如封裝共有的代碼以減少代碼的冗余

d) 面向對象：隨著遇到的業務邏輯越來越復雜，傳統的if else已經不能很好完成程序可能遇到的所有情況，即使可以完成，對整體的代碼影響也非常的大（當if語句的需求被改變，之前的else不能處理現有的需求）。而且同一個共性可能被很多地方用到，面向對象的產生就是為了解決代碼冗余和更好的描述事物間的關系。

3.面向對象編程

什么是面向對象編程

?第一個成功的面向對象的語言Smalltalk描述：

?a)萬物皆為對象

?b)程序是對象的集合，它們通過發送消息來告知彼此所要做的。

?c)每個對象都有自己的由其他對象所構成的存儲。

?d)每個對象都擁有其類型。

e)?某一特定類型的所有對象都可以接收同樣的消息。

?C++和Java等后期的面向對象語言，都是在這個定義的基礎上設計的。

面向對象編程從下到上的基本邏輯是

面向對象設計的基本原理和方法、面向對象的設計原則、面向對象的設計模式（創建模式、結構模式、行為模式）、框架、應用程序

1）面向對象的設計基本原理及方法

第一步，確定對象和類。這里所說的對象是對數據及其處理方式的抽象，它反映了系統保存和處理現實世界中某些事物的信息的能力。類是多個對象的共同屬性和方法集合的描述，它包括如何在一個類中建立一個新對象的描述。

第二步，確定結構（structure）。結構是指問題域的復雜性和連接關系。類成員結構反映了泛化-特化關系，整體-部分結構反映整體和局部之間的關系。

第三步，確定主題（subject）。主題是指事物的總體概貌和總體分析模型。

第四步，確定屬性（attribute）。屬性就是數據元素，可用來描述對象或分類結構的實例，可在圖中給出，并在對象的存儲中指定。

第五步，確定方法（method）。方法是在收到消息后必須進行的一些處理方法：方法要在圖中定義，并在對象的存儲中指定。對于每個對象和結構來說，那些用來增加、修改、刪除和選擇一個方法本身都是隱含的（雖然它們是要在對象的存儲中定義的，但并不在圖上給出），而有些則是顯示的。

2）我們來看看面向對象設計的基本原則（單一職責原則（SRP） 開放封閉原則（OCP） 里氏替換原則（LSP） 依賴倒置原則（DIP） 接口隔離原則（ISP）），我直接拷貝別人的描述

a）單一職責原則

? ? 對于單一職責原則，其核心思想為：一個類，最好只做一件事，只有一個引起它的變化。單一職責原則可以看做是低耦合、高內聚在面向對象原則上的引申，將職責定義為引起變化的原因，以提高內聚性來減少引起變化的原因。職責過多，可能引起它變化的原因就越多，這將導致職責依賴，相互之間就產生影響，從而大大損傷其內聚性和耦合度。通常意義下的單一職責，就是指只有一種單一功能，不要為類實現過多的功能點，以保證實體只有一個引起它變化的原因。

? ? 專注，是一個人優良的品質；同樣的，單一也是一個類的優良設計。交雜不清的職責將使得代碼看起來特別別扭牽一發而動全身，有失美感和必然導致丑陋的系統錯誤風險。

b）開放封閉原則

? ? 對于開放封閉原則，它是面向對象所有原則的核心，軟件設計說到底追求的目標就是封裝變化、降低耦合，而開放封閉原則就是這一目標的最直接體現。

? ? 開放封閉原則，其核心思想是：軟件實體應該是可擴展的，而不可修改的。也就是，對擴展開放，對修改封閉的。

? ? 因此，開放封閉原則主要體現在兩個方面：1、對擴展開放，意味著有新的需求或變化時，可以對現有代碼進行擴展，以適應新的情況。2、對修改封閉，意味著類一旦設計完成，就可以獨立完成其工作，而不要對其進行任何嘗試的修改。

? ? 實現開開放封閉原則的核心思想就是對抽象編程，而不對具體編程，因為抽象相對穩定。讓類依賴于固定的抽象，所以修改就是封閉的；而通過面向對象的繼承和多態機制，又可以實現對抽象類的繼承，通過覆寫其方法來改變固有行為，實現新的拓展方法，所以就是開放的。

? ? “需求總是變化”沒有不變的軟件，所以就需要用封閉開放原則來封閉變化滿足需求，同時還能保持軟件內部的封裝體系穩定，不被需求的變化影響。

c）依賴倒置原則

? ? 對于依賴倒置原則，其核心思想是：依賴于抽象。具體而言就是高層模塊不依賴于底層模塊，二者都同依賴于抽象；抽象不依賴于具體，具體依賴于抽象。

? ? 我們知道，依賴一定會存在于類與類、模塊與模塊之間。當兩個模塊之間存在緊密的耦合關系時，最好的方法就是分離接口和實現：在依賴之間定義一個抽象的接口使得高層模塊調用接口，而底層模塊實現接口的定義，以此來有效控制耦合關系，達到依賴于抽象的設計目標。

? ? 抽象的穩定性決定了系統的穩定性，因為抽象是不變的，依賴于抽象是面向對象設計的精髓，也是依賴倒置原則的核心。

? ? 依賴于抽象是一個通用的原則，而某些時候依賴于細節則是在所難免的，必須權衡在抽象和具體之間的取舍，方法不是一層不變的。依賴于抽象，就是對接口編程，不要對實現編程。

d）接口隔離原則

? ? 對于接口隔離原則，其核心思想是：使用多個小的專門的接口，而不要使用一個大的總接口。

? ? 具體而言，接口隔離原則體現在：接口應該是內聚的，應該避免“胖”接口。一個類對另外一個類的依賴應該建立在最小的接口上，不要強迫依賴不用的方法，這是一種接口污染。

? ? 接口有效地將細節和抽象隔離，體現了對抽象編程的一切好處，接口隔離強調接口的單一性。而胖接口存在明顯的弊端，會導致實現的類型必須完全實現接口的所有方法、屬性等；而某些時候，實現類型并非需要所有的接口定義，在設計上這是“浪費”，而且在實施上這會帶來潛在的問題，對胖接口的修改將導致一連串的客戶端程序需要修改，有時候這是一種災難。在這種情況下，將胖接口分解為多個特點的定制化方法，使得客戶端僅僅依賴于它們的實際調用的方法，從而解除了客戶端不會依賴于它們不用的方法。

? ? 分離的手段主要有以下兩種：1、委托分離，通過增加一個新的類型來委托客戶的請求，隔離客戶和接口的直接依賴，但是會增加系統的開銷。2、多重繼承分離，通過接口多繼承來實現客戶的需求，這種方式是較好的。

e）Liskov替換原則

? ? 對于Liskov替換原則，其核心思想是：子類必須能夠替換其基類。這一思想體現為對繼承機制的約束規范，只有子類能夠替換基類時，才能保證系統在運行期內識別子類，這是保證繼承復用的基礎。在父類和子類的具體行為中，必須嚴格把握繼承層次中的關系和特征，將基類替換為子類，程序的行為不會發生任何變化。同時，這一約束反過來則是不成立的，子類可以替換基類，但是基類不一定能替換子類。

? ? Liskov替換原則，主要著眼于對抽象和多態建立在繼承的基礎上，因此只有遵循了Liskov替換原則，才能保證繼承復用是可靠地。實現的方法是面向接口編程：將公共部分抽象為基類接口或抽象類，通過Extract Abstract Class，在子類中通過覆寫父類的方法實現新的方式支持同樣的職責。

? ? Liskov替換原則是關于繼承機制的設計原則，違反了Liskov替換原則就必然導致違反開放封閉原則。

? ? Liskov替換原則能夠保證系統具有良好的拓展性，同時實現基于多態的抽象機制，能夠減少代碼冗余，避免運行期的類型判別。

3）23種設計模式這里不做描述

4）框架

? ? 框架是用來簡化開發的約束性支撐結構，不能把框架和工具混為一談。程序遵循框架規范來完成開發，由框架來控制程序的行為。也就是說只要程序按照框架指定的規范來編寫，其余的調用全部由框架自己來完成。一個好的框架不能被外部程序所控制。例如spring框架，只需要按照規定進行配置和開發，所有的bean創建加載和調用由框架自己完成。

5）應用程序是基于以上的方法開發出來的符合業務需求的、可執行的代碼。