Ch1 良好應用程式之基石
一.偉大軟體的三步驟
1.確認你的軟體做完客戶要它做的事：把重點放在客戶上，確保應用程式做它應該「先」做的事。這裡是收集需求與分析工作所著力之處
2.應用基本的OO原則，增加軟體的彈性：一旦軟體開始運作，找出任何可能因疏忽而產生的重複程式碼
3.努力達成可維護、可重複利用的設計
﹡別為了解決舊問題而產生新問題
二.步驟一：讓顧客滿意
1.使用列舉型別enum的方法或類別，會受到它的保護，因為enum裡不會有未定義的值。所以只要有打錯字，一定會事先被編譯器指出，不僅可確保型別的安全，也能確保值的安全
三.方法的分析
1.為正在試圖解決的問題，以文字清楚描述，確保你的設計與應用程式想達成的功能一致
四.封裝變化之物
1.任何時候看到重複的程式碼，就找個地方進行封裝
2.封裝背後的想法，是要保護應用程式某一部份的資訊免於其他部份的干擾
3.封裝的力量：透過分解出應用程式的不同部份，你可以改變一部分，而不需改變應用程式的其他部份。一般而言，你應該封裝應用程式可能變化很大的部份，讓它們遠離保持不變的部份
五.為可重複利用的應用程式而戰
1.委派：當物件需要執行某向工作時，不是直接進行該工作，而是要求另一個物件代為處理
2.委派讓你的程式碼更能重複利用，也讓每個物件關注自己的功能，而不是把處理單一物件行為的程式碼分散在整個應用程式
3.鬆散耦合意謂著：應用程式裡的各個物件都有特定的工作要做，而且只做那項工作。因此，應用程式的功能性被散佈在許多定義良好的物件，各自將單一工作做得很好
4.鬆散耦合的應用程式通常比較有彈性，且容易變更。因為每個物件都相當獨立於其他物件，你能輕易地改變一個物件的行為，而不必牽動其他的物件。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
Ch2收集需求
一.判斷客戶需要什麼
1.取得好需求的最佳方式，就是了解系統應該做什麼
二.好的使用案例分為三部份
1.清楚的價值：必須對系統有清楚的價值
2.起點與終點：必須有明確的起點與終點。某件事開始此流程，然後要有條件指明流程已完成
3.外部啟動者：是由外部啟動者所開啟
﹡使用案例是系統為完成目標所做的事，且焦點放在完成一個特定目標上
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
Ch3 需求變更
一.通往目標
1.替代路徑是包含在使用案例裡的一或多個步驟，是選擇性的或提供替代性的方式通過使用案例
2.替代路徑可能是增加到主要路徑裡的額外步驟，或提供步驟，讓你以完全不同於主要路徑的方式，到達使用案例的目標
3.具有額外步驟的替代路徑，只是一組使用案例主要路徑以外的額外步驟
4.你可以擁有多條替代路徑提供額外的步驟，以及多重方式起始條件到通往終止條件
5.從第一歩到最後一步通過使用案例的完整路徑，稱為使用情節
6.單一使用案例可以有多重使用情節，只要是每個使用情節，都會具有相同的客戶目標
7.一個使用情節是通過使用案例的單一路徑，從開始到結束
8.每個使用案例應該只聚焦在一個客戶目標。假如有多個目標，你將需要撰寫多個使用案例
二.一個使用案例，多個使用情節
1.任何時候你的使用案例變更，你必須回頭檢查你的需求
2.盡可能保持事情單純；若非必要，就別增加複雜度
3.有時候，需求的變更會揭露出關於系統中，你所不知道的問題
4.變更是常態，隨著你每次的實作，系統總是隨之改善
5.假如步驟在、系統裡的運作方式是選擇性的，或者是提供替代路徑通過系統，就使用次編號，像是1.1、2.1，或是1.1.1、2.2.1
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
Ch4 分析
一.UML放大鏡
1.allowedBarks:Bark[*]
方括弧是指屬性的多樣性：該屬性能保存多少個某特定型別的物件
星號代表allowedBarks能儲存任意數目的Bark物件數量
二.名詞分析
1.文本分析(textual analysis)：查看使用案例裡的名詞與動詞，並整理出類別與方法的動作。它告訴你焦點在哪裡，而不只是你該建立什麼類別
三.分析的力量
1.注意使用案例裡的名詞，即使它們不是系統裡的類別。名詞才是該應該聚焦的地方
四.動詞是操作
1.通常使用案例裡的名詞是類別，動詞是方法
五.關聯與多重性
1.從一個類別到另一個類別的實線稱為關聯。它表示一個類別與另一個類別相關，透過參考、擴展、繼承等達成
2.一條從來源類別通往目標類別的線，代表該來源類別具有一個目標類別的屬性
3.來源類別裡的屬性名稱寫在線條的目標端上
4.來源類別的屬性名稱後方的數字是指該關聯的多樣性，代表有多少個目標型別被儲存在來源類別的屬性裡
5.當你使用關聯表示屬性時，通常不會在類別的屬性區裡，寫下該關聯所代表的屬性
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
Ch5 良好的設計＝彈性的軟體
一.抽取共同行為
1.每當你在兩個或兩個以上的地方找到共同行為時，小心將該行為抽取到一個類別裡，然後以此共同類別，重複利用這項行為
二.再一點UML
1.當類別名稱為斜體字時，該則代表為抽象類別
2.具有菱形的實線表示聚合（aggregation），聚合是關聯的一種特別型式，表示一件事物是由另一件事物組成（部分地）
3.具有空心三角形的實線表示泛化（generalization）。泛化表示一個類別從更一般化的類別擴展及繼承的行為
三.這是偉大的軟體嗎？
1.要看看軟體是否設計良好的最佳方式之一，就是試著改變它
2.假如你的軟體不易改變，可能有些設計上的問題可以加以改善
四.OO大災難
1.介面：定義要應用在多個型別上的行為，以及作為使用那些型別之類別在使用時的焦點
2.對介面編碼，而不是對實作，會讓你的軟體更容易被擴展
3.在UML裡表示介面的方式：<<interface>>
4.封裝：保護類別免於不必要的改變
5.你應該總是將變化之物封裝起來
6.確保每個類別只有一個理由改變
7.透過減少該類別的變動因素，你會讓此類別變動的機會最小化
8.類別是關於行為與功能性
五.讓壞設計死吧
1.設計是反覆進行的，你必須願意改變自己的設計，以及你從其他程式設計師所繼承的設計
六.簡單的解法
1.當你有一組特性跨物件在變化，使用群集，像是Map，動態儲存那些特性
2.大多數的好設計都是透過分析壞設計而來的
七.容易變更嗎
1.具有內聚性的類別善於處理好單一事情，把焦點放在一件特定的工作上，但不試圖做其他事
2.內聚力是判斷應用程式裡類別的功能性有多緊密相關的一種量度
3.假如一個類別由全然相關的功能性所組成，它便只有一個理由改變
4.你的軟體越具有內聚性，類別之間的耦合度就越鬆散
5.高內聚力與鬆散耦合，意味著軟體越容易被擴展、分解與重複利用，因為軟體裡的所有物件不會交互依賴
6.每一次對軟體做改變，試著確認它變得越來越具有內聚性
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
Ch6 解決大問題
一.大型程式呢？
1.看待大問題的最佳方式，就是化整為零，將它視為許多個別的功能性片段
2.你可以將那些片段視為分別要解決的問題，並運用你已經知道的每一件事
二.你應該先做什麼？
1.這個系統像什麼？：你知道有什麼事情類似此系統的功能或行為？
2.這個系統不像什麼？
三.資訊、功能與需求
1.當你沒有很多資訊，並且需要知道從何著手時，從系統功能開始著手通常對大型專案很有幫助
2.功能只是關於系統需要做的某件事的高階敘述，通常由客戶訪談中取得諸項功能
3.你可以為一項功能想出一些可用來滿足該功能的不同需求，因此，將系統的功能整理出來，是開始掌握需求的好方式
4.從客戶取得功能，接著整理出實作這些功能所需要的需求
四.功能或需求？
1.假如一開始就卡住，特別是大型專案，你可以先收集功能或需求，對系統要處理那些高階事務，就可取得一定的掌握
2.功能與需求有許多重疊處，多少可以互相交換，因此，別「卡」在功能與需求之間的「差別」
3.功能是多項需求結合起來要滿足的「大事」
五.沒有價值，就沒有使用案例
1.使用案例不會總是幫你看出整體輪廓
2.當你在建造系統時，盡可能把細節往後延遲是個好主意
六.使用案例到使用案例圖
1.有時候，你需要知道系統在做什麼，但又不想深入使用案例需要的所有細節時，可以使用案例圖
2.以一個大方盒表示系統
3.大方盒內的橢圓形表示系統裡的單一使用案例
4.案例圖以一種簡單、易讀的格式，告訴你系統需要做的每一件事
5.使用你的使用案例圖，確認你列出的所有使用案例將涵蓋你從客戶那裡得知的所有功能。然後，你將知道你的使用案例圖示完整的，就可以開始建造該系統
七.說客戶的語言
1.領域分析：用客戶所能瞭解的用語描述問題，把建構系統時所想到的一切組合起來
2.別忘了真正的客戶是誰，領域分析幫你避免建造不屬於你的責任範圍的系統部分
八.Model-View-Controller
1.MVC是將應用程式的三個元件，分成不同軟體模組或程式單元的設計模式。這種劃分的目的是為了讓各元件能獨立演進，解除不同角色的軟體物件之間的耦合性，並確保一個模組的改變不至於不慎影響其他模組
2.Model代表應用程式的資料或狀態，如資料庫資訊
3.View是使用者看到的視圖，如網頁或使用者介面
4.Controller是應用程式與使用者的互動、做出回應的部分
5.控制器操作模型，模型通知視圖狀態改變
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
Ch7 架構
一.架構的威力
1.架構是你設計的結構，強調應用程式裡最重要的零件，以及那些零件之間的關係
2.你跟其他程式設計師共同合作時，你們全都必須了解相同的架構
二.我們還是在建造偉大軟體
1.第一個步驟總是先確認應用程式做它該做的事。在小專案裡，我們使用需求清單寫下功能性；在大專案裡，我們使用功能清單整理出那些事
2.所有的這些功能都關乎功能性，它們把焦點放在系統必須做什麼，而不是你要用什麼原則與設計模式來建造此系統
3.即使知道從聚焦於功能性開始，我們還是要整理出最重要的功能性片段是什麼，這些是我們想要先聚焦的功能性片段
三.架構三問
1.它是系統本質的一部份嗎？：該功能真的是系統實質意義的核心嗎？你能想像系統中沒有這個功能嗎？如果不能，那這個功能可能是系統本質的一部份
2.這到底是什麼意思？：假如你不確定某項功能的敘述究竟是什麼意思，把注意力放在該功能上可能是重要的。每當你不確定某件事情是什麼，它可能會花費你很多時間，或者對系統其他部分造成很多問題。要在專案早期把時間用在這樣的功能上，而不是晚期
3.到底如何做？：假如你不知道要如何處理某特定問題，最好花點時間正視該功能，因此，它不會在一路上產生諸多麻煩
四.想出什麼是重要的
1.系統的「本質」是指在最基本的層次上系統是什麼
2.當你檢視一項功能時，問自己：「假如這項功能沒有被實作，此系統還會是它應該是的東西嗎？」若答案是否定的，你便找到一個「本質功能」
3.在早期階段，你可能在取得系統的基本認知上漏掉某些細節，但是，在此階段，是該把那些細節補上的時候了，這是「架構三問」的第二問所關係到的事
4.從系統的核心片段、以及看起來可能特別難的事情開始，你將步上成功之路
五.關鍵是風險
1.不必爭論應該先從哪個關鍵功能開始，重點是在減少風險。你可以從中任選一個開始，只要你把焦點放在建造你應該建造的東西上
2.架構的要點在於減少風險，所以應只聚焦在會減少風險的事
六.真情指數－使用情節
1.假如你不需要使用案例的所有細節，撰寫詳述軟體能如何被運用的使用情節，可以幫你快速收集好需求
2.使用情節對快速的問題有幫助，並且能找到大部分的一般需求，但要記得，使用情節只是通過使用案例的「一條」路徑
3.假如你才剛開始，使用情節會是起步的好方法
七.如何撰寫圖版介面
1.設計原則：將建立的程式碼抽取到它自己的方法中，而不會對其他程式碼產生混淆而難以閱讀
2.對於隨機存取物件來說，使用ArrayList可以得到較好的效能；對於移除或插入物件來說，應使用LinkedList
3.一次只把焦點放在一個功能上，減少專案的風險
4.不要為無助於減少風險的功能分心
八.OOA&D與偉大軟體
1.有時候，撰寫偉大程式碼的最佳方式，是在允許的情況下，將程式碼的撰寫往後遞延
九.詢問客戶
1.每當你不確定某項功能的意義為何，以及要怎麼在系統裡實作該功能，可運用這三個步驟：詢問客戶（該功能的意義為何？）－＞共通性分析（如何在我的系統裡實現該功能？）－＞實作計畫
十.這是誰的工作？
1.關於功能，當你發現不同之事比相同之事還多時，可能就沒有一個良好、通用的解法
十一.偉大軟體與偉大程式碼
1.客戶不為偉大程式碼付你錢，而是為偉大軟體付你錢
2.偉大程式碼是設計良好的，並且會像它應該做的那樣運作；偉大軟體不只是設計良好，它還會準時被交付，並且做客戶要它做的事
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
Ch8 設計原則
一.什麼是設計原則？
1.設計原則是能被應用到設計或撰寫程式碼的工具或技術，讓程式碼更好維護、更具彈性，或者更容易擴展
二.關閉原則
1.設計原則#1：開閉原則（Open-Closed Principle, OCP）:類別應對擴展開放，對修改關閉
2.OCP讓你「擴展」你的有效程式碼，而不是「改變」當中的程式碼
三.不自我重複原則
1.設計原則#2：不自我重複原則（Don't Repeat Yourself Principle, DRY）:透過將共同之物抽取出來，置於單一地方，避免重複的程式碼
2.當你試著避免重複程式碼時，實際上也是在試著確保你對應用程式裡的每一個功能與需求只被實作一次，並且是在單一地方被實作
3.DRY是關於讓系統裡每一個資訊與行為的片段都存在於單一、合理的地方
四.單一責任原則
1.設計原則#3：單一責任原則（Single Responsibility Principle, SRP）:系統裡的每一個物件應該具有單一責任，所有的物件服務都應該聚焦在實現該單一責任上
2.當你的每一個物件都只有一個理由改變時，你已經正確地實作單一原則
3.DRY是關於把一個功能性片段放在單一地方，像是一個類別；而SRP是關於確認一個類別只做一件事，而且把事情做好
五.SRP分析
1.找出未使用的SRP類別：
在一張紙上，寫下The [空格] [空格] itself ->
在每一行的第一個空格里，寫下類別名稱；在第二個空格裡，寫下類別的方法之一 ->
讀每一行，看看是否合理？該類別真的具有該方法所指的責任嗎？
------------------
SRP分析：____類別
The ____ ____ itself
The ____ ____ itself
...
------------------
2.若讀的東西不合理，你的方法可能違反SRP。該方法很可能屬於別的類別，就將此方法移到其他類別去
3.為了讓SRP分析合理，你需要將方法的參數包含到方法的空格裡（即第二個空格）
六.Liskov替代原則
1.設計原則#4：Liskov替代原則（Liskov Substitution Principle, LSP）:子型別必須能夠替代其基礎型別
2.當子型別能替代其父型別時，才算具有正確合理的繼承關係
七.使用另一個類別的功能性
1.假如你需要使用另一個類別的功能性，但不想要改變該功能性，可以考慮以委派代替繼承
2.在UML中，以一般的關連（association）實線來表示委派
八.使用多個類別的行為
1.使用合成將來自其他多個類別的行為組合起來
2.當你想要使用由介面所定義的行為，並且從該介面的種種實作中選擇時，合成是最有威力的，不論是在編譯期間，還是在執行期間
3.合成讓你使用來自「一組其他類別」的行為，並且可以在執行期間切換該行為
4.在UML中，以實心菱形的實線來表示合成
九.合成與擁有
1.在合成中，由其他行為所組成的物件會擁有那些行為。當物件被摧毀時，其所有行為也會被摧毀
2.在合成裡的行為不存在於合成本身以外
十.聚合行為
1.聚合是當一個類別是另一個類別的一部分，但仍然可以存在於該類別之外
2.假如該物件（行為被使用的物件）是獨立存在於使用其行為的物件之外，應該使用聚合；假如不是的話，就選擇合成
3.在UML中，以空心菱形的實線來表示聚合
十一.超越繼承
1.委派（Delegation）：當你不想要改變某個行為，而實作該行為不是此物件本身的責任時，就將行為委派給另一個類別
2.合成（Composition）：使用合成，可以重複利用來自「一或多個類別」的行為，特別是來自於一個族群的類別。你的主要物件完全擁有被組成物件（composed objects），而且，被組成物件不存在於主要物件（main object或稱組成物件composing object）之外
3.聚合（Aggregation）：當你想要合成的好處，但是也想要在主要物件之外，使用被組成物件的行為時，就使用聚合
4.假如你的子類別真的可以替代它的基礎類別，使用繼承會比較合適
5.即使在聚合物件被摧毀之後，被聚合的行為仍會繼續存在
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
Ch9 反覆與測試
一.反覆進行、步步深入
1.偉大軟體的撰寫是反覆進行的
2.先針對整體概廓作業，接著反覆進行應用程式的每個片段，直到完成為止
3.功能驅動開發（Feature Driven Development）：你可以選擇聚焦在應用程式的特定功能上，此方式全然關乎取出客戶想要的一個功能性片段，並且對此規劃、分析及開發該功能，直到它完成
4.使用案例驅動開發（Use Case Driven Development）：你也可以選擇聚焦在通過應用程式的特定流程上，此方式取出通過應用程式的完整路徑（具有清楚的開始與結束），並且在你的程式碼裡實作該路徑
二.功能或使用案例？
1.在使用功能驅動開發時，你挑選單一功能，焦點是應用程式的功能清單
2.在使用案例驅動開發裡，你進行通過使用案例的單一使用情節，接著在取出另一個使用情節並且完成它，直到所有使用情節被完成。接著，在反覆進行下一個使用案例，直到所有使用案例都能運作
3.運用使用案例驅動開發時，你從使用案例圖開始，它會列出系統不同的使用案例。在此，你可以取出「建立圖版」使用案例，並且為此使用案例想出所有的使用情節，之後再撰寫程式碼以處理它們
4.功能驅動開發比較「細粒化」。單一功能往往相當小，所有的應用程式都包含多個單一功能
5.使用案例驅動開發比較「整體觀點」。你將一次進行好幾大塊的程式碼，因為單一使用情節往往涉及許多功能性
6.功能驅動開發特色：
（1）當你有許多未密切相連接的不同功能時，會進行得比較好
（2）讓你可以較快向客戶展示可運作的程式碼
（3）以功能為中心，採用此方式，你不會忘記任何功能
（4）對具有許多未連接之功能性片段的系統，進行得特別好
7.使用案例驅動開發特色：
（1）當你的應用程式有許多流程與使用情節，而不是個別的功能性片段時，進行得比較好
（2）讓你在每個開發階段可以向客戶展示較大的功能性片段
（3）以使用者為中心，採用此方式，你將為使用者使用此系統的所有方式來撰寫程式碼
（4）對交易式系統，進行得特別好
8.測試驅動開發：在為功能性撰寫程式碼之前，先為功能性片段撰寫測試情節，接著，撰寫軟體通過所有測試
三.客戶的聲音
1.你的客戶習慣看到程式執行在電腦上。所有的圖形與清單，在需求與應該建造的事情上，可能有助於你跟客戶取得共識，但在他們相信你已經建立任何有用的事情之前，你需要先想出一些測試情節（test scenario），將它們顯示給客戶看，證明你的程式碼能有效運作，能像客戶想要的那樣運作
2.你應該為所有能想到的可能使用狀況，測試你的軟體，要有想像力！
3.別忘了測試軟體的不正確使用狀況，你將在早期捕捉住錯誤
4.應在還沒撰寫程式碼之前就先擔心測試
5.假如你在撰寫程式碼之前就知道即將使用什麼測試，要想出需要什麼程式碼，好通過那些測試，會是很容易的
6.測試驅動開發聚焦在讓類別的行為正確上
7.測試驅動開發背後的核心觀念：撰寫測試案例，接著再撰寫將通過測試之程式碼的想法
8.要保持你的測試單純，讓它們一次只測試一個小功能性片段。你可能需要很多的測試，但保持每一個測試都聚焦在非常特定的功能性片段上
9.每個測試是聚焦在單一功能性片段上，而非單一的方法。單一功能性片段可能涉及一個方法，或一些方法，視其關聯性而定
四.不同觀點的問題
1.解法#1：強調共通性會讓你更好維護
2.解法#2：強調封裝會獲得更好的彈性
五.你必須抉擇
1.良好的軟體是經由反覆進行打造而成。分析、設計、再一次反覆進行，一次一次進行應用程式更小更小的部份
2.每當你反覆進行時，重新評估你的設計決策，假如對你的設計合理，就別害怕改變
六.測試案例檢視剖析
1.每個測試案例應該有ID與名稱
2.每個測試案例應該有一件特定的事要測
3.每個測試案例應該有你提供的輸入
4.每個測試案例應該有你預期的輸出
5.大部分的測試案例具有起始狀態
------------------------------------------
ID | 測試什麼 | 輸入 | 預期輸出 | 起始狀態
------------------------------------------
七.秀給客戶看
1.當你在撰寫軟體時，你也在建立軟體與其使用之間的契約，此契約詳述當某個行動被存取時，軟體將如何運作
2.當你按契約編程（program by contract）時，你與軟體的使用者正同意該軟體將以特定方式運作
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
Ch10 OOA&D 生命週期
一.組合所有片段
1.物件導向分析設計的生命週期：功能清單－＞使用案例圖－＞分析問題－＞需求－＞領域分析－＞初步設計－＞實作－＞交付
（1）功能清單：從高階觀點出發，找出應用程式應該做什麼
（2）使用案例圖：確認應用程式要執行的大流程，以及任何牽涉到外部的力量
（3）分解問題：將應用程式分解成功能性模組（modules of functionality），接著，決定以什麼樣的順序處理每個模組
（4）需求：為每個功能性模組想出個別的需求，並確定它們符合整體概廓
（5）領域分析：想出你的使用案例如何對應到應用程式裡的物件，確認你的客戶跟你有相同的認知
（6）初步設計：加入物件的細節，定義物件之間的關係，並且應用原則與設計模式
（7）實作：撰寫程式碼，進行測試，確認它有效運作。為每個行為、每項功能、每個使用案例、每個問題，做這些事，直到你完成
﹡需求～實作為反覆式開發
2.功能清單不只是你必須解決的難題清單，而是你的應用程式必須能夠做的所有事情的清單。因此，即使功能看起來簡單且微小，也要把它放在你的功能清單上
3.使用案例圖會幫你從應用程式的「做什麼」連結到「如何被使用」，那是客戶真正有興趣的事
4.使用案例反應使用性：在撰寫使用時，就是在處理行為者與系統之間的互動，就是在談系統被使用的方式（這就是「使用案例」一詞的由來）
5.功能反應功能性：你的系統必須做那些事，好讓使用案例能真正運作，即使功能性不總是任何特定使用案例清楚、明顯的一部分
6.使用案例倚賴功能才得以運作，但功能實際上可能不是使用案例本身的部份步驟
7.系統裡的每一個功能至少解決使用案例圖中一或多個使用案例的一部分，但那不表示使用案例就必須真的直接使用功能，許多時候，功能不需要被使用案例直接使用，就能讓使用案例有效運作
8.要實作系統的使用案例，你將需要系統功能裡的功能性。那就是為什麼你總是能夠將功能對應到它所賦予能力以及使用它的使用案例
9.系統的功能是系統所做的事，並且，不總是直接反應在你的使用案例裡，使用案例是顯示系統如何被使用
二.設計決策
1.你的設計決策應該根據你的系統如何被使用以及良好的OO原則
2.Java規格建議：假如兩個物件相等，它們應該具有相同的雜湊碼（hash code）。因此，假如你決定相等性是奠基於一個特性，那麼在覆寫equals()的同時，也要覆寫hashCode()，並且回傳基於同一個特性所計算出的雜湊碼。假如你正在Hashtable或HashMap裡使用你的物件，這是特別重要的，這兩個都相當程度地使用hashCode()方法
3.你的職責是在「確認客戶得到想要的功能」，與「確保程式碼具有彈性且設計良好」之間取得平衡
三.抽象化你的類別
1.你應該只將客戶需要與之互動的類別暴露給客戶
2.不與客戶互動的類別可以在對客戶端程式碼影響最少的情況下被改變
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
Ch11 本書遺珠
一.IS-A 與 HAS-A
1.IS-A關係到繼承；HAS-A關係到合成與聚集
2.使用繼承的時機是當一個物件的行為類似於另一個物件的行為時，而不只是因為IS-A關係成立
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
Ch12 歡迎光臨物件村
一.基礎回顧
1.繼承是一個類別擴展另一個類別，以重複利用或加強所繼承的類別行為
2.多型是子類別「代替」其父類別
3.封裝是將程式的一部分隱藏起來，與程式的其餘部份分開
沒有留言:
張貼留言