私は、プログラマーがインターフェイスで不変条件 (事前および事後条件) を指定できるようにする Java フレームワークを作成することを考えていました。目的は、コードをより堅牢にし、同じインターフェイスのさまざまな実装に対して記述する必要がある単体テストの数を減らすことです。
私は、プログラマーも書く不変条件でメソッドに注釈を付ける何らかの方法を作成することを想定しています。例えば
interface Sort {
int [] sort(int [] nums);
}
実装がソートされたリストを返すことを保証するために、アノテーションで装飾されます。この注釈は、任意の実装に対してコンパイル時に実行できる単体テストにリンクされます。
これはクレイジーなアイデアですか、それともより広いプログラミング コミュニティに役立つでしょうか?
これは、 JMLとESC / Javaに関連しているように思われます。どちらも、通常の一連の手法で提供されるよりも少し高いソフトウェア品質を必要とする種類のプロジェクトで、かなり広く採用されています。
契約による設計は素晴らしいアイデアだと思います。Java でその機能を提供するフレームワークをざっと見てきました。私が思いとどまっているのは、この種のフレームワークについてチームから賛同を得るのは難しい場合があるということだと思います。コード内に単体テストを埋め込むようなものなので、奇妙です。
Java のこの方向への主なうなずきである assert ステートメントは、数年前から出回っていますが、それが使用されることはめったにありません。アサート (特に単体テストと組み合わせて) を使用することには多くのマイレージがあり、それらを使用していくつかのバグを発見しました。人々がそれらを使用しないのは残念です。
乾杯、
イアン。
Bertrand Meyer の契約によるプログラミングのアイデアは、ほとんど死んでいると思います。彼は前条件と事後条件を Eiffel に組み込みましたが、その言語は使用規模でラテン語より下です。
契約ライブラリによる Java プログラミングが世の中にあります。契約者は1名です。しかし、その日は過ぎ去りました。実のところ、Eiffel でさえ、実稼働環境ではそれらをオフにする方法がありました。実行時のコストがメリットに見合わないからです。
Stack Overflow での Eiffel の質問は 6 つだけです。実際、わずかな割合です。「contract」を含む SO タグを検索すると、非常に少数のタグが表示されます。このサイトのトピックにはあまり関心がありません。世界で最も多くのプロのプログラマーを引き寄せていると主張しています。
素晴らしいプログラミングのアイデアはクレイジーではありません!!! きっと役に立つと思います。