Tweet
Tweet

Slide 1

Slide 1 text

オブジェクト指向と アジャイルソフトウェア開発と 5つの原則

Slide 2

Slide 2 text

自己紹介 @tdakak PHP, Ruby, FreeBSD とか好きです。 無職生活4ヶ月目突入。 これ終わったら BEAR.Sunday で遊ぶ仕事に 戻りつつ、就職活動始めます。 （宣言して自分を追いつめるメソッド）

Slide 3

Slide 3 text

今日話したいこと

Slide 4

Slide 4 text

今日話したいこと オブジェクト指向パラダイム（概念）と オブジェクト指向っぽい設計について。 オブジェクト指向っぽいという流れで アジャイルソフトウェア開発的な話とか。

Slide 5

Slide 5 text

今日話したいこと 今更？

Slide 6

Slide 6 text

今日話したいこと ちょっと脱線して自分の経歴。 学生時代は COBOL, C をメインに Java を少し。 趣味で VB, VC++6.0 や Perl。 社会人になってからは PHP 4.x や 5.1.x, Java など。 前職で Ruby + アジャイルな開発を経験。 現在に至る。

Slide 7

Slide 7 text

今日話したいこと PHP5 ではじめてオブジェクト指向を意識する。 試行錯誤しながら設計する日々を過ごし、 なんとかそれっぽい設計ができるようになり、 その後業務で Ruby を使うことになる。 が、思うようなコードが書けない…！

Slide 8

Slide 8 text

今日話したいこと 書けない原因として考えられること ・ 言語の仕様を理解していない ・ オブジェクト指向を理解していない ・ 何か本質的なところを理解していない ・ そもそもプログラマに向いていない

Slide 9

Slide 9 text

今日話したいこと 自分の持っている知識を見直してみるために、 オブジェクト指向パラダイムと アジャイルソフトウェア開発について 改めて勉強してみた。

Slide 10

Slide 10 text

なぜオブジェクト指向なのか？

Slide 11

Slide 11 text

なぜオブジェクト指向なのか 従来の構造化プログラミングの限界 ・ 各処理の結合度が高くなる 　 ・ 一連の流れを読まなくちゃいけない 　 ・ 変更の影響範囲が大きくなりがち ・ メモリ要領や処理速度の向上 　 ・ 多少の負荷より可読性や 　　 保守のしやすさを優先できる

Slide 12

Slide 12 text

なぜオブジェクト指向なのか オブジェクト指向プログラミングへの移行 ・ 機能ごとに分割 ・ 再利用しやすくなる ・ ユニットテストしやすくなる …… とか？ 　 （※ゆるいイメージです）　

Slide 13

Slide 13 text

なぜオブジェクト指向なのか 構造化プログラミングが問題を抱えているのは 何となくわかるけども、 なぜオブジェクト指向なのか？

Slide 14

Slide 14 text

そもそもオブジェクトって何？

Slide 15

Slide 15 text

オブジェクトって？ そもそも自分が考える「オブジェクト」の イメージや定義は正しいのか？ というところから疑ってみる。

Slide 16

Slide 16 text

オブジェクトって？ 　// PHP で書くとこんな感じになるはず 　class Hoge { 　　function piyo() { 　　　… 　　} 　} 　$obj = new Hoge();

Slide 17

Slide 17 text

オブジェクトって？ 「たのしいRuby」より ・ プログラムの処理の対象を「データ」ではなく 　 「オブジェクト」として考える ・ データ構造を組み合わせて複雑な情報を表現 ・ データをプログラム上で表現することで 　 いろいろな操作が可能になる

Slide 18

Slide 18 text

オブジェクトって？ わかるような、 わからないような…？ (´・ω・｀)

Slide 19

Slide 19 text

3つの観点

Slide 20

Slide 20 text

3つの観点 マーティン・ファウラーは ソフトウェア開発プロセスにおける3つの観点と して次のようなものを挙げている。 1. 概念 (conceptual) 2. 仕様 (specification) 3. 実装 (implementation)

Slide 21

Slide 21 text

3つの観点 抽象度が高い＝具体的なものではない 具体的なものって？ ・ ソースコード ・ データ ・ 演算処理

Slide 22

Slide 22 text

3つの観点 1. 概念 (conceptual) ・ 実装（ソースコード）とは切り離されたもの ・ 責任 ・ 「私が何に対して責任があるのか？」

Slide 23

Slide 23 text

3つの観点 2. 仕様（specification） ・ ソフトウェアのインタフェース ・ 振る舞い ・ 「私はどのように使用されるのか？」

Slide 24

Slide 24 text

3つの観点 3. 実装（implementation） ・ 具体的な処理 ・ ソースコード、データ、演算処理 ・ 「私はどのようにして 　　自身の責任を全うするのか？」

Slide 25

Slide 25 text

