Practical
Object-
Oriented
Design in
Ruby
第一章
@kenzan100
Rubyを使った
実践的な
オブジェクト指向デザイン
プログラミング
https://twitter.com/kenzan100
この資料の文脈
岡崎 雄太
株式会社InnoBetaで、エンジニアしてます。
!
社内勉強会で、
Practical Object Oriented-Design in Ruby の
...
今までのパラダイム:手続き型プログラミング
The world is procedural. Time flows forward and events, one by one, pass by.
Your morning procedure m...
オブジェクト指向登場
!
この本では、世界を
「オブジェクト間の 自発的な 相互作用 」
として説明してみる
In a world of objects, new arrangements of behavior emerge naturall...
デザインが必要なときってどんなとき?
予期せぬ変更が今後起こりうるとき
↓
つまり「ほぼ常に」
※使い捨てのコードは除く
Applications that are easy to change are a pleasure to write ...
The parts are objects; interactions are embodied in the messages that pass between them.
Getting the right message to t...
デザインの難しさ
You must not only write code for the feature you plan to deliver today,
you must also create code that is amenabl...
The purpose of design is to allow you to do design later
and its primary goal is to reduce the cost of change.
将来どうなるか予見...
今までの人が提言した偉大な原則
coined by Michael Feathers and popularized by Robert Martin
SOLID design principle
Single Responsibility...
デザインが失敗するとき
“Yes, I can add that feature, but it will break everything.”
NoDesign状態
OverDesign(脱初級者)状態
“No, I can’t add ...
your customers can’t define the software they want before seeing it
アジャイルの論理構造
ある実装をすることで初めて、次に提供すべき価値が何かが分かる
導きだされる帰結
FX...
The design documents of BUFD start out as roadmaps for application development but gradually
become the focus of dissent.	...
The ultimate software metric would be cost per feature over the
time interval that matters,
それが良いデザインかどうか、どう判断するか
Source...
Procedural Languageをこきおろして、
Object Oriented Language like Rubyをもちあげる段落
いままでは構造体の定義だけを見ていても「で、このデータはどう
いう操作をされうるの?」ってのがわかんな...
第一章のサマリー
あなたが実務的なアプリケーション、
ソースコードにコミットしているのであれば、
「今後の変更/変化にどう対応するか」が、
一番の課題なはず。
!
そこでデザインが力を発揮する。
!
デザインをどこまで考えられるかは、
あなたの...
of 15

Rubyを使ったオブジェクト指向デザイン実践:第一章発表

下記の本を社内勉強会で輪読しています。 "Practical Object Oriented Design in Ruby" by Sandi Metz
Published on: Mar 4, 2016
Published in: Technology      
Source: www.slideshare.net


