オブジェクト指向の設計と実装の学び方のコツ
- 1. 学習パターンを実践する オブジェクト指向の設計と実装の 学び方のコツ 2012年9月12日 有限会社 システム設計 増田 masuda@system-sekkei.com Twitter : @masuda220
- 2. オブジェクト指向
- 4. オブジェクト指向の 発想・手法を会得すると 分析・モデリング （上流） 同じアプローチでできる フレームワーク ミドルウェア 言語・ツール 深く理解できる アジャイルな 開発手法 自然に身につく
- 5. どうやって学ぶ？
- 7. 学びのコツ 学びのデザイン 自分で 自分の「学び」を デザインする
- 9. 学びのコツ 創造的な学び 必死に「覚える」学びから 「つくる」・「実践する」 中での学びへ
- 10. 設計の学びの鉄則
- 11. 設計の学びの鉄則 コードを書く 言語のシャワー じゃぶじゃぶとあびていると 不思議と、けっこう身につくものだ 学びのコツ
- 12. 設計の学びの鉄則 考えて コードを書く 自分で考える 「なぜ？」という気持ちを 忘れない 学びのコツ
- 13. 設計の学びの鉄則 人の役に立つ ソフトウェアを書く 「書き上げた（動いた）」は道半ば 自分がわかる（動かす）ために書き 他の人がわかる(使える）ように書き直す 学びのコツ
- 14. 設計の学び 3つの ステージ
- 15. 1st Stage ９つの簡単なコーディングルールで 修行する オブジェクト指向の基本を体に叩き込む 2nd Stage Become a Software Developer 一人前になる ６つの役割ステレオタイプ で設計する Final Stage Become a Thoughtful Software Developer 突き抜ける Become a Leading Software Designer
- 16. 1 st Stage 修行する 基本を体に叩き込む
- 17. オブジェクトの設計と実装の基本 小さくする クラス 50行以内 メソッド 3行以内 パッケージ 10ファイル以内
- 18. 学びのコツ 小さく を身体に叩き込む 身体で覚える 意識しなくても プロトタイピング 自然に 小さく作ってみて 小さく作るようになるまで 初めてわかることがある 繰り返す 「まねぶ」ことから 小さく作る「型(パターン)」を真似る
- 19. 必然的に オブジェクト指向（小さくする） で書くことになる ９つの簡単なルール 「Thought Works アンソロジー」 第5章 オブジェクト指向エクササイズ 原文 http://www.bennadel.com/resources/uploads/2012/ObjectCalisthenics.pdf 外国語の普段づかい
- 21. How 身体への叩き込み方
- 22. 自分で書いた マーチンファウラー 実際のコード リファクタリング 小さく書き換える テクニックを 知る ケントベック 実装パターン 「９つのルール」の ルール違反を 見つけて書き直す 小さく作る 書き方を知る
- 23. 学びのコツ 隠れた関係性から学ぶ 「小さく作る」を合言葉に いろいろつながってくる 「実装パターン」 「リファクタリング」 「９つのルール」 自分の書いたコード
- 24. 1. 実際のコードでルール違反を見つける 2. ルール通りに書き直してみる • とりあえず 1000行 3. 書き直す手掛かり – オブジェクト指向エクササイズ • 説明、サンプルコード、パターン名 – リファクタリング • 第3章 いやな臭い – 実装パターン • ツアーガイド • 各パターンの説明、サンプルコード
- 25. エクササイズとリファクタリング • ルール１ メソッドのインデントは一段階まで – いやな臭い 長すぎるメソッド – 処方箋 メソッドの抽出(110) • ルール３ すべてのプリミティブをラッピング – いやな臭い 基本データ型への執着 – 処方箋 オブジェクトでデータ値を置換(175) • ルール７ クラスは50行以内 – いやな臭い 大きなクラス – 処方箋 クラスの抽出(149) And more … 自分で考える、 学びの共同体をつくる、…
- 26. エクササイズと実装パターン • ルール２ else 句は使わない – ガード条件(87) • ルール４ ファーストクラスコレクション – コレクションの拡張(138) • ルール９ getter/setter は使わない – getterメソッド (118) ケントベックは、どう言っている？ – setter メソッド (120) And more … 自分で考える、 学びの共同体をつくる、…
- 27. 小さく作る パターン集 パターン集 第5章 オブジェクト指向エクササイズ ９つのルール slideshare: オブジェクト指向エクササイズのススメ http://www.slideshare.net/yojik/ss-1033616 オブジェクト指向できていますか？ http://www.slideshare.net/MoriharuOhzu/ss-14083300 原文 http://www.bennadel.com/resources/uploads/2012/ObjectCalisthenics.pdf
- 28. ＜おまけ＞もう一つの練習法 手続型の肥満コードを オブジェクトにトランスフォームする ２つの最強パターン パラメータオブジェクトパターン 実装パターン ( 72 ) リファクタリング ( 295 ) パラメータを一つのオブジェクトにまとめ、関連ロジックをそこに移動 メソッドオブジェクトパターン 実装パターン ( 101 ) 長いメソッドをひとつのオブジェクトに置き換え、カプセル化する リファクタリング ( 135 )
- 30. • オブジェクト指向エクササイズ – 俯瞰的な説明 ４ページ を丁寧に読む – 個々のルールの説明 10ページ • 実装パターン – 俯瞰的な説明 20ページ いくつかパターンを体験した後なんども読みなおす • 1章 はじめに • 3章 プログラミングの理論 • 4章 動機 – 各パターンの説明 120ページ (77パターン)
- 31. 1St Stage まとめ • 目標 – オブジェクト指向の基本「小さく」を体に叩き込む • 行動 – オブジェクト指向エクササイズを実コードで繰返す – 小さく作るパターンを実践して習得する • リファクタリング • 実装パターン 身体で覚える 意識しなくても自然に「小さく作るが」できるようになるまで繰り返す プロトタイピング 小さく作ってみて初めてわかることがある 「まねぶ」ことから 小さく作る「型(パターン)」を真似る
- 32. 2 nd Stage 一人前になる Become a Software Developer
- 35. アンチパターン：大きなオブジェクト 巨大なクラス get get Import文の群れ get インスタンス変数の群れ set set 長いメソッドの群れ set データの入れ物クラス getter/setter だけ 巨大なクラスのメリット(？) 何でも屋なので、役割の設計が不要 一枚岩なので、隣人との協力の設計が不要
- 36. 役割分担して協力するとこんな感じ インタフェース役 小さく（50行以下） 役割が明確な 調整役 オブジェクトが 小数の隣人と協力する 構造保持役 情報保持役 制御役 サービス提供役 サービス提供役 サービス提供役 情報保持役 情報保持役 情報保持役 サービス提供役 インタフェース役 インタフェース役
- 38. 学びのコツ 創造的な学び いまの自分にはない 見方、考え方、発想を 手に入れる 「オブジェクトの役割」という考え方 「隣人との協力」という見方
- 40. ０．準備：基本スキルのチェック １． 基本の言葉を知る その言葉で ２． 「現在」のコードを語り ３． 「あるべき」コードを語り ４． コードで動かして、実感してみる
- 41. ０．準備：基本できてますか？ 小さくする クラス 50行以内 メソッド 3行以内 パッケージ 10ファイル以内 50行以上の クラス 気持ち こう感じ始めたら準備ＯＫ ３行以上の メソッド 悪い １０ファイル以上の パッケージ
- 42. １．基本の設計用語を知る まずはつかる
- 43. 設計の言葉を知る オブジェクトデザイン By ワーフスブラック 拾い読みで良いから 原文も読みたい。 訳語が少し…
- 44. オブジェクトデザイン 基本の言葉 「役割ステレオタイプ」 意図的に 思い切り単純化した オブジェクトの６つの役割
- 45. 役割ステレオタイプ 情報保持役 調整役 Information Coordinator Holder 構造保持役 何でも屋から 制御役 Controller Structurer その道の専門家へ サービス提供役 インタフェース役 Service Provider Interfacer
- 46. オブジェクトデザイン 読み方ガイド for ビギナーズ 1章 設計概念 1.1 1.3 1.2 1.19 章扉 オブジェクト オブジェクトの ロール(役割) まとめ 機械装置 役割ステレオタイプ ５章 コラボレーション(協力） 5.1 5.4 5.4.1 コラボレーション コラボレーション 5.9 章扉 役割ステレオタイプ とは何か を識別する戦略 まとめ がコラボレーション 「リード文」 「リード文」 を暗示する
- 47. 技術書の読み方のコツ 鳥の眼と虫の眼 俯瞰して全体を見る。 詳細に部分を見る。 ２つの視点を行き来する。 小説じゃないだから、 最初から順番に読んで面白いわけがない。 知らないことが書いてあるんだから、 一読で、わかるわけがない。
- 48. 技術書の読み方のコツ 鳥の眼と虫の眼 俯瞰情報 はじめに 例えば、索引の 章の扉 節のリード文 ロールステレオタイプ １６の参照先 章のまとめ コラボレーション ２８の参照先 目次 索引 概要説明、詳細説明、関連用語を行ったり来たりする。 ここを上手く使う
- 50. 学びのコツ 「はなす」ことでわかる その内容を完全にわかっていない段階でも その言葉を使って話してみる。 そうすると、自分が何が理解できていないか把握できる。 話し方を工夫することで、理解が進む。 一種のプロトタイピング。インクリメンタルな開発。
- 51. 2. 「現在」のコードを語る このオブジェクトの役割は？ ６つの役割ステレオタイプで語ってみる
- 52. うーん。何でも屋。役割が多すぎ。隣人が多すぎ。 制御役？いや調整役か？ If 文が多く、自分で判断しまくっている。制御役だな。 get/set 使いすぎ？ 構造化役っぽい。 複数のオブジェクトをグループ化してる。 複数のオブジェクトを必要とするロジックが少ないのは？ こいつは情報保持役だな。 隣人が少なく、わりと独立している。 サービス提供役だ。 暗号化ロジックを使って、パスワード生成。 情報保持役も兼ねている？ インタフェース役。 データベースとのデータやりとりが主な役割。 なんか、それ以外のこともごちゃごちゃやっていそうだけど。
- 54. こんな感じ インタフェース役 役割を 少数の隣人 専門特化 調整役 と協力 構造保持役 情報保持役 制御役 サービス提供役 サービス提供役 サービス提供役 情報保持役 情報保持役 情報保持役 サービス提供役 インタフェース役 インタフェース役
- 55. おーなるほど。 最初のインタフェース役からリクエスト受け取った時、 いきなり調整役じゃなく、 制御役が入って、内容判断と分岐が必要なんじゃない？ 最後のサービス提供役とインタフェース役の役割分担が よくわからないなあ。 そうか、コンポジションか。入れ替え可能になっているんだ。 変更に強そうだね。 だとしたら、こっちのサービス提供役も、 具体的なロジックは、さらに下請けのサービス提供役に 委譲したほうが良いんでは？ そうだね。 このオブジェクトのロジック、ぐちゃぐちゃして気持ち悪かったんだ。
- 57. 学びのコツ プロトタイピング 設計用語は コードを書いて、動かして 「はじめて」わかることばかり。 設計用語をひとつ覚えるたびに、 昨日のコードと今日のコードの違いが 自分でわかるようになる。 それが「設計の考え方」「見方」の変化。
- 58. 学びのコツ 成長の発見 昨日の自分のコードと、 今日の自分のコード。 書き方の変化。 なぜ、そう書くか？ の考え方の変化。 設計用語を使いこなし始めた 自分を実感できる。 学びの効果を実感できれば、 さらなる学びへの意欲が湧く。
- 59. 2nd Stage まとめ • 目標 – 一人前になる • オブジェクトへの役割の割り当てスキルの修得 • 協力(コレボレーション)させ方スキルの修得 • 行動 – ６つの役割ステレオタイプを、言葉として覚え – 実際のコードについて、その言葉で語ってみて – コードを書いて動かして実感する • 参考書 – オブジェクトデザイン by ワーフスブラック 創造的な学び 「覚える」学びから、「つくる」・「実践する」なかでの学びへ。 鳥の眼と虫の眼 俯瞰と詳細。２つの視点を行き来する。 成長の発見 昨日の自分と、今日の自分。コードの書き方の違いに敏感になる。
- 60. Final Stage 突き抜ける Become a Thoughtful Software Developer Become a Leading Software Designer
- 61. すべての Thoughtful Software Developer のための名著。 Leading Software Designer たちの、やり方・考え方を 具体的に説明した名著。
- 62. Domain-Driven Design (DDD) ドメイン駆動設計
- 63. ドメイン駆動設計への道 メソッドの構成 For オブジェクト間の特性の移動 データの再編成 Thoughtful Developer 小さくする 条件記述の単純化 Leading Designer エクササイズ メソッド呼び出しの単純化 ９つの簡単なルール オブジェクト 設計スタイル ドメインの理解 役割ステレオタイプ 言葉の力 実装哲学 小数の隣人と協力 モデル駆動 クラス 振る舞いとメソッド 状態とコレクション
- 64. Domain-Driven Design (DDD) ドメイン駆動設計を学ぶ 具体的な 学び方は？
- 65. Domain-Driven Design (DDD) ドメイン駆動設計を学ぶ むずかしい
- 66. Domain-Driven Design (DDD) ドメイン駆動設計をがっつりやってみる 耳よりなはなし 実際に作ることで 突き抜ける
- 67. Domain-Driven Design (DDD) ドメイン駆動設計をやってみる （１）仕事でDDDにどっぷりとつかる •技術者募集中(Java, Spring , Mule ESB) •副業、パートタイム大歓迎 •クラウドベースなので、いつでも、どこからでも、都合の良い時だけ、働くこと可能 •報酬：時給換算で、2000円から1万円 （２）DDD 出張レッスン • 今、自分たちが格闘しているプロジェクト、その実コードで、DDDレッスン • 企業向け 1回３Ｈ、20万円 ×８回 • 個人向け 1回１Ｈ、1万円 （複数名での割り勘あり） × ８回 お問い合わせは、masuda@system-sekkei.com
- 68. オブジェクトの設計と実装の学び方 まとめ
- 69. 設計の学びの鉄則 考えて コードを書く
- 70. オブジェクトの設計と実装の基本 小さくする クラス 50行以内 メソッド 3行以内 パッケージ 10ファイル以内
- 71. 役割ステレオタイプ 設計スタイル 小数の隣人と協力 インタフェース役 小さな（50行以下の） オブジェクトたち 調整役 構造保持役 情報保持役 制御役 サービス提供役 サービス提供役 サービス提供役 情報保持役 情報保持役 情報保持役 サービス提供役 インタフェース役 インタフェース役
- 73. 学びのコツ 学びのデザイン 自分で 自分の「学び」を デザインする
- 74. 学びのコツ 目的へのアプローチ 目的地への道は ひとつではない
- 75. 学びのコツ 創造的な学び 必死に「覚える」学びから 「つくる」・「実践する」 中での学びへ
- 76. 設計の学びの鉄則 考えて コードを書く