3つの観点 呼び出す側からオブジェクトを見ると… ・ 各機能の責任を負っているオブジェクトたちの 　 「実装」は問題ではない ・ オブジェクトが何を表すのか ・ オブジェクトがどのような 　 振る舞いを持つのか

Slide 26

Slide 26 text

3つの観点 実装レベルからオブジェクトを見ると… ・ 操作（メソッド）を伴ったデータ ・ 操作（メソッド）とデータの集合

Slide 27

Slide 27 text

3つの観点 オブジェクトとは… ・ 「データ」と「振る舞い」の集合 ・ 「責任」を持ったもの

Slide 28

Slide 28 text

3つの観点 クラス設計時に、オブジェクト自身の 「責任」や「振る舞い」を はっきりと意識しているか？ 自分は感覚に頼ってる部分が多い気がする… 何か危険なにおいがする…

Slide 29

Slide 29 text

腐敗するソフトウェア

Slide 30

Slide 30 text

腐敗するソフトウェア ソフトウェアはなぜ腐ってしまうのか… ・ 開発者の力不足 (´・ω・｀) ・ 要件定義が曖昧 ・ 納期に追われた結果 ・ 繰り返される仕様変更

Slide 31

Slide 31 text

腐敗するソフトウェアの兆候

Slide 32

Slide 32 text

腐敗するソフトウェアの兆候 　1. 硬さ 　2. 脆さ 　3. 移植性のなさ 　4. 扱いにくさ 　5. 不必要な複雑さ 　6. 不必要な繰り返し 　7. 不透明さ

Slide 33

Slide 33 text

腐敗するソフトウェアの兆候 1. 硬さ ・ 変更しにくいシステム ・ 1つの変更が他の部分にまで影響する

Slide 34

Slide 34 text

腐敗するソフトウェアの兆候 2. 脆さ ・ 1つの変更によって概念的に関係のない部分 　 まで壊れてしまう

Slide 35

Slide 35 text

腐敗するソフトウェアの兆候 3. 移植性のなさ ・ 他のシステムでの再利用が難しい

Slide 36

Slide 36 text

腐敗するソフトウェアの兆候 4. 扱いにくさ ・ 正しい設計をするのが困難なソフトウェア ・ 正しいことより誤ったことをしやすい ・ 裏技、バッドノウハウ ・ 面倒な開発環境

Slide 37

Slide 37 text

腐敗するソフトウェアの兆候 5. 不必要な複雑さ ・ 本質的な意味を持たない構造を内包 ・ 先行実装したコード ・ 複雑さを増やす魔法の呪文 　 "後で必要になるかもしれない"

Slide 38

Slide 38 text

腐敗するソフトウェアの兆候 6. 不必要な繰り返し ・ コピペ ・ コピペ ・ コピペ

Slide 39

Slide 39 text

腐敗するソフトウェアの兆候 7. 不透明さ ・ 目的や意図がわかりにくい ・ 読みにくい

Slide 40

Slide 40 text

腐らせないためにどうするか？

Slide 41

Slide 41 text

腐らせないために 「原則」「パターン」「プラクティス」を 継続的に適用することで、 読みやすく変更に強い状態を保つ。 ↓ これがアジャイルな設計！

Slide 42

Slide 42 text

腐らせないために 具体的にどうしたらいい？ ・ 設計の方針を決めて従う ・ オブジェクト指向プログラミング ・ アジャイルや XP などのプラクティス適用 ・ 原則

Slide 43

Slide 43 text

5つの原則

Slide 44

Slide 44 text

1. 単一責任の原則

Slide 45

Slide 45 text

単一責任の原則 単一責任の原則 SRP : Single Responsibility Principle クラスを変更する理由は 1つ以上存在してはならない。

Slide 46

Slide 46 text

単一責任の原則 変更理由＝役割（責任） 基本的に、1つのクラスに割り当てられる役割は 1つになるようにする。

Slide 47

Slide 47 text

2. オープン・クローズドの原則

Slide 48

Slide 48 text

オープン・クローズドの原則 オープン・クローズドの原則 OCP : Open-Closed Principle ・ 拡張に対して開いていなければならない。 ・ 修正に対して閉じていなければならない。

Slide 49

Slide 49 text

3. リスコフの置換原則

Slide 50

Slide 50 text

リスコフの置換原則 リスコフの置換原則 LSP : Liskov Substitution Principle 派生型はその基本型と 置換可能でなければならない。

Slide 51

Slide 51 text

リスコフの置換原則 ？？？？？

Slide 52

Slide 52 text

リスコフの置換原則 ここで望まれるのは、次の述べるような置換可能な性質 である：S型のオブジェクトo1の各々に、対応するT型 のオブジェクトo2が1つ存在し、Tを使って定義されたプ ログラムPに対してo2の代わりにo1を使ってもPの振る 舞いが変わらない場合、SはTの派生型であると言える。

Slide 53

Slide 53 text

リスコフの置換原則 ？？？？？？？？？？？？？

Slide 54

Slide 54 text

