TL;DR: 変数や関数を追加するときは、周りにある他の変数や関数の名前を修正すべきでないか検討せよ いきなりですが問題です。あるソフトウェアモジュールに以下の三つの関数があります。 show showWithSlideAnimation showWithoutAnimation 画面をスライドさせながら出現させるにはどの関数を使用すれば良いでせうか? 関数の名前だけを見て答へてください。 はい、その通り。showWithSlideAnimation が正解です。 では、画面をアニメーションなしで出現させたい場合はどの関数が良いでせうか? はい、showWithoutAnimation が正解ですね。 今度は、画面を回転させながら出現させたいとします。適する関数はあるでせうか? ブーーーッ! 残念、正解は「どの関数も適さないので新しく関数を実装する必要がある」でした。 これで最後です。画面

並行プログラミングの設計に関する本に関して適当にググると 「並行コンピューティング技法 ―実践マルチコア/マルチスレッドプログラミング」とか「マルチコアCPUのための並列プログラミング」とかいったものが出てくる。これらの本の主題は、ソートや探索などの比較的大きな計算問題をどのように並列化して解くか、そしてアルゴリズムを問題の大きさやスレッドの数に対してどうスケールさせるかといふことだ。 しかし、一般的な GUI アプリ開発では、GUI を操作するためのスレッドと他のスレッドとの通信や同期の仕方が問題になる。これがうまく出来てゐないアプリでは、例えば 処理を行ってゐる間、アプリが操作を受け付けなくなる 処理を開始するボタンを素速く二回クリックしたら、二つの操作の結果が混ざって出力されたり片方の結果しか出力されなかったりする などといった問題が発生したりする。 この類の問題を起こさないために必

irxground 君が再考: GoF デザインパターンといふ記事を書いてゐるので自分もちょっとコメントしてみます。 基本的に irxground 君と同意見のところは省略します。 あと、GoF の本自体は私は読んでゐません。 (GoF のパターン以外のパターンに関する意見の方が長くなってますね……。) GoF のデザインパターン 生成に関するパターン Builder そもそも builder パターンは Java の String と StringBuilder の様に可変オブジェクトと不変オブジェクトを別のクラスに設計しなければならない言語でしか基本的に役に立たないパターンであり、C++ の様にキャストだけで可変オブジェクトを不変オブジェクトに変換できる言語ではこのパターンは無用なはずである。 Java が出る前の本でこれがパターンとして挙げられてゐたといふのが俺には不思議に感じられる

昔から「名は体を表す」と言ひます。クラスの名前がクラスの果たす役割と一致してゐるかどうか常に考へ続けませう。 ImageInfo, AccountData, etc. Info って何やねん? Data って何やねん? ImageInfo って Image とはどう違ふねん?? FooInfo や FooData よりも好ましいかもしれない名前の例: FooAttribute, FooProperty, FooMetadata, FooDescription FooConfiguration, FooSetting, FooParameter FooResult, FooStatistics, FooSummary FooBuffer, FooList, FooCollection, ... ProductListItem, TranslationTableEntry, etc. Prod

これは Git (や Subversion などのバージョン管理システム) にコミットする時により良いコミットメッセージを書くための提言です。この提言は特にメッセージの一行目だけを対象とします。せめて最も重要な一行目だけでも良いメッセージを書いて欲しいからです。提言をズバリ一言で表すと 一行目には要求仕様を書け です。 背景 プロジェクトによっていろいろ慣習の差はあるものの、一般的には「コミットメッセージの一行目は変更内容の要約を簡潔に書け」とされます。特に Git は、各コミットメッセージの一行目だけを取り出してそれを一覧表示するなど、一行目を特別に処理する機能が多いので、一行目にできるだけ多くの情報を凝縮させることは重要です。またメッセージを一行しか書かない不届きな慣習のプロジェクトでは、十分な情報を持たないメッセージは無用の長物と化します。 良くないコミットメッセージ しかし私は、情