9

Design by Contract プログラミングのベスト プラクティスは何ですか。

大学では、契約パラダイムによる設計を学びました (OO 環境で)。問題に取り組むための 3 つの方法を学びました。

1) トータル プログラミング : その効果で考えられるすべての例外的なケースをカバーします (cf. 数学)

2) Nominal Programming : 前提条件が満たされた場合にのみ、正しい効果を「約束」します。(それ以外の場合の効果は未定義)

3) 防御的プログラミング : 例外を使用してメソッドの不正な呼び出しを知らせる

さて、さまざまな OO シナリオで、それぞれの状況での正しい使用法に焦点を当ててきましたが、いつ、どれを使用するかについては学習していません... (ほとんどの場合、演習によって強制される戦術..)

今、私が先生に尋ねなかったのは非常に奇妙だと思います (しかし、講義中は誰も質問しませんでした)。

個人的には、私は現在ノミナルを使用することはなく、前提条件を例外に置き換える傾向があります（したがって、「前提条件：除算器はゼロとは異なる必要がある」と述べるよりも、IllegalDivisionByZero をスローします）、意味のある合計のみをプログラムします（したがって、ゼロ除算の従来の値) ですが、この方法は個人的な調査結果と好みに基づいています。

だから私はあなたたちに尋ねています：

ベストプラクティスはありますか??

4

5 に答える 5

6

私はこの区分について知りませんでしたし、私の経験を実際に反映していません。

完全なプログラミングは事実上不可能です。すべての例外的なケースに対応できるとは限りません。したがって、基本的には範囲を制限し、範囲外の状況を拒否する必要があります (それがPre-conditionsの役割です) 。

公称プログラミングは望ましくありません。未定義の効果は禁止されるべきです。

防御的プログラミングは必須です。メソッドの不正な呼び出しは常に通知する必要があります。

私は完全な Design-by-Contract 要素の実装に賛成です。これは、私の意見では、Total Programmingの実用的で手頃なバージョンです。

メソッドの不正な呼び出しを通知するための前提条件(防御的プログラミングの一種)。コードを簡素化できるように、スコープをできる限り制限してください。範囲を少し狭めて、可能であれば複雑な実装を避けてください。

目的の効果が得られない場合にエラーを発生させる事後条件。たとえそれがあなたのせいであっても、目標を達成できなかったことを発信者に通知する必要があります。

オブジェクトの一貫性が保持されていることを確認するための不変条件。

于 2009-09-19T22:35:19.840 に答える
0

コンピューティングの多くと同様に、「依存する」がおそらく最良の答えです。

契約による設計/契約によるプログラミングは、関数の条件を明示的に文書化することにより、開発を大幅に支援します。ドキュメンテーションだけでも、(コンパイルされた) コードにしなくても役に立ちます。

可能であれば、すべての状態をチェックする防御的な方法をお勧めします。ただし、開発ビルドとデバッグ ビルドのみ。このようにして、条件が破られたときに、ほとんどの無効な仮定が捕捉されます。優れたビルド システムでは、さまざまな条件タイプをモジュールまたはファイル レベルでオンまたはオフにすることができます。

ソフトウェアのリリース バージョンで実行されるアクションは、システムと条件がどのようにトリガーされるかによって異なります (外部インターフェイスと内部インターフェイスの通常の区別)。リリース バージョンは「完全なプログラミング」である可能性があります。すべての条件で定義された結果が得られます (エラーまたは NaN を含む可能性があります)。

私にとって「名目上のプログラミング」は現実世界の行き止まりです。正しい値を渡した場合 (もちろん実際に渡しました)、受け取った値は適切であると想定します。あなたの仮定が間違っていた場合、あなたは崩壊します。

于 2009-04-15T12:53:40.510 に答える
0

テスト駆動プログラミングが答えだと思います。モジュールを実際に実装する前に、まず単体テストを作成します (コントラクトと呼びます)。次に、機能を徐々に実装し、コントラクトがまだ有効であることを確認します。通常、私は単純なスタブとモックアップから始めて、スタブを実際のものに置き換えながら、残りを徐々に埋めていきます。改善を続け、テストをより強力にします。最後に、上記のモジュールの堅牢な実装に加えて、契約のコード化された実装である素晴らしいテスト ベッドが得られます。後で誰かがモジュールを変更した場合、最初にそれがまだテスト ベッドに適合するかどうかを確認します。そうでない場合、契約は破られています - 変更を拒否してください。または、契約が古くなっています - 単体テストを修正してください。などなど..ソフトウェア開発の退屈なサイクル:)

于 2009-04-18T19:23:53.010 に答える