今天發現一本好書，設計模式精解，作者是alan shalloway和james r.trott，薄薄的一本，但是講的很清楚，也讓我對物件導向和設計模式有了多一點的理解。記得去三星實習生面試的時候面試過就問過乙個問題，談談對物件導向的理解，我當時就只說了乙個多型，而且感覺沒有條理，所以今天趁著看過書，總結下這個問題。
object oriented，oo這個概念已經知道很多年了，但是感覺距離真正的理解還差的很遠，要想深刻理解可能需要一些大型的專案經驗，通過實踐成長。oo的思想已經運用的很廣泛了，還有什麼object database，分布式系統，cad技術等很多方面。三個特徵多型、繼承、封裝，貌似很簡單的東西。
oo的最根本目的是什麼？oo可以實現**復用，可以實現多型，可以實現資訊的封裝，但是都不是本質的。我覺得是容易維護，當使用者的需求變化的時候，系統容易維護！所以如果需求不改變（不可能的。記得哲學上還有個什麼事物總是發展變化的原理～），那麼可能就不會有oo，結構化的程式設計思路清晰，設計實現速度快，而且**執行上速度可能更快（建立銷毀物件是要消耗效能的）。
舉個例子，來說明oo是如何來處理變化的需求的。假設一位講師，參加他課程的人不知道下一節課去**上，講師的責任就是保證每個人都知道**去上下一節課程，如果按照結構化的程式設計方法，可能步驟是這樣的：
1.獲得學生名單
2.對於每個學上在名單上查詢他的下一節課地點
第二種方法，直接把學生課程和課程地點張貼出來，並告訴他們去自己查。
兩種方法的最大的不同就是責任的轉移，第一種方案中，講師負責所有責任，第二種方案中，學生對自己的行為負責，這樣做的最大的好處就是可以使得當需求變化的時候，**的變動最小，容易維護。當有一類特殊的學生，例如是畢業生，這類學生在上下節課之前必須去先乙個地方提交課程評價，如果是按照方案一，那麼當每一種這樣的需求出現時候都要去修改控制程式。而第二種方案，只要為畢業生編寫乙個附加的程式就可以了，新的型別的學生對自己的行為負責。
上面這個例子也是多型的思想。物件導向的核心是「物件」的概念。所有東西都聚焦於物件，圍繞物件而非函式來組織**，使用物件可以定義對自己負責的東西。
使用oo的設計，可以通過封裝改變程式會隱含產生的一些「***」bugs，維護容易。如果不採用封裝，那麼乙個資料結構或者函式的變化，可能會影響到後面很多的方法，可能會產生很多隱藏的「***」bugs，但是如果採用物件封裝，那麼唯一影響乙個物件的方法就是呼叫其中的方法，物件的資料和實現其責任的方法都被遮蔽起來，不受其他物件變化的影響。
總結下：
oo可以實現**重用（繼承和封裝）和介面重用（多型），但是最根本上是使得程式容易擴充套件和維護：
1.多型解決需求變化
2.封裝解決修改時***
3.多型的介面統一可以使得程式改動的時候編譯效率增加
物件導向的理解
1.物件導向的思想 誰擁有資料，誰就提供運算元據的方面。eg1 售票員統計票上的資料這個過程中統計方法是票據提供的。eg2 兩塊石頭磨成一塊石刀，石刀砍樹，砍成木材，木材又變成椅子 eg3.乙個小球從繩子一端移到至另一端。就第二個例子而言，石頭變成石刀，這個變成的方法不應該是石頭提供的，因為一般沒有...
物件導向的理解
關於物件導向的概念，一直都是似懂非懂的狀態，做次筆記方便日後溫故而知新 封裝 解決了資料的安全問題.繼承 解決了 的重用問題.多型 解決了程式的擴充套件問題.在現實生活中，可以理解為兒子繼承了父親的財產。財產的重用。在程式中是解決 的重用問題 繼承是利用現有的類建立新類的過程，現有的類稱作基類 父類...
物件導向的理解
面向過程就是分析出解決問題所需要的步驟，然後用函式把這些步驟一步一步實現，使用的時候乙個乙個依次呼叫就可以了。物件導向是把構成問題事務分解成各個物件，建立物件的目的不是為了完成乙個步驟，而是為了描敘某個事物在整個解決問題的步驟中的行為。例如五子棋，面向過程的設計思路就是首先分析問題的步驟 1 開始遊...