『オブジェクト指向設計実践ガイド』を読もう（2016/12/16 社内勉強会）

『オブジェクト指向設計実践ガイド 〜Rubyでわかる進化しつづける柔軟なアプリケーションの育て方』を読んで「みんな読めばいいのに！」という強い思いを発表しました。

Transcript

1. An Agile Primer Practical Object-Oriented Design in Ruby Yoko TAMADA @tmd45 2016-12-16 feedforce Inc. 日本語版
2. Practical Object-Oriented Design in Ruby http://www.poodr.com/ An Agile Primer a.k.a. "POODR"
3. オブジェクト指向設計 実践ガイド Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方 http://gihyo.jp/book/2016/978-4-7741-8361-9
4. 結論: 日本語版でいいので 読みましょう!!! Must read it!
5. Resume ❖ What "POODR" help you? ❖ What's practical design? ❖ What I learned from this book.
6. What "POODR" help you?
7. POODR will help you from www.poodr.com ❖ Decide what belongs in a single class ❖ Avoid entangling objects that should be kept separate ❖ Define flexible interfaces among objects ❖ Reduce programming overhead costs with duck typing ❖ Successfully apply inheritance ❖ Build objects via composition ❖ Design cost-effective tests ❖ Craft simple, straightforward, understandable code
8. POODR will help you from www.poodr.com ❖ １つのクラスに属するものを決める ❖ 分けられているべきオブジェクトがもつれないようにする ❖ オブジェクト間の柔軟な「インターフェース」を定義する ❖ 「ダックタイピング」でコーディングのオーバーヘッドコストを削減 ❖ 「継承」を正しく適用する ❖ 「コンポジション」を使ってオブジェクトを生成する ❖ 費用対効果の高いテストの設計 ❖ シンプルで、わかりやすく、理解できるコードを作成する
9. ❖ 変化は常に訪れるもの ❖ 変化は避けられないもの ❖ 変化で起こる「何か」は分からない 変更が容易なコードなら書くのが楽しい！☺ What for? なんのために必要なの？ - 第1章 オブジェクト指向設計
10. What's practical design?
11. What's practical design? 実用的な設計とは ❖ 未来を考慮するとは、特定の未来を想定して実装しておくことではない ❖ 未来を選択してしまうのではなく、動くための余地を残す ❖ 未来を受け入れるための選択肢を保護する 推測し、選択してしまうのではなく、 予測できない変化を受け入れるための選択肢を守る - 第1章 オブジェクト指向設計
12. What's practical design? 実用的な設計とは 設計の目的は「あとにでも」設計をできるようにすること その第一の目標は、変更コストの削減。 - 第1章 オブジェクト指向設計 Agile!
13. ❖ アプリケーションを「部品」で構成する ❖ 部品は相互に作用し合い、全体の振る舞いが生まれる ❖ 部品とは「オブジェクト」 ❖ 相互作用はオブジェクト間で受け渡される「メッセージ」 ❖ メッセージの送り手は、受け手のことを知っている必要がある ➢ 知っている＝２つのオブジェクトの「依存関係」となる ➢ 依存関係は変更を邪魔する オブジェクト指向設計とは「依存関係を管理すること」 Object-Oriented design? オブジェクト指向設計とは - 第1章 オブジェクト指向設計
14. What I learned from this book.
15. ❖ アジャイル開発のよくわからなかった部分がわかった ➢ 顧客と共同作業をし、ソフトウェアは一度に小さな単位でつくり、そのときそれぞれの単位が次のア イディアを得る機会となることを目指す ➢ 真実１：前もってつくる全体の詳細設計（ Big Design Up Front）にはまったく何の意味もない ➢ 真実２：アプリケーションの完成時期は誰にも予測できない ➢ この事実により "顧客とプログラマは必然的に敵対する " が、アジャイルを有効にするにはソフト ウェアがかたちになる「前」に確かさを手に入れることはできないと認めること 全体の詳細設計（BDUF）ではなく 変化を受け入れるための「設計」はむしろ必要とされるものである With Agile development アジャイル開発
16. ❖ 親子関係だけでは理解できなかった「実践的な」オブジェクト指向設計 ➢ とくに実際の改善例が Ruby で書かれていて、Ruby ならこうすると上手くいくというのが分かりやす い。そこから Ruby に限らずにオブジェクト指向設計を学べる ❖ オブジェクトの「インターフェース」を考えることに集中したら「公開しない部分」の実 装に迷いが減った ❖ クラスに含まれている何かを別のオブジェクトとして捉らえて切り分ける考え方が以 前よりスムーズにできるようになった ❖ とにかく大切なのは「変更を受け入れられるように」作ること ➢ 疎結合とか単一責任とかはすべてそのために存在するということ With Object-Oriented Design オブジェクト指向設計
17. ❖ 最初から順に読んでいくとスッと入ってくる良書！ ➢ 導入・文化（アジャイル開発との関連）・概要 ▪ 第１章 オブジェクト指向設計 ➢ パターンと実装 ▪ 第２章 単一責任のクラスを設計する ▪ 第３章 依存関係を管理する ▪ 第４章 柔軟なインターフェースをつくる ▪ 第５章 ダックタイピングでコストを削減する ▪ 第６章 継承によって振る舞いを獲得する ▪ 第７章 モジュールでロールの振る舞いを共有する ▪ 第８章 コンポジションでオブジェクトを組み合わせる ▪ 第９章 費用対効果の高いテストを設計する How to read 本書の読み方 関係の選択(p.233)
18. オブジェクト指向設計 実践ガイド Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方 http://gihyo.jp/book/2016/978-4-7741-8361-9
19. ❖ １つのクラスに属するものを決める ❖ 分けられているべきオブジェクトがもつれないようにする ❖ オブジェクト間の柔軟な「インターフェース」を定義する ❖ 「ダックタイピング」でコーディングのオーバーヘッドコストを削減 ❖ 「継承」を正しく適用する ❖ 「コンポジション」を使ってオブジェクトを生成する ❖ 費用対効果の高いテストの設計 ❖ シンプルで、わかりやすく、理解できるコードを作成する 終 ────── ⓣⓜⓓ POODR will help you from www.poodr.com