漫谈模式之雇工模式

本文我们来介绍一下雇工模式或者叫仆人模式（Servant design Pattern）。

雇工模式，它为一组类提供通用的功能，而不需要类实现这些功能。

雇工模式的基本介绍

意图

它为一组类提供通用的功能，而不需要类实现这些功能。此功能对于这些类是通用的，因此不必要在每个类中重复。

结构

雇工模式的结构大致如下：

这里涉及到的参与者有如下几种：

IServiced（接口）

“一组类”所具有的功能

ConcretedServiced（具体类实现IServiced接口）

具体类，实现IServiced接口

Servant雇工

提供了处理所需服务的通用方法，具体类则被作为参数（IServiced serviced）传递。

雇工模式的示例

假如，我们现在有几个几何对象的类，包含矩形、椭圆和三角形。我们可以在一些画布上绘制这些功能。如果，此时我们需要为这些对象提供“移动”功能。接下来，我们使用雇工模式的写法来完成一下功能。

示例一、移动位置

Movable（IServiced接口）

具体类实现（ConcretedServiced）

MoveServant(雇工)

定义一个雇工类“MoveServant”，它有两个通用方法“moveTo（Movable movedObject，Position where）”和“moveBy（Movable movedObject，int dx，int dy）。

写一个客户端调用一下。

此示例中，我们先定义了一个雇工Servant，然后完成了正方形和三角形的位置移动。

这样，一个简单的雇工模式示例就完成了。

小结

问题思考

Q1：真的需要Servant Pattern吗？如果在父类中实现？

虽说雇工模式是为一组类提供通用的功能。但是，这里一组类可能在同一继承层次结构中，也可能不在同一层次结构中。

比如：

在上述示例中，Movable是一个接口，而不是一个类，并且形状没有父类。在更复杂的情况下，类可以实现感兴趣的接口，同时驻留在不同的继承层次结构中。在这种情况下，没有一个通用的父级可以持有通用的方法。

当然，可以创建一个新的父类并将层次结构联合起来。不过，最好避免深层的类层次结构。太重。

Q2：Java的默认实现是否就可以？

Java的默认实现看上去貌似可以解决问题。不过，如果假如有多个不太一样的Servant。此时，扩展方法、Java的默认实现、继承等方法不能够动态地选择Servant。

优缺点

优点

扩展性较好，可以很容易地增加雇工来执行新的任务。

缺点

增加了程序的复杂度。

命令模式 vs 雇工模式

两者很像，主要是解决的方法不同。

对于Servant模式，主要用于提供一些通用的功能。我们创建一个类，该类的实例提供了该功能，并定义了服务对象必须实现的接口。然后将服务实例作为参数传递给服务对象。

对于命令模式，主要用于对动作或者命令的解耦。因此，我们定义了一个接口，该接口命令必须实现所需的功能。然后将这些命令的实例作为其方法的参数传递给原始对象。

适用场景

当我们想让一些对象执行一个共同的动作，又不想把这个动作定义为每个类中的一个方法时。

其实，我们在写一些SDK提供通用的功能的时候，可能已经使用雇工模式了。