再考: GoF デザインパターン - Qiita
本投稿は私の主観によって書かれています。コメントは大歓迎です。もし長くなるようでしたら別途記事に投稿し、リンクを張っていただけると嬉しいです。 概要 GoFのデザインパターンは適当すぎるから、いい加減、修正されるべき。 参考までに各パターンに対するコメントを書く。 GoFのデザインパターン GoFのデザインパターンは適当であり、教科書通りに学ぶべきものではないように思う。 以下がGoFのデザインパターンの良くない原因だろう。 本が出版されたのは1994年であり、Java(1995)が出てくるよりも前だった オブジェクト指向が未成熟な時代にカタログ化された 現代のプログラミングと合致しないものが多い 「オブジェクト指向における～」と断っている以上、OOPに絡める必要があった パターンのいくつかに「多態性を用いると便利」という蛇足がついている 挙げたパターンに根拠がない 「とりあえず、23個ほ
コードカバレッジですか？もちろん100％ですよ、静的な意味で - Qiita
タイトルに反して、どうやらWikipediaによると型チェックはソフトウェアテストではないらしい。 プログラムを実行し、正しく動作するかどうか確認する作業 （略） 欠陥が存在することを示すことはできるが、欠陥が存在しないことは証明できない。 型チェックは一部ではあるものの、プログラムを実行するまでもなく正しく動くことを確認でき、欠陥が存在しないことの証明ができてしまうからだ。 しかし型チェックはテストコード同様、「プログラムの動作部分ではないが、プログラマのミスを避けるために追加で書かれるコード。本質的には無くてよい」ものであることに違いはない。 型チェックもソフトウェアテストってことにしておこうよ 従来のソフトウェアテストを「帰納的テスト」、型チェックのようなものを「演繹的テスト」と呼びたい。 型チェック自体をテストとすれば多くのソフトウェア開発でTDDを行っていることになる。これは単な
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
