对比Windows OOP与Cocoa MVC

本文我们将介绍Windows OOP与Cocoa MVC之间的对比，在Objective-C里，你必须明确地创建一个controller用来处理model和view之间的变化。其实MVC应该被称做MCV，因为controller是在model和view之间的一个协调员。如果你的model发生了改变，你的controller会通知view。如果用户在view中做出了某种改变，controller就会通知model。所以我建议初学者可以叫它MCV，会更加形象一点。有点跑题了。

AD：

本文我们将介绍Windows OOP与Cocoa MVC之间的对比。在Windows里，尤其是C# .NET，你可以通过添加一个Form对象来创建新的窗口，而且还可以简单地在设计窗口中添加一些不同的“控件”。这些操作是非常容易的。不过一旦窗口创建好之后，你需要在主窗口的代码中建立刚才新建的窗口的实例，然后提供公共变量在两个窗口之间设置或者获取数据。窗口类是由Windows Form模板写好直接交给你使用的，这当然可以使代码看起来清晰干净，但是它打破了MVC的惯例，所以大部分Windows的程序员会花费不少时间提升他们思考的方式也就不足为奇了。

我用VS2008做了一个demo程序，截图大概是这样的：

看一下主窗口的代码：

   
   
public partial class Form1 : Form 
 
{ 
 
Panel p; 
 
? 
 
public Form1() 
 
{ 
 
InitializeComponent(); 
 
p = new Panel(); 
 
p.Show(); 
 
} 
 
? 
 
private void btnChangeText_Click(object sender, EventArgs e) 
 
{ 
 
p.OutputText = this.tbInputText.Text; 
 
} 
 
} 

注意看我声明了一个Panel的对象，这是我们需要在上面设置文字的第二个窗口(view)。下面是Panel类的代码：

   
   
public partial class Panel : Form 
 
{ 
 
public Panel() 
 
{ 
 
InitializeComponent(); 
 
} 
 
? 
 
public string OutputText 
 
{ 
 
set 
 
{ 
 
this.tbOutputText.Text = value; 
 
} 
 
} 
 
} 

好，代码很容易理解，但是从这里就可以看出我的观点：MVC模型已经被破坏了。虽然这个例子里面并没有任何编程逻辑，不过很清楚的是这样的设计导致你只需要把代码放到按钮的事件处理里面就可以了，而不是去将逻辑抽象到controller对象中。

你也许会问，我在C#中如何做MVC呢?呃……这是一个关于Objective-C、Cocoa编程的网站，对于读者们来说这是个作业了……不过坦白讲，我可不知道。我知道那是一件可能的事情，不过C#语言的内部就没有把开发者向这个方向去引导。我也看过一些讲这方面事情的文章，不过那些也都是基本上困难到没法实践的。有几篇号称是MVC不过根本不算，所以如果你真想在C#上面实现MVC，自己想办法弄吧……^o^ 我想说的其实就是要想在C#上面实现MVC，那算你狠。

Objective-C/Cocoa的方式

在Objective-C里，你必须明确地创建一个controller用来处理model和view之间的变化。其实MVC应该被称做MCV，因为controller是在model和view之间的一个协调员。如果你的model发生了改变，你的controller会通知view。如果用户在view中做出了某种改变，controller就会通知model。所以我建议初学者可以叫它MCV，会更加形象一点。有点跑题了。

在Objective-C/Cocoa的世界里，我们建立的controller通常是指应用程序(Application)的托管(Delegate)，或者可以简单称做app delegate。很多Windows程序员都会在这里迷惑不解的事情是，我们通常学习到的面向对象开发就是你应该去做的事情，而并不会关注为什么你会去做，或者你为什么不去做。我并不是说你别用OOP的思想，而正相反我建议去用。问题是如果把一切都抽象化，那就有点太傻叉了……我们应该有很好的理由去写这些代码，而不要用诸如“我从大学里面学的……”或是“我一直就这么干……”这种理由。

当你在Objective-C里面建立一个app delegate的时候，这个delegate可以做为你所有model和view的controller，或者你也可以为不同的model和view分别创建controller。想怎么干就怎么干吧。不过有一个比较重要的事情是要记住的，如果你把所有的代码都扔到同一个app delegate类里头，那你就有了一个超大的app delegate文件，很难看清楚。

一些例子程序

为了帮助那个提出问题的朋友，还有另外一些想从Windows开发转变到Cocoa开发的朋友们，我也写了点简单例子来帮助把这个问题变简单。如果你想让两个View，或者两个窗口可以互相之间通信，只要在他们之间传递消息就可以了。虽然把你的view们封装到它们自己的类中并不是坏事，不过通常来说真的没必要。在任何一种语言和任何一种平台上，都有实现这个功能的方法，所以就别管我没提到的事情了，我也没说这是唯一的方法不是……我说的方法是简单直接的方法，可以帮你更快的理解。

我同样建了一个简单的demo程序来演示上面说的，这里是截图：

你可以在这里下载例子。

这里是我提到的代码，只需要在app delegate的头文件中将你的view声明为outlet：

   
   
@interface AppDelegate : NSObject { 
 
IBOutlet NSTextField *inputText; 
 
IBOutlet NSTextField *outputText; 
 
} 

然后声明这样一个方法，在按下按钮之后会执行：

   
   
- (IBAction)updateText:(id)sender; 

最好要做的事情就是在IB里面把action和outlet连到AppDelegate对象上，任务完成。就这么简单。

为什么Windows的方法烂，Mac的方法赞

好吧，这个小标题仅仅是个玩笑，Windows专家们千万表喷俺。不过我的确认为C#设计用户界面的方式会把人们的代码搞得贼乱，而且明显不是MVC模式。

当然，又来了，怎么做还是看你自己，不过.NET的用户界面设计工具非常鼓励用户去破坏MVC模式。当你在设计器里面把一个按钮拽到窗口里，然后双击那个按钮的时候，它就自动地给你指到按钮点击事件代码里，大部分程序员就自然而然地在那里写代码了。当你在设计过程的时候，倒也没什么，不过它根本没有做什么来支持你将逻辑和表现分开。

在Objective-C里，想破坏MVC设计模式倒是很困难的事情。基本上你都必须遵循这个模式。甚至当你使用Interface Builder在app delegate和action及outlet中间建立连接的时候，都会带有一个可视的MVC表现。要连接app delegate类(你的controller)到outlet的时候(比如输入框)，你按住ctrl之后从AppDelegate拖拽一根线放到outlet上。当你想告诉AppDelegate执行一些动作，你要从触发动作的对象中拽到AppDelegate对象上。反过来是不行的。养成这样的习惯其实很好，只不过Windows的铁杆程序员会相当不习惯。

结论

从Windows程序员转到Mac程序员是有一点挑战的，不过你越早抛掉从前的开发的概念，就越容易接受Mac开发的概念。想想令狐冲吧……Mac的开发的确是不太一样的。要习惯这种开发思路，而不要试图沿用从前的习惯来进行Mac开发。

承认这一点吧兄弟们，工程师们都是很傲慢的，而且当学习一门新的语言、技术或是平台的时候，通常会认为他们已经很清楚了。最后这句的英文真的很棒，我不知道怎么翻译才能完美的表达这句话，和大家共勉：Goto is not inherently evil, you know? Until next time.