はこだてIKA IT技術促進WG主催 第2回 モデリング勉強会で使用したスライドです。

1. 第2回 モデリング勉強会
2013/02/14
株式会社アットウェア 高橋 哲也

2. 前回のおさらい
• どうしてオブジェクト指向が必要か。
• モデリングって？
• CRCカードの書き方
クラス名
役割・責務
そのクラスが 関連・相互作用クラス
・知っていること
・行うこと

3. オブジェクト指向設計五大原則
• 優れたオブジェクト指向開発のための指針。
• あくまで原則。
• 必ず守らなければならないものではないが
まずそれで考えることが重要。
• 正当な理由やトレードオフが
説明できれば破っても良い。
• が、無視してはダメだ。

4. 【単一責任の原則】
(Single Responsibility Principle)
• 『クラスを変更する理由は
1つ以上存在してはならない。 』
• 変更理由が2つあるということは
責任（役割）も2つあるということ。
• そんな便利そうなクラスは許さん！
という原則。
※ 「変更する理由」ってのがポイント

5. 【オープン・クローズドの原則】
(the Open-Closed Principle )
• 『ソフトウェアの構成要素は
拡張に対して開いていて
修正に対して閉じていなければならない。』
• オープンとは？
→ モジュールの振る舞いを拡張できる。
• クローズとは？
→ モジュールの振る舞いを変更しても
そのソースやバイナリは影響を受けない。
• 抽象的な原則のくせに一番大事。
オブジェクト指向設計の核心です。

6. 【リスコフの置換原則】
(the Liskov Substitution Principle)
• 『派生型はその基本型と
置換可能でなければならない。』
• 使う側から言うと、基本型を引数にとる関数に、ど
んな派生型のインスタンスをもらっても気にしない
で使えないとダメ。
• 実装側から言うと、派生クラスがその基本クラスで
使われるところにおいても、正常に動作することを
保証しないとダメ。

7. 【依存関係逆転の原則】
(the Dependency Inversion Principle)
• 『上位のモジュールは下位のモジュールに
依存してはならない。
どちらのモジュールも「抽象」に
依存すべきである。』
• 『「抽象」は実装の詳細に依存してはならない。
実装の詳細が「抽象」に依存すべきである。』
• 手続き型でよく出てしまう好ましくない構造。
• ここで言う上位・下位は継承のこと
だけを指しているわけではありません。

8. 【インターフェイス分離の原則】
(the Interface Segregation Principle)
• 『クライアントに、クライアントが
利⽤しないメソッドへの依存を
強制してはならない。』
• クライアントは複数のインターフェイスを
利⽤するけど、そのすべてが互いに
強い関連を持っているわけではない。
• すべてのインターフェイスを
１つのクラスに押し込めてしまうことはやめ
関連性持ったインターフェイスは
グループ化して抽象基本クラスとして
分けて利⽤すべき。

9. もっと詳しく知りたい人は
『アジャイルソフトウェア開発の奥義 第2版』
〜オブジェクト指向開発の神髄と匠の技〜
ロバート・C・マーチン、 瀬谷 啓介 著
6,000円くらいするけどね

10. お題
• ドラクエの戦闘画面を
モデリングしましょう。
• パーティは4人、敵はランダム。
• ステータス異常などもアリ。