neue cc - Tester-DoerパターンとCode Contracts
僕と契約して安全性の高いソフトウェアを作ってよ！というだけじゃ、何か、弱い。動機付けに足りない。という、分かったような分からないようなCode Contracts。困ったところは、で、何が嬉しいの？にたいする積極的具体的な動機付けを提供しにくいということ。契約をしっかり行うことで、強固なソフトウェアが設計出来ます。うーん、理念は分かりますけど実用的に便利ー？if hoge==null throw に毛が生えた程度のものだったら、ちょっとよくわからない。 // こういうコード見るともう目も当てられなくて、画面の半分が引数チェックで埋まってるよ！ public void Hoge(string arg1, string arg2, string arg3) { if (arg1 == null) { throw new ArgumentNullException("arg1"); } if (
neue cc - 基礎からのCode Contracts
ufcppさんのレポートとセッション資料は第7回日本C#ユーザー会 勉強会レポート - 日本 C# ユーザー会に。Code Contractsを説明する場合、通常は背後にあるDesign By Contractの説明をしてから流れると思うのですが、今回はufcppさんが前の時間で受け持ってくれたので、その辺は完全スルーで.NET上のCode Contractsの話のみにフォーカスしています。 標準入りしているようだけど何なの？→実際は標準入りとは全然言えません というところから入って、主眼はバイナリリライター、ということで、セッションでは.NET Reflectorを片手にどのようにリライトされるかを見ていきました。どう展開されるのかをそうして確認すると、仕組みが理解しやすいのではないかと思います。Reflector有料化ということで、代替も色々出てきているようですが、私はReflecto
とある契約の備忘目録。契約による設計(Design by Contract)で信頼性の高いソフトウェアを構築しよう。 - Bug Catharsis
「より堅牢で正確性の高いソフトウェアを作りたいぜ！」と願う.NETデベロッパーお待ちかねの、 契約による設計(DbC)をサポートするCode Contractsが.NET Framework4より利用できるようになります。 C#をベースとして契約による設計をサポートする「Spec#」を利用するという方法もありますが、 学習負担を軽減するためにと、マイクロソフトは言語を意識しなくても開発者が利用できるように、 Code Contractsとして.NET Frameworkで契約をサポートしてくれました。 これは、オブジェクト指向および、オブジェクト指向プログラミングが大好きな.NET開発者にとって、とても良い知らせです。 わたしも待ち望んでいたうちのひとりです。ありがとうマイクロソフト！！という気持ちでいっぱいです。 VisualStudio2010が4月12日（米国）にローンチされることが
Visual Studio 2010 後の世代のプログラミング(1) Code Contracts
Visual Studio 2010 「後」って事で VS2010 には正式には組み込まれてないんだけど、その後にリリースされた各種拡張がどんな感じでプログラミングに影響を与えるかの話。 (1)って事で連載。 というわけで最初は Code Contracts、Code Contracts については一回書いてるけど素晴らしく使える代物って事で導入から設定まで流した上で軽くイントロダクション まずダウンロード、DevLabs Code Contracts から Download Standard Edition / Download Premium Edition どっちか選んでインストールする。僕は Premium を選んでインストールしたぜって事でそれをベースに書きます。 （ってか Static Checker 無いと契約違反をビルド時に検出できないんで魅力半減っていうより魅力なっしんぐ
Code Contracts（契約）の使いどころ - jamzzの日記
「Code ContractsとPex - Jamzzの日々」に引き続いてCode Contracts（契約）の使いどころについて書きたいと思います。 Code Contractsで興味深いと思う点は契約の継承、特にインターフェイスやabstractのクラス（abstractのメソッド）に対する契約を記述できる点です。 契約による設計（契約プログラミング）における議論として、どの範囲にどれぐらいの厳密さで契約を記述するべきかということがあると思います。 この議論に対してはっきりと言えることはライブラリ、モジュール、コンポーネントのインターフェイス、特にフレームワークにおける拡張点にあたる部分については相当な厳密さで契約を記述することは確実に効果が期待できるということです。 フレームワークの拡張点に契約を記述しようとした場合にインターフェイスやabstractのクラス（abstractのメソ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
