委托模式与工厂方法——低耦合与高内聚设计原则初探续

#_00

在上一篇文章中，我讲了自己理解的低耦合与高内聚设计原则。其中提到我是在学习移动开发的过程中加深了这种理解。本文就将详叙移动开发中低耦合与高内聚设计原则的一种应用实例。

#_01

委托模式也许是新手最容易混淆的一件事，但要理解这种模式却很容易，不仅容易，而且对于反向加深对面向对象(OO)的理解也大有裨益。委托模式在移动开发中最广泛的应用在于对事件的响应处理。所谓事件响应，就是当发生一件事时，比如点击，滑动，键入等用户输入或有消息到达，应用程序下一步该如何做。在低耦合的设计原则下，答案显而易见：交给别人处理（也就是委托）。

#_02

委托模式最简单的例子就是工厂方法。工厂方法用于封装一个类的构造器，向外部隐藏构造器的细节。当我们想要实例化一个类A，应该调用类A的工厂类B的create()方法来获得类A的一个实例。对于工厂类B来说，类A就是它的产品。具体的流程是，我们先实例化工厂类B，然后调用B.create()方法获得一个类A的实例。

#_03

为什么要使用工厂方法？工厂方法并非如示例那样多此一举。当我们想要一台冰箱时，我们其实是指“买”一台冰箱，因为相比“生产”冰箱的复杂程度，“买”的行为更加简单。不是每一个人都会“生产冰箱”，但大部分都会“买冰箱”。所以，在工厂方法中，工厂类B就相当于生产冰箱的工厂（或卖场），B内部封装了生产冰箱的方法也就是冰箱类A的构造器A(params)，A的构造器也许需要各种各样的参数，但我们不需要关心，我们只需要掌握B的一个方法buy()就可以了，任何时候调用B.buy()都能获得一个冰箱类A的示例，你也许可以给buy()重起一个名字create()，这样看起来就和工厂方法差不多了。

#_04

工厂方法的一个扩展是，当你想买不同的冰箱时，只需要去不同的卖场，比如海尔与格力的专卖店也许外形会有不同，但他们都提供冰箱，区别在于一家提供海尔冰箱，而另一家提供格力冰箱。无论哪家卖场，你都可以调用buy()方法来获得冰箱，而不管你购买的哪款冰箱，它都会提供冷藏的功能restore()。在OO中，我们可以把卖场和冰箱共同遵守的约定称为接口，在有的语言中，这也被称为协议。比如所有声称自己是冰箱的类都应有一个restore()方法，而所有声称自己是卖场的类也都应实现buy()方法，并封装冰箱类的构造器。这样，虽然你最后获得的冰箱类在品牌brand和价格price属性上有可能不同，但能完成的功能都是一样的。你也可以把他们都视作普通的冰箱。

#_05

工厂方法的精髓正是委托模式，你想要一台冰箱吗？那你应该委托工厂为你制造而不是自己动手，低耦合和高内聚的体现：不仅将冰箱的功能独立出去，连生产一台冰箱的方法都单独构建了一个类。于是，市场上有了形形色色的冰箱，而程序也可以得到更有弹性的拓展。

#_06

移动开发中的事件处理正是基于委托模式，有事情发生？那我应该委托一个对象来处理这件事。对于事件的处理方法应写在那个专门的类里而不是写在你自己的类中。虽然有些操作系统也提供基于回调的事件处理模式，但那其实相当于你委托了自己来处理这件事，也就是delegate(self)。显然，这有违低耦合和高内聚原则，但有的时候，你并不需要凡事都由工厂代劳，比如洗衣服或缝扣子，所以，根据实际情况灵活选择设计模式，最终高效的创建和维护代码，才是最终的目的所在。