通过委托/策略与返回聚合结果来实现业务逻辑？答案

【问题标题】：Pass delegate / strategy vs return aggregated result to implement business logic?通过委托/策略与返回聚合结果来实现业务逻辑？
【发布时间】：2015-07-20 07:23:41
【问题描述】：

有些方法必须处理特殊情况。

例如，方法Print 必须处理用户在打印过程中手动取消打印（Canceled）或打印机缺纸（OutOfPaper）的情况。

情况不是错误也不是异常，因为它们是业务逻辑的一部分。

我看到了方法实现的两种变体。

变体 1：

public enum PrintResult
    Ok
    Canceled
    OutOfPaper
end enum

public function Print() as PrintResult

end function

方法Print 有一个独特的结果类型PrintResult，其中包含有关方法执行期间发生的情况的报告。

消费者调用方法Print，获取结果，分析结果，决定下一步做什么。

变体 2：

public Sub Print(CanceledAction as Action, OutOfPaperAction as Action)

end Sub

方法Print没有明确的结果类型，但是在特殊情况下要做什么是通过回调/委托/接口的方式传递给方法的。

当调用方法Print消费者提供的方法使用是特殊情况。

问题：

还有其他变体吗？
什么时候最好使用每个变体？

【问题讨论】：

标签： oop interface architecture callback delegates

【解决方案1】：

我投票支持返回结果。传递委托意味着该方法知道更多它应该知道的情况。

理想情况下，方法不应该知道某些操作甚至是可用的。它只是返回它的状态。是否有任何行动可以做出反应，这不是它的业务。

【讨论】：