用解決小問題的相同方式解決大問題。

1.確認你的軟件做客戶要它做的事

2.運用基本的OO原則來增加軟件的靈活性

3.努力實現可維護、可重用的設計

看待大問題的最佳方式就是化整為零，將它視為許多單獨的功能片段（pieces of functionality）

你可以將那些片段的每一個創建為要解決的單獨問題，並且運用你已經知道的每一件事

可以將大問題分解成許多功能片段，接著解釋單獨解決每個片段

看幾個原則：

1.封裝（encapsulation）的使用有助於大問題的解決。封裝的內容越多，就越容易將大型應用程序分解成單獨功能片段

通過封裝變化之物，讓軟件更有靈活性，更容易改變。

2.對接口（interface）編碼，而不是對實現（implementation）編碼，讓軟件更容易擴展。

　　在大型應用程序中這一點很重要。通過對接口編碼，可以減少應用程序中不同部件之間的依賴性（dependency），而且松散耦合（loosely coupled）總是一件好事。

3.取得良好需求的最佳方式就是去了解系統應該做什麽。

　　假如知道應用程序的每一個功能小片段應該做什麽，那麽就很容易將那些小部件（part）結合成做該做之事的大應用程序。

4.分析（analysis）幫你確保系統能夠運作在真實世界的情景（context）中。

　　分析對大型軟件而言甚至更為重要，多數情況下，你從分析單獨的功能片段開始，接著分析那些片段之間的交互。

5.偉大軟件容易改變及擴展，並且做客戶要它做的事

　　應用程序的內聚力（cohesion）越強，每一個功能片段就越獨立，要同時運作那些小片段也就越容易。

看一個遊戲項目：

上面的框架，只是一個框架並沒有告訴我們具體一步一步要怎樣實施，所以我們要從客戶需求和用例開始，

這個系統像什麽？這叫共同性（commonality），你能找出系統更多信息的一個方法就是找出此系統像什麽，也就是說你知道有什麽事情與此系統的功能或行為類似。

這個系統不像什麽？這叫變化性（variability），你能找出系統應該做什麽的另一個好方法就是找出此系統不像什麽。這幫你決定什麽是系統中你不必擔心的事。

領域分析（domain analysis）讓你檢查你的設計，並且是以客戶所用的語言。識別、收集、組織及表示領域相關信息的流程，根據的是現有系統與其開發歷程的研究、領域專家捕捉到的知識、潛在的理論以及領域裏新興的技術。

領域分析幫你避免構建不屬於你的責任範圍內的系統部分。

MVC設計模式（Model-View-Controller），可以參考《Head First Design Partterns》(這個是我下一本要看的書)，會在一周之後開始看。

設計的框架藍圖，已經做好了。

這一章理論知識較強。沒有看懂沒有關系，因為什麽樣的理論只有在實踐中才能深刻的領悟其中的真諦，我們差的是實踐。

但是理論知識也很重要，沒有理論，我們實踐的時候就有可能走很長的彎路。

書的出現必有其道理，我們看了理論，接下來就是通過實踐來深刻理解其內涵，當你在實踐中走不下去的時候，在去回想一下我們之前學過的一些知識，柳暗花明指的就是那個時候。

第六章.解決大問題