表題の通りですが、実装では極力要件通りに条件指定をするべきです。
従属的に求まる条件で代用できるとしても、その条件は原則として指定するべきではありません。
具体的に何が言いたいのか、なぜそう言えるのか、ということについて、以下で具体例を挙げて説明していきます。
----
例えば、
「商品区分が"1"の場合だけ、特別な処理をしたい」
という要件があったとします。
また、実装上は、
「商品区分が"1"の場合は、商品コードの2桁目が"1"になる」
という従属条件も存在するとします。
この場合、実装方針としては、以下の２つが考えられます。
方針１：商品区分が"1"であるかどうかを見る
方針２：商品コードの2桁目が"1"であるかどうかを見る
そして、この場合は、できる限り方針１で実装するべきです。
そう言える理由は以下の２つです。
理由１：可読性を損なわないようにするため
理由２：将来の変更に弱くなりにくくなるため（保守性の確保）
理由１については、新たな実装者を向かい入れることを考えるとわかりやすいと思います。
「商品区分が"1"の場合は、商品コードの2桁目が"1"になる」という従属条件を知っていれば何がしたいのかコードを見て推測できますが、そうでないとコードからは何がしたいのか推測できなくなるので、可読性が損なわれやすくなります。
理由２については、従属条件には例外がつきものということを意識する必要があります。
例えば、ある時点では「商品区分が"1"の場合は、商品コードの2桁目が"1"になる」が成り立っていたとしても、商品コードの採番が進むにつれて「取り扱う商品が多くなってきたので、商品コードの2桁目が"A"の場合も商品区分"1"として取り扱う」という例外が発生する可能性があります。
この際に実装の改修が発生してしまいますし、改修が漏れた場合は「商品コードの2桁目が"A"の場合に、特別な処理が行われなくなる」という障害になってしまいます。
----
従属的に求まる条件で代用する場合は、可読性・保守性以外の観点で止むに止まれぬ事情がある場合に限るべきです。
例えば、「納期に間に合わせるため」というのは、止むに止まれぬ事情の一つとして考えられます。
具体的には「要件通りの条件は連携されていない、連携してもらう時間もない」というような状況です。
しかし、止むに止まれず従属的に求まる条件で代用する場合は、可読性や保守性をできる限り損なわないようにする工夫をするべきです。
例えば、本来は何がしたいのか、ということをコメントに残すというのは、可読性を損なわないようにする上で重要です。
「要件通りの条件指定に直す」というタスクを作って管理する、というのも保守性を確保する上では良い工夫です。
