開放閉鎖原則と expression problem - Qiita
ソフトウェア原則[1] - OCP(Open-Close Principle) と云ふ記事に「(引用者註: プログラムをオブジェクト指向で書き直すことによって) 修正の論理を、追加の論理に変換している」と書いてあったのですがそれは公平なものの見方ではないと思ったのでここに記しておきます。 開かれてゐると云ふことの真実 元記事にある C++ で書かれた例では、 Shape 親クラスに Circle 子クラスを追加しても既存の Point 子クラスや Line 子クラスの実装を修正する必要はないことが示されてゐます。つまり、Shape クラスは新たな図形の種類を表す子クラスの追加に対して開かれてゐるといふことですね。 しかしこの C++ の例は、図形に対する操作の追加に対しては開かれてゐません。例へば、既にある draw (描画する) といふ操作に加へて translate (平行移動する)
クラスの命名のアンチパターン - Qiita
昔から「名は体を表す」と言ひます。クラスの名前がクラスの果たす役割と一致してゐるかどうか常に考へ続けませう。 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
提言: コミットメッセージの一行目には要求仕様を書け - Qiita
これは Git (や Subversion などのバージョン管理システム) にコミットする時により良いコミットメッセージを書くための提言です。この提言は特にメッセージの一行目だけを対象とします。せめて最も重要な一行目だけでも良いメッセージを書いて欲しいからです。提言をズバリ一言で表すと 一行目には要求仕様を書け です。 背景 プロジェクトによっていろいろ慣習の差はあるものの、一般的には「コミットメッセージの一行目は変更内容の要約を簡潔に書け」とされます。特に Git は、各コミットメッセージの一行目だけを取り出してそれを一覧表示するなど、一行目を特別に処理する機能が多いので、一行目にできるだけ多くの情報を凝縮させることは重要です。またメッセージを一行しか書かない不届きな慣習のプロジェクトでは、十分な情報を持たないメッセージは無用の長物と化します。 良くないコミットメッセージ しかし私は、情
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
