オブジェクト指向と設計の話

2013/07/06 ゆるかわPHPの会#2 の発表資料です。
オブジェクト指向とアジャイル設計などについて。
内容は書籍「アジャイルソフトウェア開発の奥義」と「オブジェクト指向のこころ」に書かれている話が中心となっています。

Transcript

1. オブジェクト指向と アジャイルソフトウェア開発と 5つの原則
2. 自己紹介 @tdakak PHP, Ruby, FreeBSD とか好きです。 無職生活4ヶ月目突入。 これ終わったら BEAR.Sunday で遊ぶ仕事に 戻りつつ、就職活動始めます。 （宣言して自分を追いつめるメソッド）
3. 今日話したいこと
4. 今日話したいこと オブジェクト指向パラダイム（概念）と オブジェクト指向っぽい設計について。 オブジェクト指向っぽいという流れで アジャイルソフトウェア開発的な話とか。
5. 今日話したいこと 今更？
6. 今日話したいこと ちょっと脱線して自分の経歴。 学生時代は COBOL, C をメインに Java を少し。 趣味で VB, VC++6.0 や Perl。 社会人になってからは PHP 4.x や 5.1.x, Java など。 前職で Ruby + アジャイルな開発を経験。 現在に至る。
7. 今日話したいこと PHP5 ではじめてオブジェクト指向を意識する。 試行錯誤しながら設計する日々を過ごし、 なんとかそれっぽい設計ができるようになり、 その後業務で Ruby を使うことになる。 が、思うようなコードが書けない…！
8. 今日話したいこと 書けない原因として考えられること ・ 言語の仕様を理解していない ・ オブジェクト指向を理解していない ・ 何か本質的なところを理解していない ・ そもそもプログラマに向いていない
9. 今日話したいこと 自分の持っている知識を見直してみるために、 オブジェクト指向パラダイムと アジャイルソフトウェア開発について 改めて勉強してみた。
10. なぜオブジェクト指向なのか？
11. なぜオブジェクト指向なのか 従来の構造化プログラミングの限界 ・ 各処理の結合度が高くなる 　 ・ 一連の流れを読まなくちゃいけない 　 ・ 変更の影響範囲が大きくなりがち ・ メモリ要領や処理速度の向上 　 ・ 多少の負荷より可読性や 　　 保守のしやすさを優先できる
12. なぜオブジェクト指向なのか オブジェクト指向プログラミングへの移行 ・ 機能ごとに分割 ・ 再利用しやすくなる ・ ユニットテストしやすくなる …… とか？ 　 （※ゆるいイメージです）　
13. なぜオブジェクト指向なのか 構造化プログラミングが問題を抱えているのは 何となくわかるけども、 なぜオブジェクト指向なのか？
14. そもそもオブジェクトって何？
15. オブジェクトって？ そもそも自分が考える「オブジェクト」の イメージや定義は正しいのか？ というところから疑ってみる。
16. オブジェクトって？ 　// PHP で書くとこんな感じになるはず 　class Hoge { 　　function piyo() { 　　　… 　　} 　} 　$obj = new Hoge();
17. オブジェクトって？ 「たのしいRuby」より ・ プログラムの処理の対象を「データ」ではなく 　 「オブジェクト」として考える ・ データ構造を組み合わせて複雑な情報を表現 ・ データをプログラム上で表現することで 　 いろいろな操作が可能になる
18. オブジェクトって？ わかるような、 わからないような…？ (´・ω・｀)
19. 3つの観点
20. 3つの観点 マーティン・ファウラーは ソフトウェア開発プロセスにおける3つの観点と して次のようなものを挙げている。 1. 概念 (conceptual) 2. 仕様 (specification) 3. 実装 (implementation)
21. 3つの観点 抽象度が高い＝具体的なものではない 具体的なものって？ ・ ソースコード ・ データ ・ 演算処理
22. 3つの観点 1. 概念 (conceptual) ・ 実装（ソースコード）とは切り離されたもの ・ 責任 ・ 「私が何に対して責任があるのか？」
23. 3つの観点 2. 仕様（specification） ・ ソフトウェアのインタフェース ・ 振る舞い ・ 「私はどのように使用されるのか？」
24. 3つの観点 3. 実装（implementation） ・ 具体的な処理 ・ ソースコード、データ、演算処理 ・ 「私はどのようにして 　　自身の責任を全うするのか？」
25. 3つの観点 呼び出す側からオブジェクトを見ると… ・ 各機能の責任を負っているオブジェクトたちの 　 「実装」は問題ではない ・ オブジェクトが何を表すのか ・ オブジェクトがどのような 　 振る舞いを持つのか
26. 3つの観点 実装レベルからオブジェクトを見ると… ・ 操作（メソッド）を伴ったデータ ・ 操作（メソッド）とデータの集合
27. 3つの観点 オブジェクトとは… ・ 「データ」と「振る舞い」の集合 ・ 「責任」を持ったもの
28. 3つの観点 クラス設計時に、オブジェクト自身の 「責任」や「振る舞い」を はっきりと意識しているか？ 自分は感覚に頼ってる部分が多い気がする… 何か危険なにおいがする…
29. 腐敗するソフトウェア
30. 腐敗するソフトウェア ソフトウェアはなぜ腐ってしまうのか… ・ 開発者の力不足 (´・ω・｀) ・ 要件定義が曖昧 ・ 納期に追われた結果 ・ 繰り返される仕様変更
31. 腐敗するソフトウェアの兆候
32. 腐敗するソフトウェアの兆候 　1. 硬さ 　2. 脆さ 　3. 移植性のなさ 　4. 扱いにくさ 　5. 不必要な複雑さ 　6. 不必要な繰り返し 　7. 不透明さ
33. 腐敗するソフトウェアの兆候 1. 硬さ ・ 変更しにくいシステム ・ 1つの変更が他の部分にまで影響する
34. 腐敗するソフトウェアの兆候 2. 脆さ ・ 1つの変更によって概念的に関係のない部分 　 まで壊れてしまう
35. 腐敗するソフトウェアの兆候 3. 移植性のなさ ・ 他のシステムでの再利用が難しい
36. 腐敗するソフトウェアの兆候 4. 扱いにくさ ・ 正しい設計をするのが困難なソフトウェア ・ 正しいことより誤ったことをしやすい ・ 裏技、バッドノウハウ ・ 面倒な開発環境
37. 腐敗するソフトウェアの兆候 5. 不必要な複雑さ ・ 本質的な意味を持たない構造を内包 ・ 先行実装したコード ・ 複雑さを増やす魔法の呪文 　 "後で必要になるかもしれない"
38. 腐敗するソフトウェアの兆候 6. 不必要な繰り返し ・ コピペ ・ コピペ ・ コピペ
39. 腐敗するソフトウェアの兆候 7. 不透明さ ・ 目的や意図がわかりにくい ・ 読みにくい
40. 腐らせないためにどうするか？
41. 腐らせないために 「原則」「パターン」「プラクティス」を 継続的に適用することで、 読みやすく変更に強い状態を保つ。 ↓ これがアジャイルな設計！
42. 腐らせないために 具体的にどうしたらいい？ ・ 設計の方針を決めて従う ・ オブジェクト指向プログラミング ・ アジャイルや XP などのプラクティス適用 ・ 原則
43. 5つの原則
44. 1. 単一責任の原則
45. 単一責任の原則 単一責任の原則 SRP : Single Responsibility Principle クラスを変更する理由は 1つ以上存在してはならない。
46. 単一責任の原則 変更理由＝役割（責任） 基本的に、1つのクラスに割り当てられる役割は 1つになるようにする。
47. 2. オープン・クローズドの原則
48. オープン・クローズドの原則 オープン・クローズドの原則 OCP : Open-Closed Principle ・ 拡張に対して開いていなければならない。 ・ 修正に対して閉じていなければならない。
49. 3. リスコフの置換原則
50. リスコフの置換原則 リスコフの置換原則 LSP : Liskov Substitution Principle 派生型はその基本型と 置換可能でなければならない。
51. リスコフの置換原則 ？？？？？
52. リスコフの置換原則 ここで望まれるのは、次の述べるような置換可能な性質 である：S型のオブジェクトo1の各々に、対応するT型 のオブジェクトo2が1つ存在し、Tを使って定義されたプ ログラムPに対してo2の代わりにo1を使ってもPの振る 舞いが変わらない場合、SはTの派生型であると言える。
53. リスコフの置換原則 ？？？？？？？？？？？？？
54. リスコフの置換原則 ・ 赤いもの 　 ・ T型のオブジェクトo2 ・ ねこ 　 ・ S型のオブジェクトo1 　 ・ o2を持つ ・ とり 　 ・ プログラムP 　 ・ T型のオブジェクトを使う
55. リスコフの置換原則 とりに対して赤いものの代わりにねこを使っても とりの振る舞いが変わらない場合、 SはTの派生型と言える。
56. リスコフの置換原則 プログラム P に o2（T型のオブジェクト） または o1（o2 を保持するS型のオブジェクト） のどちらを渡しても P の挙動が変わらない、 この状態は「 LSP に従っている」と言える。 LSP に違反すると OCP にも違反してしまう。
57. 4. 依存性逆転の原則
58. 依存性逆転の原則 依存性逆転の原則 DIP : Dependency Inversion Principle ・ 上位のモジュールは下位のモジュールに依存しては 　 ならない。どちらも「抽象」に依存すべきである。 ・ 「抽象」は実装の詳細に依存してはならない。 　 実装の詳細が「抽象」に依存すべきである。
59. 依存性逆転の原則 ここでいう上位モジュールとは ・ アプリケーションの方針に基づく重要な判断 ・ ビジネスモデル ・ アプリケーションの存在理由を決定づける 下位モジュールとは ・ 上位モジュールの実装の詳細を担当
60. 依存性逆転の原則 上位モジュールが下位モジュールに依存している 場合、問題を抱えてしまう。 ・ 下位モジュールの変更が 　 上位モジュールに影響を与えてしまう ・ 上位モジュールの再利用が難しい 　 （依存関係にある下位モジュールを切り離せない）
61. 依存性逆転の原則 下位モジュールが宣言したインタフェースに 上位モジュールが従う形は、 インタフェースの所有権が 下位モジュールにある 状態だといえる。
62. 依存性逆転の原則 逆に上位モジュールがインタフェースを宣言し、 下位モジュールはそれに従う形にすることで、 インタフェースの所有権を 上位モジュールに 持たせることができる。
63. 5. インタフェース分離の原則
64. インタフェース分離の原則 インタフェース分離の原則 ISP : Interface Segregation Principle クライアントに対し、クライアントが利用しない メソッドへの依存を強制してはならない。
65. まとめ
66. まとめ この辺のことを知っておくと何がいいの？ ・ オブジェクト指向のこと ・ アジャイル的な何か
67. まとめ オブジェクト指向パラダイムへの理解 ・ Web + 軽量プログラミング言語界隈では 　 大事な考え方（少なくとも今のところは） ・ 何となくでも理解することで、読み書き 　できる内容が変わってくると思う。 ・ FW やライブラリの設計を理解する手助け。
68. まとめ アジャイルの思想とか アジャイルや XP は先人の知恵。 取り入れられそうなところをやってみる。 パターン、プラクティス、原則 などなど。 ただしむやみやたらに導入、適用しないことも大切。
69. 参考書籍
70. 参考書籍 アジャイルソフトウェア開発の奥義 　　　　　　　　　　　　　　　　　著者はロバート・C・マーチン、 　　　　　　　　　　　　　　　　　通称ボブおじさん。 　　　　　　　　　　　　　　　　　オブジェクト指向による設計と 　　　　　　　　　　　　　　　　　アジャイルの思想についてがっつり。 　　　　　　　　　　　　　　　　　700ページ超のボリューム（凶器）
71. 参考書籍 オブジェクト指向のこころ 　　　　　　　　　　　　　　　　　オブジェクト指向を題する本の中で 　　　　　　　　　　　　　　　　　評価がよさそうだったので購入。 　　　　　　　　　　　　　　　　　「オブジェクトとは何か」という定義 　　　　　　　　　　　　　　　　　から UML の説明、具体的な実装を例 　　　　　　　　　　　　　　　　　にいくつかのデザインパターンが紹介 　　　　　　　　　　　　　　　　　されている。
72. 参考書籍 各原則については「アジャイルソフトウェア開発 の奥義」から引用しています。 「オブジェクト指向のこころ」は ”実装レベルで は理解できているけど本質的なところは曖昧でふ わふわしてる” っていう人におすすめです。
73. 参考書籍 定番のこちらもおすすめ アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣 アジャイルサムライ 達人開発者への道
74. ありがとうございました。