用解决小问题的相同方式解决大问题。

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》(这个是我下一本要看的书)，会在一周之后开始看。

设计的框架蓝图，已经做好了。

这一章理论知识较强。没有看懂没有关系，因为什么样的理论只有在实践中才能深刻的领悟其中的真谛，我们差的是实践。

但是理论知识也很重要，没有理论，我们实践的时候就有可能走很长的弯路。

书的出现必有其道理，我们看了理论，接下来就是通过实践来深刻理解其内涵，当你在实践中走不下去的时候，在去回想一下我们之前学过的一些知识，柳暗花明指的就是那个时候。

第六章.解决大问题