我最近有一些场景,代码的细微变化导致多个类的前提条件发生变化,我想知道合同设计是否应该是这样的。
public Goal getNextGoal() {
return goalStack.pop();
}
如果goalStack.pop()
具有堆栈不为空的前提条件,那么getNextGoal()
是否需要明确具有相同的前提条件?似乎继承前置条件会使事情变得脆弱,并且更改为队列或其他结构会将前置条件更改为getNextGoal()
,它是调用者,并且它是调用者的调用者。但似乎没有继承前置条件会隐藏合同和呼叫者,而呼叫者的呼叫者也不会知道前提条件。
所有调用者都知道并继承了他们调用的代码的前置条件和后置条件,或者调用者永远不知道更深层次的先决条件和后置条件是什么的神秘代码,这是一个脆弱的代码?
答案 0 :(得分:3)
这取决于你的调用方法究竟做了什么。 前提条件的重要一点是调用者负责实现前提条件。
因此,如果GetNextGoal方法的调用者应该负责提供非空堆栈,那么您还应该在GetNextGoal方法上设置前置条件。清晰的前提条件是代码合同的巨大优势之一,因此我建议您将它们放在呼叫者必须满足前提条件的所有地方。
如果您的代码看起来很脆弱,可能表示您需要重构某些代码。
似乎继承了 先决条件会成就 脆弱,并改为队列或 其他结构会改变 getNextGoal()的先决条件,它是 呼叫者,它是呼叫者的呼叫者。
如果您将队列公开给调用者并稍后更改(到另一个结构,就像您说的那样),那么调用者也必须更改。这通常是脆弱代码的标志。
如果要公开接口而不是特定的队列实现,那么前提条件也可以使用该接口,并且每次实现更改时都不必更改前置条件。从而减少了脆弱的代码。
答案 1 :(得分:0)
例外是一种解决方案,但可能对您的情况不可行。
记录如果没有目标会发生什么是正常的.E.G。这就是malloc()在C
中的作用我无法判断您是使用Java还是C ++或其他什么东西,因为每种语言都可能有更自然的方式来使用该特定语言。