大堀/書籍/オブジェクト指向における再利用のためのデザインパターン
をテンプレートにして作成
[
トップ
] [
新規
|
一覧
|
単語検索
|
最終更新
|
ヘルプ
|
ログイン
]
開始行:
[[大堀/授業関係]]
#contents
----
*オブジェクト指向における再利用のためのデザインパターン [#y6d53dd0]
--JAVAの開発を授業の一環として行ったが、ソースコードがあまりにも汚く可読性に欠けていたので、理解し、活用する。
*雑記 [#s5348228]
--メモ
**概論 [#q68c13dc]
**変更に対する設計 [#k832d0c8]
-再設計をしなければならなくなる原因と回避方法
--クラスを明白に規定してオブジェクトを生成するのはダメ!
---理由) 特定のインターフェースではなく、特定の実装を委ねることになる。
---回避) 間接的にオブジェクトを生成する。
---パターン) Abstract Factory, Factory Method, Prototype
--特定のオペレーションへ依存するのはダメ!
---理由) 変更しにくくなる。
---回避) 要求を実装に依存しないようにする。
---パターン) Chain of Resposibility, Command
--ハードウェアやソフトウェアプラットフォームへ依存してはダメ!
---理由) 他のプラットフォームへの移植がやりにくい。自信の最新版に合わせるのも大変
---回避) 依存度をできるだけ小さくして設計する
---パターン) Abstract Factory, Bridge
--オブジェクトが表現、実装へ依存しちゃダメ!
---理由) オブジェクトを変更した際にクライアントも変更する必要がある。
---回避) クライアントに対しては、表現、格納、実装などの情報を隠す
---パターン) Abstract Factory, Bridge, Memeno, Proxy
--アルゴリズムへ依存しちゃダメ!
---理由) アルゴリズムを拡張し、最適化し書き換える時に大変
---回避) 変更する可能性のあるオブジェクトは局所化する。
---パターン) Builder, Iterator, Strategy, Template Method, Visitor
--密な結合はしちゃダメ!
---理由) 個別に再利用するのが大変。
---回避) 抽象化あるいは階層化技法を用いて実装する。
---パターン) Abstract Factory, Bridge, Chain of Responsibity, Command, Facade, Mediator, Observer
--サブクラス化による機能の拡張はしちゃダメ!
---理由)
***デザインパターンを用いた設計問題の解き方 [#mea828cd]
-システムをどのようにオブジェクトに分割するか?
--カプセル化、粒度、依存関係、柔軟性、性能、進化、再利用性を考慮する
--アプローチ 1
++問題文を書く
++名詞、動詞を抽出し、対応するクラスとオペレーションを生成する
--アプローチ 2
++システムにおける協調と責任に焦点を絞る
--アプローチ 3
++実世界をモデル化し、分析過程でみつけたオブジェクトを設計に変換する
--設計結果をより柔軟に再利用可能な形態にする段階で発見するオブジェクト[重要]
---Strategy: 交換可能なアルゴリズムの実装方法を記述
---State: 実体の状態をオブジェクトとして表す
-オブジェクトの粒度の決定
--Facede: オブジェクト群を用いて完全なサブシステムの表現を記述
--Flyweight: 最適な粒度で数多くのオブジェクトを支援するかを記述
--Abstract Factory, Builder:他のオブジェクトを生成することのみを責任として有するオブジェクトを生成
--Visitor, Command: 他のオブジェクトやオブジェクトのグループに対する要求を実装することのみを目的としたオブジェクトを生成
-オブジェクトのインターフェースを規程?
--型(タイプ)
---インターフェースを表現するのに使われる。
--オペレーションのシグニチャ
---名前
---パラメータ
---戻り値
--シグニチャのまとまり: オブジェクトに対するインターフェース
---オブジェクトに送ることのできる要求を明記している
-オブジェクトの実装を規程
--オブジェクトの実装はクラスによって定義する
--オブジェクトの内部データ、表現、オペレーションを定義する。
-理解しておくキーワード
--オブジェクト
---データ、データを操作する手続きをパッケージ化するもの
---クライアントからの要求を受けたときにオペレーションを実行する
--メソッド、オペレーション
---手続き
---オブジェクトの内部データを変更する唯一の方法(参考:カプセル化)
--要求
---オブジェクトに対してオペレーションを実行させる唯一の方法
***分類方法 [#je4d2cd9]
-分類方法には複数あり、多くの分類方法を知ることで各パターンの理解が深まる。
-本書で説明するパターン分類[他にも分類方法はある]
--目的別
生成: オブジェクトの生成
構造: クラス、オブジェクトの生成
振る舞い: クラス、オブジェクトの通信の方法を特徴付け、責任を分担する
--範囲別
クラス: クラスとサブクラス間の関連を扱う -> 静的
オブジェクト: オブジェクト間の関連を扱う -> 動的
-本書で説明するパターンの動作
--生成
クラス: オブジェクトの生成の一部をサブクラスに委ねる
オブジェクト: オブジェクトの生成の一部をオブジェクトに委ねる
--構造
クラス: 継承を用いてクラスを構成する
オブジェクト: オブジェクトをまとめる方法を記述する
--振る舞い
クラス: 継承を用いてアルゴリズムや制御のながれを記述する
オブジェクト: オブジェクトのグループがどのように協調するかを記述する
-> 複数のオブジェクトを利用しタスクを推敲するため
----
-パターン
--開発する際の経験を明確に表すもの
パターン名:問題・解法・結果を一語で表した名称
問題: 対象としている問題
解法: 解法手順。ただし具体的な実装は記述せず、抽象的な記述にする
結果: 容量・時間に関して。柔軟性、拡張性、移植性に関わる
-MVC(Model View Controller)
--ユーザインターフェースを構築するのに必要な概念
Model: アプリケーションオブジェクト
View: 画面の表現
Controller: ユーザ入力に対するユーザインターフェースの働き
--例
---Modelは複数のViewを持てる(Observer)
---Viewは複合化できる(Composite)
---Controllerは応用メカニズムをカプセル化する(Strategy)
---Factory Method, Decorator他
-デザインパターンの記述方法
--図形
---重要・有用だが、決定事項・代替案・トレードオフが記録できないので不十分
--テンプレート
---情報の均質性、比較有用性、利用性アップ。
---例) 本書のテンプレート
パターン名と分類: 1.5節の表参照
目的: 原理、意図、対象の問題
別名: よく知られた別名
動機: パターン内の構造が問題をどのように解くかを記述するシナリオ。抽象的な記述を理解するため。
適用可能性: 適用状況。他人の認識を予見する。
構造: OMT(Object Modeling Technique)に基づく手法を用いて図形的に表現したもの
構成要素: パターン内のクラス・オブジェクトとその責任分担
協調関係: 各構成要素の協調方法
結果: 目的に対するパターンの解決結果。トレードオフ。可変部分の詳細
実装: 実装する際の注意点、ヒント、技法、言語に依存した問題
サンプルコード: 実装方法
使用例: システムで利用されているパターンの例
関連するパターン: 密接に関連したデザインパターン、違い
**メモ [#qd884c29]
-オブジェクトインスペクタ
-サブクラスのインスタンス
終了行:
[[大堀/授業関係]]
#contents
----
*オブジェクト指向における再利用のためのデザインパターン [#y6d53dd0]
--JAVAの開発を授業の一環として行ったが、ソースコードがあまりにも汚く可読性に欠けていたので、理解し、活用する。
*雑記 [#s5348228]
--メモ
**概論 [#q68c13dc]
**変更に対する設計 [#k832d0c8]
-再設計をしなければならなくなる原因と回避方法
--クラスを明白に規定してオブジェクトを生成するのはダメ!
---理由) 特定のインターフェースではなく、特定の実装を委ねることになる。
---回避) 間接的にオブジェクトを生成する。
---パターン) Abstract Factory, Factory Method, Prototype
--特定のオペレーションへ依存するのはダメ!
---理由) 変更しにくくなる。
---回避) 要求を実装に依存しないようにする。
---パターン) Chain of Resposibility, Command
--ハードウェアやソフトウェアプラットフォームへ依存してはダメ!
---理由) 他のプラットフォームへの移植がやりにくい。自信の最新版に合わせるのも大変
---回避) 依存度をできるだけ小さくして設計する
---パターン) Abstract Factory, Bridge
--オブジェクトが表現、実装へ依存しちゃダメ!
---理由) オブジェクトを変更した際にクライアントも変更する必要がある。
---回避) クライアントに対しては、表現、格納、実装などの情報を隠す
---パターン) Abstract Factory, Bridge, Memeno, Proxy
--アルゴリズムへ依存しちゃダメ!
---理由) アルゴリズムを拡張し、最適化し書き換える時に大変
---回避) 変更する可能性のあるオブジェクトは局所化する。
---パターン) Builder, Iterator, Strategy, Template Method, Visitor
--密な結合はしちゃダメ!
---理由) 個別に再利用するのが大変。
---回避) 抽象化あるいは階層化技法を用いて実装する。
---パターン) Abstract Factory, Bridge, Chain of Responsibity, Command, Facade, Mediator, Observer
--サブクラス化による機能の拡張はしちゃダメ!
---理由)
***デザインパターンを用いた設計問題の解き方 [#mea828cd]
-システムをどのようにオブジェクトに分割するか?
--カプセル化、粒度、依存関係、柔軟性、性能、進化、再利用性を考慮する
--アプローチ 1
++問題文を書く
++名詞、動詞を抽出し、対応するクラスとオペレーションを生成する
--アプローチ 2
++システムにおける協調と責任に焦点を絞る
--アプローチ 3
++実世界をモデル化し、分析過程でみつけたオブジェクトを設計に変換する
--設計結果をより柔軟に再利用可能な形態にする段階で発見するオブジェクト[重要]
---Strategy: 交換可能なアルゴリズムの実装方法を記述
---State: 実体の状態をオブジェクトとして表す
-オブジェクトの粒度の決定
--Facede: オブジェクト群を用いて完全なサブシステムの表現を記述
--Flyweight: 最適な粒度で数多くのオブジェクトを支援するかを記述
--Abstract Factory, Builder:他のオブジェクトを生成することのみを責任として有するオブジェクトを生成
--Visitor, Command: 他のオブジェクトやオブジェクトのグループに対する要求を実装することのみを目的としたオブジェクトを生成
-オブジェクトのインターフェースを規程?
--型(タイプ)
---インターフェースを表現するのに使われる。
--オペレーションのシグニチャ
---名前
---パラメータ
---戻り値
--シグニチャのまとまり: オブジェクトに対するインターフェース
---オブジェクトに送ることのできる要求を明記している
-オブジェクトの実装を規程
--オブジェクトの実装はクラスによって定義する
--オブジェクトの内部データ、表現、オペレーションを定義する。
-理解しておくキーワード
--オブジェクト
---データ、データを操作する手続きをパッケージ化するもの
---クライアントからの要求を受けたときにオペレーションを実行する
--メソッド、オペレーション
---手続き
---オブジェクトの内部データを変更する唯一の方法(参考:カプセル化)
--要求
---オブジェクトに対してオペレーションを実行させる唯一の方法
***分類方法 [#je4d2cd9]
-分類方法には複数あり、多くの分類方法を知ることで各パターンの理解が深まる。
-本書で説明するパターン分類[他にも分類方法はある]
--目的別
生成: オブジェクトの生成
構造: クラス、オブジェクトの生成
振る舞い: クラス、オブジェクトの通信の方法を特徴付け、責任を分担する
--範囲別
クラス: クラスとサブクラス間の関連を扱う -> 静的
オブジェクト: オブジェクト間の関連を扱う -> 動的
-本書で説明するパターンの動作
--生成
クラス: オブジェクトの生成の一部をサブクラスに委ねる
オブジェクト: オブジェクトの生成の一部をオブジェクトに委ねる
--構造
クラス: 継承を用いてクラスを構成する
オブジェクト: オブジェクトをまとめる方法を記述する
--振る舞い
クラス: 継承を用いてアルゴリズムや制御のながれを記述する
オブジェクト: オブジェクトのグループがどのように協調するかを記述する
-> 複数のオブジェクトを利用しタスクを推敲するため
----
-パターン
--開発する際の経験を明確に表すもの
パターン名:問題・解法・結果を一語で表した名称
問題: 対象としている問題
解法: 解法手順。ただし具体的な実装は記述せず、抽象的な記述にする
結果: 容量・時間に関して。柔軟性、拡張性、移植性に関わる
-MVC(Model View Controller)
--ユーザインターフェースを構築するのに必要な概念
Model: アプリケーションオブジェクト
View: 画面の表現
Controller: ユーザ入力に対するユーザインターフェースの働き
--例
---Modelは複数のViewを持てる(Observer)
---Viewは複合化できる(Composite)
---Controllerは応用メカニズムをカプセル化する(Strategy)
---Factory Method, Decorator他
-デザインパターンの記述方法
--図形
---重要・有用だが、決定事項・代替案・トレードオフが記録できないので不十分
--テンプレート
---情報の均質性、比較有用性、利用性アップ。
---例) 本書のテンプレート
パターン名と分類: 1.5節の表参照
目的: 原理、意図、対象の問題
別名: よく知られた別名
動機: パターン内の構造が問題をどのように解くかを記述するシナリオ。抽象的な記述を理解するため。
適用可能性: 適用状況。他人の認識を予見する。
構造: OMT(Object Modeling Technique)に基づく手法を用いて図形的に表現したもの
構成要素: パターン内のクラス・オブジェクトとその責任分担
協調関係: 各構成要素の協調方法
結果: 目的に対するパターンの解決結果。トレードオフ。可変部分の詳細
実装: 実装する際の注意点、ヒント、技法、言語に依存した問題
サンプルコード: 実装方法
使用例: システムで利用されているパターンの例
関連するパターン: 密接に関連したデザインパターン、違い
**メモ [#qd884c29]
-オブジェクトインスペクタ
-サブクラスのインスタンス
ページ名: