MVC减少编程复杂性

　　复杂性

　　复杂性是应用开发过程中最令人头疼的一个问题。每当在一个应用中增加一个功能时，它的复杂性通常呈几何级的增长。这种复杂性往往导致程序的开发无法再继续下去。这也是现在为什么许多应用只有Beta版本而没有正式版的原因。

　　专家将应用开发过程产生的复杂性分为两类，即非本质的（accidental）和本质的（essential）。本质的复杂性是对于解决目标问题所必然产生的复杂性，非本质的复杂性是由于选择了不适当的开发工具和设计工具而产生的复杂性。对于一个功能确定的程序来讲，本质的复杂性是确定的，而非本质的复杂性则是没有限制的。因此，一个应用的开发要想较顺利地取得成功，就需要尽可能地减少非本质的复杂性。

　　OOD的特点

　　面向对象的设计（OOD）将一个程序分解成根据具体的对象而设计的一系列元素。这些具体对象的行为和数据以一种叫做“类（class）”的编程单元进行打包。应用程序创建一个或多个这些类的例示，也称为“对象（object）”。类的行为是通过创建对象之间的关系组合在一起的。

　　OOD答应开发者用两种主要的方法来控制复杂性的增加。第一，OOD定义严格的出口语义，这答应开发者隐藏实现的细节，并且明确说明什么方法是其它的对象可以访问的。这个信息隐藏使得可以对大部分的代码进行修改而不影响其它的对象。

　　第二，OOD将对象之间的关系分为四类：继续、包容、使用和协调。适当地使用这些关系可以大大减少应用开发过程中本质的和非本质的复杂性。如，继续是产生面向对象设计中可再使用的主要因素。这个再使用性是通过代码共享和多态性获得的。这种再使用可以大大减少应用的本质的复杂性。包容答应一个类的用户在使用包容器时忽略被包容的类（class）。这个简化使设计者能够大大减少应用的非本质的复杂性。

　　可视化接口在OOD方面的不足

　　许多程序都需要可视化接口，这些接口由对话框、选单、工具条等组成。这些可视化接口的增加会引进OOD设计的不足，使得一个好的面向对象的设计走向反面。可视化接口有三个属性可能会给应用开发带来麻烦。

　　第一，可视化接口提高了传统的面向操作的拓扑结构。用户产生接口事件，如开关按键和列表框选择等，受到程序的一个模块的驱动并且用来对静态的数据进行操作。在设计中将这面向操作的拓扑结构同一个面向对象的设计混合在一起将导致对象之间的大量的杂合。

　　第二，用户接口通常对于同样的信息经常会需要许多不同的显示。如，一个客户选择列表框可以包含一个客户的名字和电话号码以及许多其它客户的名字。

　　当用户选择某个特定的客户后，他／她的名字和电话号码及其它全部相关的信息都会具体地显示出来。

　　除此之外，一个简单的程序可能具有不同的用户接口。如一个银行账户系统有一个接口用于出纳员来访问账户平衡、存款和取款，而监督者的接口则包含另外的信息并加上账号治理的功能。这些不同的接口很轻易导致类的扩展。

　　最后，可视化接口在整个设计阶段还会进行较大的改变。这些改变包括完全重新安排用户与系统的交互操作等。可视化接口的这些改变即使在最好的设计中也会增加应用开发的复杂性。

　　MVC弥补可视化接口/OOD的不足

　　模型／界面／控制器（Model／View／Controller，MVC）编程技术答应一个开发者将一个可视化接口连接到一个面向对象的设计中，而同时还可以避免我们上面讨论的几个问题。MVC最初是为Smalltalk语言而设计的。MVC通过创建下面三个层将面向对象的设计与可视化接口分开：

　　模型（Model）：模型包含完成任务所需要的所有的行为和数据。模型一般由许多类组成并且使用面向对象的技术来创建满足五个设计目标的程序。

　　界面（View）：一个界面就是一个程序的可视化元素，如对话框、选单、工具条等。界面显示从模型中提供的数据，它并不控制数据或提供除显示外的其它行为。一个单一的程序或模型一般有两种界面行为。

　　控制器（Controller）：控制器将模型映射到界面中。控制器处理用户的输入，每个界面有一个控制器。它是一个接收用户输入、创建或修改适当的模型对象并且将修改在界面中体现出来的状态机。控制器在需要时还负责创建其它的界面和控制器。

　　控制器一直决定哪些界面和模型组件应该在某个给定的时刻是活动的，它一直负责接收和处理用户的输入，来自用户输入的任何变化都被从控制器送到模型。

　　界面从模型内的对象中显示数据。这些对象的改变可以通过也可以不通过用户的交互操作来完成。如：在一个Web浏览器中负责接收页面的对象收集和装配栈中的信息，必须有某种方式来让这些对象通知界面数据已经被改变了。在模型变化时有两种方法来对界面进行更新。