「オブジェクト指向入門 第11章 契約による設計」を読んだ - $shibayu36->blog;

オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング) 作者:バートランド・メイヤー翔泳社Amazon これまでの続きで、「オブジェクト指向入門 第11章 契約による設計」を読んだ。「オブジェクト指向入門 第6章 抽象データ型」を読んだ - $shibayu36->blog; で紹介した抽象データ型と同様に非常に面白い章であった。プログラムの設計を考える時に役立ちそうな知識が自分の中で言語化されたので、今後の設計時や、コードレビューの指摘の時にも役に立ちそう。 この章は信頼性の高いソフトウェアを記述するために、表明という概念を解説してくれる。例えば、ソフトウェアが正しいとは何かについての議論や、事前条件・事後条件・クラス不変表明のような表明の種類の説明、それぞれの表明の役割、表明の使いみち、表明の監視などについての

[shiba_yu36]

契約による設計の章、非常にいい章だった

[nilab]

「オブジェクト指向入門 第11章 契約による設計」を読んだ - $shibayu36->blog;

[peketamin]

“れば、「スタックがいっぱいならばputは正しく機能しない」などといったものがある。” "開発時やデバッグ時には全ての表明を監視させるべきである"

[SWIMATH2]

開発時だけでも事前条件をチェックするのなるほど

[sona-zip]

契約、つまり関数仕様は明確に定義して仕様内なら正しくエラーを返してあげるべきだし、仕様外ならassertなどで実行側のバグとして通知してあげるのが基本だと思う そうしないとすべての関数でNullチェックが必要になる

[hamlet-r]

普通なら機能仕様とという言葉を使うんだろうけど、定義が曖昧で共通認識がうまく持てないことも多いので、契約と強い言葉で定義を厳密にするんだというアプローチは、面倒そうに見えるけど、結果的には早いと思う。