Strategic Choice
Problemこのクラスは大きすぎて、もうこれ以上大きくしたくありません。「単一責務の原則」を適用してクラスを分割しようと思います。分割の具体的な方法がわかりません。Strategy「クラスの抽出」を適用します。どんなとき？「単一責務の原則」を適用してクラスを分割しようと思います。責務を把握したので、分割の実装を行いますが、具体的な方法がわかりません。どうする？「クラスの抽出」リファクタリングを適用します。ほとんどのレガシーシステムにおいて、最初にできることは、「実装レベル」で単一責務の原則を適用することです。つまり、大きなクラスから「クラスの抽出」をして、抽出クラスに委譲することです。「インタフェースレベル」で単一責務の原則を導入するには、より多くの作業が必要です。クラスの呼び出し側を変更しなければならず、テストも必要になります。まず、実装レベルで単一責務の原則を導入しておくと、将来イン
あなたのソースを汚くして生産性も下げている、たったひとつの間違い - よくわかりません
この内容には私も全面的に賛成で、クラスやフィールド、メソッド、名前空間など、とにかく文字として表れる名前には、必ず、例外なく、正しく誤解のない命名を徹底することが非常に重要だ。 http://blog.livedoor.jp/lalha/archives/50261226.html 先のエントリは、danさん*1やlalhaさんにまで言及いただき大変光栄で、なにより多くの人に読んでもらえた。多謝。 一方で、自分で読み直すと「先のエントリ」は、いくぶん観念的でいまいちよく分からないところもあるかなと思った。というわけで、より実践に結びつきやすいように、「何に気をつければいいのか」「どういう考え方でコードを書けばいいのか」を書いてみる。 lalhaさんがエントリで強調したかったという (1) 適当に書いたコードは後でとても大きな被害をもたらす可能性が高い への包括的な対策であり、 (2) たく
アイデア創発の素振り：SCAMPER法――「10分以内にアイデア3つ出さなきゃ」をかなえる方法 (1/4) - ITmedia Biz.ID
午後から新製品を考える会議。ふと、メールを見返すと「1人3つアイデアを持ってくること」という指示――しまった、見落としていた。しかし会議まであと20分しかないぞ。こりゃまずい。 という時にうってつけの方法がある。 例えば、アイデアを出し合う会議が午後イチにある。昼飯に行く直前、メールを見返したら「アイデアを3つ以上もってくるように」との指示があった。これはしまった。う～ん、急いで考えよう……あせるばかりで出てこないよ！ という極限状態にうってつけの方法がある。10分間あれば、アイデアを必ず3つ以上、発想できるのだ。 今、あなたがそういう状況ならば、ここから先はこの記事2ページ目以降を印刷し、ペンとプリントアウトした記事だけ持って、昼食に出てほしい。 名称 人数 道具 長所 SCAMPER（スキャンパー）法
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
