tac*_*cos 17 oop model-view-controller design-patterns
我已经在设计模式上考虑了一段时间了,我刚开始看到如何在我的开发工作中更加刻意地将其中一些更加谨慎地融入其中.但是,我仍然对本书开头的MVC处理以及它与书的其余部分的关系感到困惑.
我使用过的大多数框架 - Spring,Yii,ASP.NET,甚至是Objective-C Cocoa(UIKit) - 都适合MVC范例.我得到了MVC,因为对我而言,它是一种分类对象以及它们应该如何相互消息或交互的有用方法.而且,即使你不打算以MVC方式思考,这些框架也会强加给你.
我也觉得我理解设计模式的前提:他们真的不喜欢子类化,他们喜欢抽象接口,他们努力松散耦合.我不能说我完全理解所有的模式或它们是如何有用的,但我对它有了一种感觉.
我的问题是:MVC和设计模式之间的相互作用是什么？他们在MVC应用程序示例的第一章中得到了什么？某些设计模式是否与MVC范例无关？我想知道,例如,Command模式应该如何适应MVC.这似乎非常有用的,但是我们创建了一个CommandModel与CommandController发送给其他控制器？我们只是Command按照书中的规定创建一个对象吗？基本上,我想知道MVC和设计模式的想法是完全不相交的,我只是不明白,或者是否有一些模式不适合模具.
Ste*_*and 10
我个人认为MVC是Observer Pattern的简化版本,它是Mediator Pattern的简化版本.
MVC:一个模型,一个视图,Controler管理它们之间的通信.
观察者模式:一个模型,多个视图(观察者/订阅者),并且发布者管理通信
中介模式:几种不同的模型,多个视图和中介管理它们之间的通信.
GoF书中的MVC用于桌面,它使用观察者模式来更新视图.GoF书中的命令示例适用于编辑器.
还有其他类型的MVC,使用其他设计模式可能并不明显:
MVC和MVVM之间有什么区别？
演示文稿抽象控制
GoF书中说:
...
从表面看,这个例子反映了一种将视图与模型分离的设计.但该设计适用于更普遍的问题:解耦对象,以便对一个对象的更改可以影响任意数量的其他对象,而不需要更改的对象知道其他对象的细节.Observer(第293页)设计模式描述了这种更通用的设计.
MVC的另一个特性是可以嵌套视图.例如,按钮的控制面板可以实现为包含嵌套按钮视图的复杂视图.对象检查器的用户界面可以包含可以在调试器中重用的嵌套视图.MVC支持使用CompositeView类(View的子类)的嵌套视图.CompositeView对象就像View对象一样; 可以在可以使用视图的任何地方使用复合视图,但它还包含和管理嵌套视图.
同样,我们可以将此视为一种设计,让我们可以像处理其中一个组件一样处理复合视图.但该设计适用于更普遍的问题,每当我们想要对对象进行分组并将组视为单个对象时,就会出现这种问题.这种更通用的设计由Composite(163)设计模式描述.它允许您创建一个类层次结构,其中一些子类定义基本对象(例如,Button),而其他类定义复合对象(CompositeView),将基元组合成更复杂的对象.
MVC还允许您更改视图响应用户输入的方式,而无需更改其可视化表示.例如,您可能想要更改它响应键盘的方式,或者让它使用弹出菜单而不是命令键.MVC将响应机制封装在Controller对象中.控制器有一个类层次结构,可以很容易地创建一个新控制器作为现有控制器的变体.
视图使用Controller子类的实例来实现特定的响应策略; 要实现不同的策略,只需用不同类型的控制器替换实例.甚至可以在运行时更改视图的控制器,以使视图更改其响应用户输入的方式.例如,可以禁用视图,使其仅通过为其提供忽略输入事件的控制器来接受输入.
视图 - 控制器关系是策略(315)设计模式的示例.策略是表示算法的对象.当您想要静态或动态替换算法时,当您拥有大量算法变体时,或者算法具有您想要封装的复杂数据结构时,它非常有用.
MVC使用其他设计模式,例如Factory Method(107)来指定视图的默认控制器类,而Decorator(175)则将滚动添加到视图中.但MVC中的主要关系由Observer,Composite和Strategy设计模式给出.
...