僕が今やってる例のプロジェクト*1で、この前、設計書を作ってお客さんに確認してもらった。 分厚い設計書で、何回も社内レビューをしてもらって、メッセージＩＤのマッピングなど細かい点をイライラしながら直して何度も印刷して、「最終版」、「最終版２」…

”理想”を追求して正攻法をとるべきか、”臨機応変さ”を良しとして寝技的に勝負するか、という話題は、形を変えて様々なところで目にする。 新規開発時の設計は理想論で組み立てていたはずが、運用保守になると、そうは行かなくなる。本当は、理想的な設計のは…

基本設計書は、顧客が見るから実装技術を意識してはいけない。 と、昔から呪文のように刷り込まれていたけど、 これ、、呪いが掛かってる。 基本設計書で実装技術を記述するのは違うでしょうけれど、基本設計で実装を意識して設計してはいけないということで…

システムのイベントを処理する責任をどのクラスが持つかを決めるための一般的原則が「コントローラー」パターンです。 コントローラーは、以下のどれかを表すクラスとし、システムイベントのメッセージを受け取ったり処理したりする責任を割り当てます。 シ…

クラス構成をよりシンプルにするための設計原則が「高凝集性（ハイ・コウヒージョン）パターン」です。役割的に関連性の高い責務（処理）は一つの要素（クラス・サブシステム）にまとめるというシンプルなパターンですが、これによりクラスの責務が1つのクラ…

変更による影響を小さくし、再利用性を高めるための設計原則が「疎結合パターン」です。 これは設計でのあらゆる意思決定において考慮すべき原則でもあります。 結合性の低いクラス群は、変更に対する影響範囲が少なく、再利用もしやすいものになります。 と…

あるクラスの新しいインスタンスを生成する責任を誰が持つべきかを決める一般的原則が「生成者」パターンです。そのオブジェクトを集約するオブジェクトが生成者となる。 そのオブジェクトを含むオブジェクトが生成者となる。 そのオブジェクトを記録するオ…

クラスへの責任割り当てパターンであるGRASPパターンを噛み砕きます。 「責任＝メソッド」をクラスに割り当てる一般的原則は「情報エキスパート」パターンです。 責任の遂行に必要な情報を持っているクラスを「情報エキスパート」と呼びます。必要な情報を全…