「new」を見たら「具象」と考える newは具象クラスをインスタンス化する。しかし、コードの柔軟性を保つためにインターフェースを使いたい。 「new」の何が問題か 本当の問題は「変更」であり、変更によってnewの使用箇所がどのような影響を受けるのかという…

Decoratorパターンとは Decoratorパターンはオブジェクトに付加的な責務を動的に付与する。デコレータはサブクラス化の代替となる、柔軟な機能拡張手段を提供する。 スターバズコーヒー 継承を使って飲み物を増やすのはクラス爆発や硬直した設計になる。 継…

Observerパターンとは Observerパターンは、オブジェクト間の1対多の依存関係を定義し、あるオブジェクトの状態が変化するとそれに依存しているすべてのオブジェクトが自動的に通知され更新されるようにする。 ObserverパターンではPublisherをサブジェクト…

はじめの状態 共通の処理を抽象クラスに書きサブクラスが継承する。 いわゆる差分プログラミング。 飛ぶ振る舞いをもたせる必要が出てきた 飛ぶ振る舞いを基底クラスに追加したがDuckのすべてのサブクラスが飛ぶ必要はない。 コードに対する局所的な更新によ…

第7章 アーキテクチャ アーキテクチャとは、設計の構造であり、アプリケーション内において重要である部分とそれらの重要部分間での関係に着目する。 アーキテクチャとは、システムの組織化された構造である。各部分への分割、部分間の接続、相互作用メカニ…

第6章 本当に大きな問題の解決 今まではせいぜい10個程度のクラスのアプリケーションを開発してきた。より大規模なアプリケーションの開発はどうやって行うのか? →大きな問題も小さな問題と同じように解決する。 顧客が必要とする処理をソフトウェアが実行す…

第5章 後半 良い設計=柔軟なソフトウェア 柔軟ではないコードに対処する アプリケーションの変更時に問題が発生するのは、ソフトウェアの柔軟性が足りないから。「凝集度」を高めて結合の問題を解決する。 ・凝集度と結合度 設計におけるオブジェクトの責務…

第5章 良い設計=柔軟なソフトウェア この章で学ぶこと ソフトウェアの変更が困難になっていれば顧客からの変更要求に対応することが難しくなる。既存のソフトウェアの設計を改善することを通して、柔軟な設計を学ぶ。 ギターだけでなくマンドリンも扱えるよ…

第4章 分析 テキスト分析によって、今まで作成してきたユースケースを顧客が必要とする内容を表現するクラスやメソッドに変換する方法を学ぶ。 ソフトウェアは理想の世界ではなく、現実世界で動作する必要がある。 システムを不確実性が高く混沌とした現実世…

第3章要件変更 この章で学ぶこと 要件は常に変化する。設計やアプリケーションがどんなに素晴らしくても、やがてアプリケーションは成長し変更される。この章では、要件変更に対応するための方法を学ぶ。 今回の例では、リモコンを使用して犬用ドアを開閉す…

第2章 要件収集 この章で学ぶこと 素晴らしいソフトウェアへの第1歩は、顧客が必要としている処理の実行。 顧客の真の必要性をどのように把握するのか？顧客自身が真の必要性に気づいていない場合､顧客にどうやって気づかせればよいのか？ この章では、顧客…

『Head First オブジェクト指向設計』を読み始めた。顧客志向の考え方が非常に良いと思う。コードを書いてWebアプリケーションを作る目的は顧客の要望を叶え、必要な機能を提供することなのだ。コードが汚いとかきれいとかは結局、顧客にとっては関係ない。 …

Strategyパターン 目的 様々なアルゴリズムを､それが発生するコンテキストに応じて使い分けられるようにする｡ 問題 要求を行うクライアントや操作対象データによって､適用するアルゴリズムを選択する｡ 解決策 該当アルゴリズムの実装からアルゴリズムを個別…

Adapterパターン 目的 修正することのできない既存オブジェクトを､特定のインターフェースに適合させる｡ 既存のクラスを修正することなく､適切なインターフェース(メソッド)を追加することができる｡ 問題 使用したいデータや振る舞いが既存システム内に存在…

オブジェクト指向のこころ (SOFTWARE PATTERNS SERIES)作者: アラン・シャロウェイ,ジェームズ・R・トロット,村上雅章出版社/メーカー: 丸善出版発売日: 2014/03/11メディア: 単行本（ソフトカバー）この商品を含むブログ (6件) を見る まえがき デザインパ…