2つの異なる環境で2つの異なるクラスを使用することに興味があります。両方のクラスは同じ構造(メソッド)を共有する必要がありますが、本番環境で使用されるクラスは「軽量」であり、検証や機能性、またはアクションが少なくなります。
例:フィールドのタイプ/存在をチェックしないSQLクエリクラス。その他の例:メッセージをログに記録して表示しないエラー処理クラス。
特定のデザインパターンがすでに存在していると思いますが、どれを掘り下げるべきかはよくわかりません。
2つの異なる環境で2つの異なるクラスを使用することに興味があります。両方のクラスは同じ構造(メソッド)を共有する必要がありますが、本番環境で使用されるクラスは「軽量」であり、検証や機能性、またはアクションが少なくなります。
例:フィールドのタイプ/存在をチェックしないSQLクエリクラス。その他の例:メッセージをログに記録して表示しないエラー処理クラス。
特定のデザインパターンがすでに存在していると思いますが、どれを掘り下げるべきかはよくわかりません。
これは私だけかもしれません...しかし、それは本当に悪い考えです。
開発/テストで実行していないコードをライブで実行するべきではありません。そうしないと、コードが適切に機能していることを確認する方法がありません (もちろん、コードを本番環境にプッシュして指を交差させる以外に)。
そのため、探しているものの良い例が見つかるとは思いません。
アップデート
あなたが説明したことは、元の質問の読み方とは少し異なります。その場合は、検証とログのレベルを指定する構成ファイルの「フレームワーク」を読み取ることができます。そうすれば、構成ファイルは環境間で異なっていても、同じコード ベースを実行できます。
私の場合、サンドボックスとライブ環境を備えた支払いゲートウェイがあります。私がしたことは、ファクトリパターン+インターフェイス(すべてのゲートウェイが同じ署名を持つため)+構成(システムがどのクラスをインスタンス化する必要があるかを知っている場所)を使用することでした
異なる環境で異なるコードを使用することはお勧めできません。
あなたのシナリオでは、特定の環境で避けたいことを構成の側面として外部化し、アプリケーションがデプロイされたときに詳細なログのオン/オフ、フィールドのサニティチェックのオン/オフなどを設定するのが最善のオプションだと思います.
環境への変更は、問題を回避するために一貫した方法で行う必要があります。バージョン管理システムと一貫したビルドおよびデプロイ プロセスは、そのための友達です。
本番環境と開発環境で異なるコードを実行しないという点に関しては、上記のコメントのほとんどに同意します。
そうは言っても、おそらくFactoryまたはFactory Methodパターンを探しているでしょう。