面向对象设计的一个重要分析方法是利用对象的职责来驱动设计。对象有了职责,才会成为具体拥有意识的对象,成为对象社区中可以独立完成,或者发出指令委派别的对象协作完成职责的一员。将对象看成是“具有职责的东西”。对象应该自己负责自己,而且应该清楚地定义职责。这就是对象设计的关键。好的软件设计者应该像牧羊人一般放牧自己的牛羊,只需要给它们一片丰沃的草地,它们就能自己觅食生活。
Rebecca认为:对象在履行职责时有3种选择,你可以任选其一:(1)亲自完成所有的工作。(2)请求其他对象帮忙完成部分工作(和其他对象协作)。(3)将整个服务请求委托给另外的帮助对象。在分析对象职责时,可以考虑“专家”模式,即信奉专业的事情交给专家来完成,既不互相推诿,却也不能越俎代庖。专家有其擅长的领域,如果把专家错放在他不熟悉的领域,不仅会降低工作效率,还可能引入潜在危机。所谓“尺有所长,寸有所短”,含义正在于此。
对象的能力总是有限的,正如我们不能将所有的鸡蛋放在一个篮子里,我们也不能将所有的职责交给“上帝”。这既避免单一功能点带来的风险,又能实现职责的分权。Christepher Alexander建议,在遇到设计问题时“尽量少用集权的机制”。软件设计同样如此。职责总是可大可小,面对复杂的职责行为,总是需要多个对象的协作才能完成,就像机器中的零部件,按部就班,各司其职。
让我们来设计一个数据分析器,它通过分析算法对输入数据进行分析,并将结果保存在输出集中。根据业务需求的不同,执行的分析算法也不相同。同时,为了提高分析性能,我们还需要采用多线程方式执行分析任务。从调用者的角度来看【即Martin Fowler提到的规约视角】,我们只关心分析需要的数据以及分析后的结果。那么,谁应该来承担分析的职责呢?毫无疑问,我们可以定义分析器对象来履行这一职责。此外,调用者其实并不会关心分析算法的实现以及分析的过程,他希望分析是易于执行的,这一愿望通过有效的封装完全可以满足。我们可以将分析的职责封装在DataAnalyzer类中,同时隐藏具体的分析算法。
public class Client {
public static void run(InputData input) {
DataAnalyzer analyzer = new DataAnalyzer();
AnalyticResult result = analyzer.analysis(input);
// 做其它事情
// 处理分析后的数据
handleOutput(analyzer.output(result));
}
}
public class DataAnalyzer {
public AnalyticResult analysis(InputData input) {}
public OutputData output(AnalyticResult result) {}
}
然而,数据的分析并不是一件简单的事情。分析器虽然是分析的专家,却不精通多线程的执行。它自身无法提供分析的异步操作,这时就需要其他对象的协作。分析器将这一职责委派给TaskScheduler对象。TaskScheduler是一个任务调度器,可以发起任务的运行,并在运行完毕的时候,通知任务的发起者。对于TaskScheduler而言,并不会关心具体执行了何种任务。这样的设计能够遵循Demeter法则,让对象尽量保持无知,以避免不必要的依赖。
public class TaskScheduler {
private Task task;
public AnalyticResult beginRun(Task task) {
AnalyticResult result = new AnalyticResultImpl();
task.setResult(result);
this .task = task;
Thread thread = new Thread( this .task);
thread.start();
return result;
}
public OutputData endRun(AnalyticResult result) {
while ( ! result.beFinished()) {
result.wait();
}
return task.getOutputData();
}
}
TaskScheduler引入AnalyticResult对象的目的是为了判断任务执行的状态。它封装了当前的线程,从而可以获得当前线程的状态,并能够操作线程。
public interface AnalyticResult {
public void setCurrentThread(Thread thread);
public boolean isFinished();
public void finish();
public void wait();
}
DataAnalyzer的内部封装了对TaskScheduler对象的调用:
public class DataAnalyzer {
private TaskScheduler scheduler = new TaskScheduler();
public AnalyticResult analysis(InputData input) {
Task task = createTask(input);
return scheduler.beginRun(task);
}
public OutputData output(AnalyticResult result) {
return scheduler.endRun(result);
}
}
Task任务对象负责完成分析任务。虽然在之前的分析中,我们认为DataAnalyzer对象承担了分析数据的职责。不过,这一职责仅就调用者而言是可行的,对于DataAnalyzer的内部实现则不然。这基于两种原因。其一是分析过程的复杂程度,它需要对输入数据进行多个步骤的处理,包含数据的转换、过滤、运算以及存储。如果让DataAnalyzer一力承担,则可能导致职责过重,形成一个庞大的复杂对象。这既有碍于代码的阅读性,也不利于处理过程或算法的重用。其二是分析过程的可变性。根据不同的输入数据,需要不同的分析算法。DataAnalyzer不应该负责对算法的决策与选择。而且,随着需求的变化,数据分析器可能需要扩展。将任务抽象出来,可以很好地应对变化。
引入Task对象可以将DataAnalyzer从繁重的分析任务中解放出来,同时又能够保证它对分析任务的封装,是很好的对象协作表现。由于Task对象需要支持多线程,我们还需要它实现Runnable接口。至于ExecutionCallback是一个回调对象,注册该对象可以在任务执行完毕后调用它:
public interface Task extends Runnable {
public InputData getInputData();
public void setInputData(InputData input);
public OutputData getOutputData();
public void setOutputData(OutputData output);
public OutputData execute(InputData input);
public void setResult(AnalyticResult result);
public ExecutionCallback getCallback();
public void setCallback(ExecutionCallback callback);
}
public interface ExecutionCallback {
public void callback();
}
例如分析销售量波动的任务:
public class SaleWaveTask implements Task {
private InputData inputData;
private OutputData outputData;
private AnalyticResult result;
public OutputData execute(InputData input) {
inputData = input;
// 分析输入数据,获得销售量波动的情况
result.finished();
if (getCallback() != null ) {
getCallback().callback();
}
return output;
}
public void run() {
this .setOutputData(execute(getInputData());
}
public ExecutionCallback getCallback() {
return new ExecutionCallback() {
public void callback() {
System. out .println(
" The sale's wave task is completed. " );
}
}
}
}
之所以要在Task中为InputData和OutputData定义get、set访问器,是因为Runnable接口提供的run()方法不允许传入参数和返回结果。而在TaskScheduler中又只接受Task对象,利用这些方法可以在Task中存储和传递这些数据。
在DataAnalyzer类的定义中,不能忽略的另一个职责是Task对象的创建。虽然,DataAnalyzer的调用者也可以完成对Task对象的创建,并将创建好的对象传递给DataAnalyzer。然而,更好的做法是DataAnalyzer能够根据传入的InputData来决定创建哪一种Task对象。这样可以减轻调用者的负担。然而,一旦这样定义,DataAnalyzer的职责就显得混淆不清了。一方面它负责执行分析任务,另一方面又要承担创建Task对象的职责。这意味着它既是Task对象的使用者,又是Task对象的创建者。此外,DataAnalyzer对象并没有持有创建Task对象所必须的数据,违背了将数据与行为封装在一起的原则。因此,我们应该将创建的职责委派给其他对象。还有什么对象比得上“工厂专家”更适宜做创建的工作呢?最简单的做法是定义一个静态工厂:
public class TaskFactory {
public static Task create(InputData input) {
Task task = null ;
if (input.getType().equals(SALE_WAVE)) {
task = new SaleWaveTask();
task.setInputData(input);
}
return task;
}
}
为了更好地应对任务的变化,我们也可以引入配置文件来管理任务。Task对象的创建因配置信息的不同而变化。create()方法能够读取配置文件,然后根据配置信息来决定创建哪一种Task对象。
数据的分析任务事实上是按照一定的步骤来完成的。这些步骤可能会采取不同的顺序或组合方式来执行。每一种执行步骤就是一个算法,完成数据的收集、筛选、计算、分析和存储。Task对象负责将这些步骤整合起来,并封装到接口中,将这些算法实现以及执行算法的顺序隐藏起来。为此,我们可以定义一个实现了Task接口的抽象类,统一完成整合分析步骤的工作。
public abstract class AbstractTask implements Task {
protected AnalyticResult result;
protected List < Algorithm > algos;
public void registerAlgorithm(Algorithm algo) {
algos.add(algo);
}
public OutputData execute(InputData input) {
AnalyticData data = new AnalyticData(input, null );
processAlgorithms(data);
afterExecute();
return data.getOutputData();
}
protected void processAlgorithms(AnalyticData data) {
for (Algorithm algo : algos) {
algo.process(data);
}
}
private void afterExecute() {
result.finished();
if (getCallback() != null ) {
getCallback().callback();
}
}
public void run() {
this .setOutputData(execute(getInputData());
}
}
public class AnalyticData {
public AnalyticData(InputData input, OutputData output) {}
public InputData getInputData() {}
public void setInputData(InputData input) {}
public OutputData getOutputData() {}
public void setOutputData(OutputData output) {}
public void prepare() {}
public void complete() {}
}
任务的执行步骤被抽象为Algorithm接口,而AnalyticData则用于协调输入数据和输出数据,因为Algorithm对象在Task中形成了一条流水线,上一个Algorithm的输出是下一个Algorithm的输入。输入数据和输出数据形成了一种不可协调的共扼性,需要提供prepare()方法和complet()方法来完成二者之间的转换。
public interface Algorithm {
public void process(AnalyticData data);
}
public abstract class AbstractAlgorithm implements Algorithm {
public void process(AnalyticData data) {
data.prepare();
process(data.getInputData(), data.getOutputData());
data.complete();
}
protected abstract void process(
InputData input, OutputData output);
}
我们发现Task与AnalyticData都重复定义了InputData与OutputData的get、set方法。在设计和实现时,必须避免这样的重复代码。我们发现,这样的输入输出数据体现了数据池的概念,因此可以定义一个抽象的DataSink接口:
public interface DataSink {
public InputData getInputData() {}
public void setInputData(InputData input) {}
public OutputData getOutputData() {}
public void setOutputData(OutputData output) {}
}
AnalyticData类实现了该接口,而Task则可以持有该对象。
public class AnalyticData implements DataSink {}
public interface Task extends Runnable {
public void setDataSink(DataSink dataSink);
public OutputData execute(InputData input);
public void setResult(AnalyticResult result);
public ExecutionCallback getCallback();
public void setCallback(ExecutionCallback callback);
}
public abstract class AbstractTask implements Task {
protected DataSink dataSink;
protected AnalyticResult result;
protected List < Algorithm > algos;
public OutputData execute(InputData input) {
processAlgorithms(dataSink);
afterExecute();
return dataSink.getOutputData();
}
protected void processAlgorithms(AnalyticData data) {
for (Algorithm algo : algos) {
algo.process(data);
}
}
public void run() {
execute(dataSink.getInputData());
}
}
传递InputData对象的方式也发生了变化:
public class TaskFactory {
public static Task create(InputData input) {
Task task = null ;
DataSink dataSink = new AnalyticData(input, null );
if (input.getType().equals(SALE_WAVE)) {
task = new SaleWaveTask();
task.setDataSink(dataSink);
}
return task;
}
}
通过对分析器职责的分析,我们引入了DataAnalyzer、TaskScheduler、Task以及Algorithm等对象。这些对象的协作顺序如下图所示:
DataAnalyzer相当于分析器的外观,它总揽全局,管理着各种对象之间的协作,共同实现分析工作。TaskScheduler是任务的调度器,负责启动任务和结束任务,而它主要的职责则是封装了对多线程的处理,用以完成任务的异步调用。如果未来需求需要强化任务的调度模式,例如增加任务队列,以调度和管理多个任务的执行,则可以修改TaskScheduler而不影响它的调用者。Task对象体现了任务的独立性,同时又利用抽象统一了任务的执行方式,有利于任务的扩展。Algorithm则完成对任务的切分,将任务步骤单独封装,有利于各种算法的重用。这些对象的协作以一种层层委派的方式,实现了职责的分离,避免了“集权式”的对象。不同的职责可以分别演化,又能很好地协作,共同完成数据分析的整体职责。