再战MVC（－）

除了这三种主要的设计模式，Gof最后也提到了MVC还使用了其它的设计模式，比如说工厂方法模式用来说明对一个view的默认的控制器，还有装饰模式用来为view增加一个滚动条等。但是在MVC模式里起主要作用的还是前面列出来的三个设计模式。

 

 

　书中提到由于[GOF95]是论述软件模式的著作的第一本，也是OO设计理论著作中最流行的一本，因此有些人常常使用设计模式(Design Pattern)一词来指所有直接处理软件架构，设计，程序实现的任何种类的模式。另外一种说法是强调要划分三种不同层次的模式：架构模式 (Architectual Pattern)，设计模式(Design Pattern),成例(Idiom)。成例有时称为代码模式(Codeing Pattern)。

 

 

面向对象软件大师Martin Fowler有本书叫做<< Patterns of Enterprise Application Architecture>>中文名叫<<企业应用架构模式>>。这本书就是关于如何将企业应用分层，以及如何组织各层工作的。例如这本书在第二部分深入讲解模式时，在谈到了Web表示层的时候就分析了MVC模式，从这些我们可以知道架构模式提供一些事先定义好的子系统，指定他们的责任，并给出把它们组织在一起的法则和指南，一个架构模式常常可以分解成很多个设计模式的联合使用。

 

　设计模式

 

设计模式描述在软件设计过程中普遍存在相互通信的组件中重复出现的结构，这种结构解决在一定的背景中的具有一般性的设计问题。

 

 

 代码模式（或成例）是较低层次的模式，并与编程语言密切相关。代码模式描述怎样利用一个特定的编程语言的特点来实现一个组件的某些特定的方面或关系。

 

　从上面的叙述中其实我们不难从一个软件系统中找到他们，因为三种不同的模式存在于它们自的抽象层次和具体层次上，所以少了其中任何一种模式，或者有一种设计的不好，都会给整个软件系统带来害处，如可维护性低等缺点。因为架构模式是一个系统的高层次策略，涉及到大尺度的组件以及整体性质和力学，它设计的好坏可以影响到总体布局和框架性结构。设计模式是中等尺度的结构策略。这些中等尺度的结构实现了一些大尺度组件的行为和它们之间的关系，所以设计模式的好坏不会影响到系统的总休布局和总体框架，但是它会影响到系统的扩展性，维护性等方面。代码模式是特定的范例和与特定编程语言有关的编程技巧。它不会影响到一个部件或子系统的中等尺度的结构，更不会影响到系统的总体布局和大尺度框架，但是会影响到一个中等尺度组件的内部，外部的结构或行为的底层细节。

 

MVC中的三个角色

 

 

Mod封装的是数据源和所有基于对这些数据的操作。在一个组件中，Model往往表示组件的状态和操作这些状态的方法，往往是一系列的公开方法。通过这些公开方法，便可以取得模型端的所有功能。

 

在这些公开方法中，有些是取值方法，让系统其他部分可以得到模型端的内部状态参数，其他的改值方法则允许外部修改模型端的内部状态。模型端还必须有方法登记视图，以便在模型端的内部状态发生变化时，可以通知视图端。我们可以自己定义一个Subject接口来提供登记和通知视图所需的接口或者继承 Java.util.Observable类，让父类完成这件事。