Strategic Choice
Problemこのクラスは大きすぎて、もうこれ以上大きくしたくありません。「単一責務の原則」を適用してクラスを分割しようと思います。分割の具体的な方法がわかりません。Strategy「クラスの抽出」を適用します。どんなとき？「単一責務の原則」を適用してクラスを分割しようと思います。責務を把握したので、分割の実装を行いますが、具体的な方法がわかりません。どうする？「クラスの抽出」リファクタリングを適用します。ほとんどのレガシーシステムにおいて、最初にできることは、「実装レベル」で単一責務の原則を適用することです。つまり、大きなクラスから「クラスの抽出」をして、抽出クラスに委譲することです。「インタフェースレベル」で単一責務の原則を導入するには、より多くの作業が必要です。クラスの呼び出し側を変更しなければならず、テストも必要になります。まず、実装レベルで単一責務の原則を導入しておくと、将来イン
カプセル化、情報隠蔽、データ隠蔽 - ぐるぐる～
あちこちのサイトを見てると、間違った解釈をしてるのが多い。カプセル化なんて、情報隠蔽まで含んでるのが常識になりつつあるような。。。ここまで一般化してると情報隠蔽してるのがカプセル化というのが常識なのかも。 カプセル化・情報隠蔽・データ抽象化 - 今日の役に立たない一言 − Today’s Trifle! − カプセル化と情報隠蔽、データ隠蔽の違いがよくわからくなったので、手持ちの本で調べてみた。 基準 基準としては、 カプセル化、情報隠蔽、データ隠蔽の関係 カプセル化は隠蔽を含んでいるかどうか 対象はクラスのみか、そうでないか などなど。 一番目はそのまんま。二番目は、 // 隠蔽せずともカプセル化か class Hoge { int hoge; // なんかhogeを使うメソッド } // 隠蔽しなければカプセル化ではないか class Piyo { private int piyo;
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.microsoft.com/language/ja/jp/search.mspx
