《thinking in JAVA》讀書筆記
阿新 • • 發佈:2019-01-04
以前跟別人討論問題時,有一些概念或思想無法表達。但在這本書裡找到了比較到位的理解,記錄下來。
黑體 - 原文
斜體 - 自己的想法,不代表作者觀點
為什麼要抽象
人們所能夠解決的問題的複雜性直接取決於抽象的型別和質量。
最NB的抽象莫過於周易。道即原理、規律。道本身就是抽象。周易是對抽象的抽象,所以能占卜天地,無所不知嗎?
什麼是物件
建模方式 | 語言代表 | 建模方法 | 優點 | 缺點 |
---|---|---|---|---|
“命令式”語言 | FIRTRABM\BASIC\C | 建立機器模型和實際待解問題模型之間的聯絡 | 難以編寫,維護代價,需要“程式設計方法” | |
另一種 | LISP\APL\PROLOG | 只針對待解問題建模 | 善於解決特定問題 | 超出特定領域則力不從心 |
OOP | 將問題空間中的元素在其解空間中的表示稱為“物件” | 通過新增新型別的物件使自身適用於某個特定的問題 |
OOP的挑戰之一,就是問題空間和元素和解空間的物件之間建立一對一的對映。
OOP仍然沒有跳出“建立機器模型和實際待解問題模型之間的聯絡”的圈子,只是用了一種更方便的方法。
過程程式與物件程式
面向過程:程式 = 資料結構 + 演算法
面向物件:程式 = 物件 + 訊息
物件具有狀態、行為和標識。
狀態 - 內部資料
行為 - 方法
標識 - 記憶體中唯一的地址
開發或理解一個程式設計
最好的方法之一就是將物件想像為“服務提供者”。程式本身將向用戶提供服務,它將通過呼叫其他物件提供的服務來實現這一目的。你的目的是建立(或者最好是在現有程式碼庫上尋找)能夠提供理想的服務來解決問題的一系列物件。
被隱藏的部分通常代表物件內部脆弱的部分。
訪問控制庫設計者可以改變類內部的工作方式而不用擔心會影響到客戶端程式設計師。
如果組合是動態發生的,那麼它通常被稱為聚合。
在建立新類時,應該首先考慮組合(相對於繼承來說)。
多型的原理
編譯 | 連結 | 執行時 |
---|---|---|
早捆綁 | 對特定的函式名產生呼叫 | 把呼叫解析為要執行程式碼的絕對地址 |
晚捆綁 | 保證被呼叫的函式存在 |
控制物件生命週期的方式
方式 | 方法 | 目的 | 缺點 |
---|---|---|---|
靜態方式 | 將物件置於棧 | 將儲存空間分配和釋放置於優先考慮的位置 | 在編寫時知道物件的數量、型別和生命週期,犧牲了靈活性 |
動態方式 | 堆 | 動態管理物件,靈活 | 慢 |
動態方式有這樣的一個一般性的邏輯假設:物件趨向於變得複雜,所以查詢和釋放儲存空間的開銷不會對物件的建立造成重大的衝擊。動態方式所帶來的靈活性正是解決一般程式設計問題的要點所在。