若您覺得文章寫得不錯，請點選文章上的廣告，來支持小編，謝謝。
偉大軟體的三大步驟
1. 確認你的軟體作客戶要他做的事
2. 應用基本的OO原則，增加軟體的彈性
3. 努力達成可維護，可重利用的設計
一個使用案例，三個部分
1. 清楚的價值(Clear value)：每個使用案例都必須對系統有清楚的價值。假如使用案例無助於客戶達成目標，這個使用案例便沒有什麼價值。
2. 起點(Starting point)與終點(Stopping point)：每個使用案例必須有明確的起點與終點。某件事開始此流程，然後要有條件指明流程已完成。
3. 外部啟動者(External initiator)：每個使用案例由外部啟動者開啟，有時，啟動者是人，有時，可能是系統外的任何事物。
查看使用案例裡的名詞（與動詞），並整理出類別的方法與動作，叫做本文分析（textual analysis）。
需求
1. 好的需求確保你的系統如客戶所預期地那樣運作。
2. 確認需求涵蓋系統的所有使用案例。
3. 運用使用案例找出客戶忘了告訴你的事。
4. 使用案例將揭露任何不完整、闕漏的需求，你可能必須將它們加到你的系統裡。
5. 需求將總是隨著時間改變（及成長）。
OO原則：
將變化之物封裝起來。
對介面撰碼，而不是對實做。
應用程式裡的每一個類別只有一個理由改變。
類別是關於行為與功能。
A cohesive class does one thing really well and does not try to do or be something else.
內聚力量度個別的模組、類別與物件各元素之間的連接度（degree of connectivity）。軟體的內聚力越高，應用程式裡每個類別的責任就定義愈好且愈相關（well-defined and related），每個類別就具有特定一組緊密相關的動作要執行。
每個類別都應該試圖確保這件事的發生只有一個理由，這件事代表許多設計不良的軟體片段之死。
Architecture is your design structure, and highlights the most important parts of your app, and the relationships between those parts.
應用程式裡真正重要的事情是架構上重要的(architecturally significant)，你應該先把焦點至於其上。
設計原則：
1. 開閉原則(OCP，Open-Closed Principle)：類別應該允許擴展而開放，禁止修改而關閉。
2. 不自我重複原則(DRY，Don't Repeat Yourself Principle)：透過將共同之物取出來，置於單一地方，避免重複的程式碼。
3. 單一責任元則(SRP，Single Responsibility Principle)：系統裡的每一個物件應該具有單一責任，所有的物件服務都應該聚焦在實現該單一責任上。
4. Liskov 替代原則(LSP，Liskov Substitution Principle)：子型別(subtype)必須能夠替代其基礎類別(base type)。
開發方式：功能驅動開發與使用案例驅動開發。
當你按契約編程(Program by contract)時，你與軟體的使用者正同意該軟體將以特定方式運作。
沒有留言:
張貼留言