Transcripts - Rubyを使ったオブジェクト指向デザイン実践:第一章発表

  • 1. Practical Object- Oriented Design in Ruby 第一章 @kenzan100 Rubyを使った 実践的な オブジェクト指向デザイン プログラミング
  • 2. https://twitter.com/kenzan100 この資料の文脈 岡崎 雄太 株式会社InnoBetaで、エンジニアしてます。 ! 社内勉強会で、 Practical Object Oriented-Design in Ruby の 輪読を始めたので、読みながら要約しました。
  • 3. 今までのパラダイム:手続き型プログラミング The world is procedural. Time flows forward and events, one by one, pass by. Your morning procedure may be to get up, brush your teeth, make coffee, dress, and then get to work. These activities can be modeled using procedural software; because you know the order of events you can write code to do each thing and then quite deliberately string the things together, one after another. 世界を「手続き型」として見てみよう。 あなたは朝起きて、 歯を磨いて、 着替え、 会社に行く。 この「順番」に注目して、 コードを紡いでいくのが Procedural Programming
  • 4. オブジェクト指向登場 ! この本では、世界を 「オブジェクト間の 自発的な 相互作用 」 として説明してみる In a world of objects, new arrangements of behavior emerge naturally. You don’t have to explicitly write code for the spouse_steps_on_cat procedure, all you need is a spouse object that takes steps and a cat object that does not like being stepped on. Put these two objects into a room together and unanticipated combinations of behavior will appear. 第一章:視点の説明から始めます
  • 5. デザインが必要なときってどんなとき? 予期せぬ変更が今後起こりうるとき ↓ つまり「ほぼ常に」 ※使い捨てのコードは除く Applications that are easy to change are a pleasure to write and a joy to extend. They’re flexible and adaptable. そういった自体が想定できるかぎり、 OODで書いておこう。 その方が、絶対にあとあと楽しいよ!
  • 6. The parts are objects; interactions are embodied in the messages that pass between them. Getting the right message to the correct target object requires that the sender of the message know things about the receiver. This knowledge creates dependencies between the two and these dependencies stand in the way of change. Object-oriented design is about managing dependencies. It is a set of coding techniques that arrange dependencies such that objects can tolerate change. 結局デザインって何を工夫することなの? メッセージを送りあう以上は、送り主は 送り先のことを知らなきゃいけない。 これは依存関係が生まれることを意味している。 ! この依存関係をどうするか考えるのが、 要するにオブジェクト指向でデザインする、ということ。
  • 7. デザインの難しさ You must not only write code for the feature you plan to deliver today, you must also create code that is amenable to being changed later. 「これ全部書き直した方が早いんじゃね?」 ってならないために、 今も将来もCostEffectiveなコードレイアウトを 選択する
  • 8. The purpose of design is to allow you to do design later and its primary goal is to reduce the cost of change. 将来どうなるか予見するのは、 不可能じゃね? 将来のことを考えるというのは 「将来どんな変更がきてもよいように、変更に強くしておく」 ということ。
  • 9. 今までの人が提言した偉大な原則 coined by Michael Feathers and popularized by Robert Martin SOLID design principle Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion. Andy Hunt and Dave Thomas’s DRY (Don’t Repeat Yourself) and the Law of Demeter (LoD) from the Demeter project at Northeastern University. これら原則の強力さは、信じてほしいとのこと。 原則以外にも、「パターン」があるよ OOP Design Pattern by Gang of Four + 詳しくはググれ
  • 10. デザインが失敗するとき “Yes, I can add that feature, but it will break everything.” NoDesign状態 OverDesign(脱初級者)状態 “No, I can’t add that feature; it wasn’t designed to do that.” “Well, I can certainly write this, but it’s not what you really want and you will eventually be sorry.” ※DesignedByOthers(仕様書 神)状態 「それできるけど、他の機能全部壊れちゃうよ!?」 「そんな機能を増やすことは、設計上できません。」 「やることはできるけど..どうなっても知らないよ?」
  • 11. your customers can’t define the software they want before seeing it アジャイルの論理構造 ある実装をすることで初めて、次に提供すべき価値が何かが分かる 導きだされる帰結 FXXK Big Up Front Design (BUFD) 納期は定義不可能
  • 12. The design documents of BUFD start out as roadmaps for application development but gradually become the focus of dissent. The word design when used in BUFD has a differ- ent meaning than when used in OOD. BUFD is about completely specifying and totally documenting the anticipated future inner workings of all of the features of the proposed application. If there’s a software architect involved this may extend to deciding, in advance, how to arrange all of the code. OOD is concerned with a much narrower domain. It is about arranging what code you have so that it will be easy to change. Agile processes guarantee change and your ability to make these changes depends on your application’s design. 仕様書頼みの状況は、 責任のなすり付け合いしか産み出さない 仕様書をつくることと、オブジェクト指向で設計することの違い 仕様書は、将来の変更を許容しない。 設計は、 将来の変更を「請け負う。
  • 13. The ultimate software metric would be cost per feature over the time interval that matters, それが良いデザインかどうか、どう判断するか SourceCode Lines Of Code時代 OOP metric 時代 でも、OOP metricで良いスコアでも、良いデザインとは限らない (その逆は真だけど) 究極の判断指標は、 1機能あたりにかかったコストを、 その寿命で割ること 一生懸命設計しても、その設計が報われるのが一年後なら(おそらく)それはやりすぎ。
  • 14. Procedural Languageをこきおろして、 Object Oriented Language like Rubyをもちあげる段落 いままでは構造体の定義だけを見ていても「で、このデータはどう いう操作をされうるの?」ってのがわかんなくて「うっどんなこと が起こるかわからなくて怖い」ってなってたことが、「ほうほう、 このデータはこういう操作をされうるのか」というのがクラス定義 を見るだけでわかるようになりました。安心ですね! 分かりやすかったので他ブログから引用 http://nekogata.hatenablog.com/entry/2014/01/17/125600
  • 15. 第一章のサマリー あなたが実務的なアプリケーション、 ソースコードにコミットしているのであれば、 「今後の変更/変化にどう対応するか」が、 一番の課題なはず。 ! そこでデザインが力を発揮する。 ! デザインをどこまで考えられるかは、 あなたの「理論を実践に活かす能力」による。 だからがんばって、第二章以降も読もう!

Related Documents