Question

在下文中，我提供了我的问题的抽象描述，因为如果我提供上下文和特定代码会更复杂。

我有一个班级Specification。文件读取器从文件访问特定的嵌套规范，并相应地提供Specification实例。该文件可能包含不完整的规范，即稍后将绑定某些值（例如，来自用户输入）。

class Specification{
    Criteria spec1;
    AnotherCriteria spec2;
    ...
}

现在考虑界面：

Interface Criteria {
    criteriaMethod1();
    criteriaMethod2();
}

考虑实施班：

class ConcreteCriteria1 implements Criteria{
    someDataMember;
    @Overrride
    criteriaMethod1(){
        // some implementation goes here
    }
    @Overrride
    criteriaMethod2(){
        // some implementation goes here
    }
}

现在让我们考虑一个负责执行某些特定任务的类，具体取决于传递的Criteria：

class WorkExcuter {
    doSomeWork(Criteria criteria);
}

我有一个案例，例如，传递给criteria的{{1}} 未知，处于等待状态以从用户那里获得一些输入。这种未知状态强制某些特定的附加属性，例如，它是字符的最大长度，标识符，等待时间等。为了对此进行建模，让我们考虑一下：

doSomeWork

问题：

我想要一种“智能”方式（例如某种设计模式）来制作两者，Interface ReuqiredInput { reuqiredInputMethod1(); }（在Specification数据memebr中）和spec1接受{当状态未知如上所述时，{1}}而不是标准。因此，他们应该接受这两种情况：doSomeWork或ReuqiredInput。

可能的解决方法：

除了Criteria之外，还要RequiredInput实施ConcreteCriteria1;即，具有实现两个接口的单个具体类;但是，我将把我的具体课作为一个丑陋的 ReuqiredInput 在两个不同的元素集之间彼此无关，它必须有一个方法来确定哪个集合填充元素（以避免异常，因为另一个集合将为null），并且它通过实现的接口使访问变得复杂。
重载Criteria;这样：
```
XOR
```
但是这解决了行为部分，而不是结构部分，即如何说服doSomeWork它可以接受class WorkExcuter { doSomeWork(Criteria criteria); doSomeWork(RequiredInput input); }类型Specification中的数据成员而不是sepc1 }

Answer 1

您的条件在不同的状态下没有不同的数据，它具有计算所需的任何数据成员，并且在等待用户输入时可能未设置;有各种选项可确保在继续进行主计算之前接收用户输入。例如

criteriaMethod1（）等可以根据需要以交互方式请求用户输入（可能是第一次调用它们）。没有使用RequiredInput对象。可能很乱，因为它将用户界面代码放在像Criteria这样的业务逻辑组件中。
criteriaMethod1（）等可以在调用不完整状态时返回错误，然后他们的调用者会询问他们需要什么输入（使用一些Criteria方法返回RequiredInput对象）。调用者使用RequiredInput对象获取信息，将该信息传递给Criteria，然后可以成功调用criteriaMethod1（）等。
更好的是，只有当所有需要的数据都可用时才会创建Criteria对象，并且它们永远不会处于无效的等待输入状态。对于将不完整的规范文件与用户输入组合的情况，这可能涉及表示配置文件内容的特定类和给定配置文件的模块，该模块询问用户缺少信息并创建条件。程序的其余部分，使用标准的部分，只能看到完整的部分。 RequiredInput对象可能非常有用，可以作为配置文件未指定内容的中间表示。

对未知（或待定变量）对象的可能性进行结构和行为建模，而不是具体的对象

1 个答案: