【问题标题】:how to define "isValid" function with reason如何用原因定义“isValid”函数
【发布时间】:2016-12-27 22:25:27
【问题描述】:

我正在尝试在我的文件生成程序中对某些状态进行建模, 在某一时刻:

  1. 我想查看数据的当前状态
  2. 如果数据有效,我想继续
  3. 否则我想告知用户我无法继续的原因

伪代码如下:

if(isValid()){
    writeFile()
} else {
    switch(getReason()){
        case FAIL1: doSomething1();
            break;
        case FAIL2: doSomething2();
            break;
        case FAIL3: doSomething3();
            break;
    }
}

不确定这样的方法是否正确,希望得到您的建议/意见。其中:总共有不到 10 个错误状态,并且在给定时间只有一个错误状态适用。

【问题讨论】:

  • 取决于有多少错误状态以及一次是否可以应用多个错误状态。问题未详细说明。
  • 更新了规范

标签: java error-handling


【解决方案1】:

我会为您的Reason 创建一个enum 并将您原因的所有具体信息放在那里。然后您可以使用来自原因的具体信息对doSomething 方法进行参数化。在我看来,这可能是String。使用这种方法可以更容易地扩展您的代码。 代码可能如下所示:

if(isValid()){
    writeFile()
} else { Reason reason = getReason(); 
    doSomething(reason.getMessage());
}

用你的枚举Reason

enum Reason {
    REASON1("message1"), REASON2("message2")/* ... */;

    private String message;

    private Reason(String message) {
        this.message = message;
    }

    public String getMessage() {
        return message;
    }

}

【讨论】:

    【解决方案2】:

    garnulf 的想法正朝着好的方向发展;但从面向对象的角度来看,它仍然不是一个非常好的解决方案。

    问题是:您已经提到了此处重要的关键概念:状态,如状态机

    你真的想在这里使用多态性:

    abstract class Reason() {
       String getMessage() { // just to show that there might be some shared code
       abstract void doSomething();
    

    那么你的 Reason 类会有不同的子类;最后,您的客户端代码归结为:

    getReason().doSomething();
    

    因为每个原因都知道如何处理自己!当然,这可能需要进一步思考——这取决于这些不同错误原因的真正含义。

    关键点是:您确实希望避免对枚举或字符串值进行任何类型的切换。如果有的话,您将此类开关隐藏在工厂内部,它们会返回一些抽象类/接口(工厂为您创建具体的子类/实现)。

    【讨论】:

    • 在本案中,Reason 无法决定下一步的行动,我们还能避免“切换”而不是“原因”吗?
    • @Suryavanshi 好吧,可能不容易。但是对于更具体的建议,您应该增强您的问题;可能会给出具体错误情况的示例,以及您对此的想法。
    • 错误状态可以是任何东西,比如“订单处理模块”可以报告订单失败,因为a. insufficient inventoryb. payment failed。在这个特定的例子中,“订单处理模块”将不负责对错误状态的反应,它可以只通知订单是成功还是失败。如果订单失败,那为什么!!
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2015-01-04
    • 2019-05-10
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多