リスコフの置換原則 ・ 赤いもの 　 ・ T型のオブジェクトo2 ・ ねこ 　 ・ S型のオブジェクトo1 　 ・ o2を持つ ・ とり 　 ・ プログラムP 　 ・ T型のオブジェクトを使う

Slide 55

Slide 55 text

リスコフの置換原則 とりに対して赤いものの代わりにねこを使っても とりの振る舞いが変わらない場合、 SはTの派生型と言える。

Slide 56

Slide 56 text

リスコフの置換原則 プログラム P に o2（T型のオブジェクト） または o1（o2 を保持するS型のオブジェクト） のどちらを渡しても P の挙動が変わらない、 この状態は「 LSP に従っている」と言える。 LSP に違反すると OCP にも違反してしまう。

Slide 57

Slide 57 text

4. 依存性逆転の原則

Slide 58

Slide 58 text

依存性逆転の原則 依存性逆転の原則 DIP : Dependency Inversion Principle ・ 上位のモジュールは下位のモジュールに依存しては 　 ならない。どちらも「抽象」に依存すべきである。 ・ 「抽象」は実装の詳細に依存してはならない。 　 実装の詳細が「抽象」に依存すべきである。

Slide 59

Slide 59 text

依存性逆転の原則 ここでいう上位モジュールとは ・ アプリケーションの方針に基づく重要な判断 ・ ビジネスモデル ・ アプリケーションの存在理由を決定づける 下位モジュールとは ・ 上位モジュールの実装の詳細を担当

Slide 60

Slide 60 text

依存性逆転の原則 上位モジュールが下位モジュールに依存している 場合、問題を抱えてしまう。 ・ 下位モジュールの変更が 　 上位モジュールに影響を与えてしまう ・ 上位モジュールの再利用が難しい 　 （依存関係にある下位モジュールを切り離せない）

Slide 61

Slide 61 text

依存性逆転の原則 下位モジュールが宣言したインタフェースに 上位モジュールが従う形は、 インタフェースの所有権が 下位モジュールにある 状態だといえる。

Slide 62

Slide 62 text

依存性逆転の原則 逆に上位モジュールがインタフェースを宣言し、 下位モジュールはそれに従う形にすることで、 インタフェースの所有権を 上位モジュールに 持たせることができる。

Slide 63

Slide 63 text

5. インタフェース分離の原則

Slide 64

Slide 64 text

インタフェース分離の原則 インタフェース分離の原則 ISP : Interface Segregation Principle クライアントに対し、クライアントが利用しない メソッドへの依存を強制してはならない。

Slide 65

Slide 65 text

まとめ

Slide 66

Slide 66 text

まとめ この辺のことを知っておくと何がいいの？ ・ オブジェクト指向のこと ・ アジャイル的な何か

Slide 67

Slide 67 text

まとめ オブジェクト指向パラダイムへの理解 ・ Web + 軽量プログラミング言語界隈では 　 大事な考え方（少なくとも今のところは） ・ 何となくでも理解することで、読み書き 　できる内容が変わってくると思う。 ・ FW やライブラリの設計を理解する手助け。

Slide 68

Slide 68 text

まとめ アジャイルの思想とか アジャイルや XP は先人の知恵。 取り入れられそうなところをやってみる。 パターン、プラクティス、原則 などなど。 ただしむやみやたらに導入、適用しないことも大切。

Slide 69

Slide 69 text

参考書籍

Slide 70

Slide 70 text

参考書籍 アジャイルソフトウェア開発の奥義 　　　　　　　　　　　　　　　　　著者はロバート・C・マーチン、 　　　　　　　　　　　　　　　　　通称ボブおじさん。 　　　　　　　　　　　　　　　　　オブジェクト指向による設計と 　　　　　　　　　　　　　　　　　アジャイルの思想についてがっつり。 　　　　　　　　　　　　　　　　　700ページ超のボリューム（凶器）

Slide 71

Slide 71 text

参考書籍 オブジェクト指向のこころ 　　　　　　　　　　　　　　　　　オブジェクト指向を題する本の中で 　　　　　　　　　　　　　　　　　評価がよさそうだったので購入。 　　　　　　　　　　　　　　　　　「オブジェクトとは何か」という定義 　　　　　　　　　　　　　　　　　から UML の説明、具体的な実装を例 　　　　　　　　　　　　　　　　　にいくつかのデザインパターンが紹介 　　　　　　　　　　　　　　　　　されている。

Slide 72

Slide 72 text

参考書籍 各原則については「アジャイルソフトウェア開発 の奥義」から引用しています。 「オブジェクト指向のこころ」は ”実装レベルで は理解できているけど本質的なところは曖昧でふ わふわしてる” っていう人におすすめです。

Slide 73

Slide 73 text

参考書籍 定番のこちらもおすすめ アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣 アジャイルサムライ 達人開発者への道

Slide 74

Slide 74 text

ありがとうございました。