オブジェクト指向をきちんと使いたいあなたへ

書籍情報

• 著者:青山幹雄, 井上樹, 江川崇, 柏野雄太, 川尻剛, きしだなおき, トム・エンゲルバーグ, 長谷川裕一, 濱田廣貴, 深沢千尋, 星野香保子, 増田亨, 山本裕介
• 発行日:2016-03-03
• ISBN:9784774179810
• URL:http://gihyo.jp/book/2016/978-4-7741-7981-0

書籍目次

• 第0章 最近の「オブジェクト指向」事情――いかにして学び，現場に広めるか
• 第1章 わかった人だけメキメキ上達ちゃんとオブジェクト指向できていますか？
  • 1-1 オブジェクト指向の学び方，教え方
  • 1-2 組み込みからクラウドまで，オブジェクト指向は隅々と！
  • 1-3 JavaScriptでオブジェクト指向
  • 1-4 PHPでオブジェクト指向
  • 1-5 Perlによるオブジェクト指向入門
  • 1-6 オブジェクト指向の基本を学ぶ
• 第2章 オブジェクト指向――習得のヒントと実践
  • 2-1 Javaでオブジェクト指向を知るための3つの基礎練習
  • 2-2 急がず・慌てず自然なぺースでオブジェクト指向を学ぼう！
  • 2-3 社会慣習としてのオブジェクト指向プログラミング
  • 2-4 組込エンジニアのためのオブジェクト指向
  • 2-5 Android開発でオブジェクト指向プログラミングするとは
  • 2-6 オブジェクト指向はまぼろしか？
  • 2-7 SmallTalkこそオブジェクト指向の克服の手がかり
• 第3章 特講オブジェクト指向――苦手克服のベストプラクティス
  • オブジェクト指向の実践的な考え方とやり方
• 第4章 もしも，新卒女子SEが『アジャイル』をマスターしたら――ソフトウェア開発はセンバー・ファルシシムス！
  • 4-1 最初の最初――if i should fall from grace with god
  • 4-2 始まり――アジャイルの寓話。いつか，どこかの街で
  • 4-3 アジャイルとは何か？――アストロ球団とアフリカ
  • 4-4 プロジェクトの準備をしよう
  • 4-5 そろそろ最初のイテレーション
  • 4-6 大規模へと続く道（メトリクス管理）
  • 4-7 おしまいの話
• 第5章 ソフトウェア開発に効くSmall Objectをご存じですか？――オブジェクト指向再入門
  • 5-1 最初の最初
  • 5-2 プロローグ～オブジェクト指向プログラミングの寓話。いつか，どこかの街で～
  • 5-3 最悪な新人研修
  • 5-4 Javaと9つのルール
  • 5-5 ジャンケンをオブジェクト指向する
  • 5-6 注文書でS-OPする
  • 5-7 エピローグ
• 第6章 なぜMVCモデルは誤解されるのか？――本質を押さえて見通しのよいシステム作り
  • 6-1 Java編――MVCの原型を知り，JSP/ServletとSpringMVCで再確認！
  • 6-2 JavaScript編――クライアントサイドMVCの実装をBackbone.js，AngularJSを使って学ぼう
  • 6-3 PHP編――CakePHPを通してMVCを復習，FuelPHP/Symfonyで実践

誤ったクラスの使い方(p.4)

• データクラスと機能クラスを分割する
• 機能分割設計と相性は良かった
• オブジェクト指向が本来目指した方向性とは違った

[MEMO]

• C言語的な共用の構造体を引数に取って処理を行うようなイメージか
• それでは確かに手続き型にならざるを得ない

データクラスと機能クラスを分割するデメリット(p.5)

• 複数の機能クラスがひとつのデータクラスを参照しがち
• コードの重複が発生しやすい
• 保守性悪化→品質低下

[MEMO]

• この問題は何度でも指摘し続けていきたい

Javaの関数型的な機能の追加について(p.7)

• Javaにも関数型的な仕組みが導入された(Java8)
• Javaでも関数型プログラミングができる！
• ただし、設計スタイルのごった煮は危険
• オブジェクト指向を軸に関数型の良さを利用するスタイルが良さそう

[MEMO]

• 可能であることと最善であることは違う、という教訓を胸に邁進したいところ

オブジェクト指向の基本的な考え方(p.10)

• オブジェクト指向は部品指向と言い換えられる
• オブジェクトは小さく単機能にすべし
• 既存のクラスに機能を追加して、クラスを太らせていくのはNG
• 機能追加は新しい部品（＝オブジェクト）の追加で対応する
• 修正は部品の差し替えで対応することを考える

手続き型の考え方(p.11)

• 手続き（処理）が複雑になってくると、小さな手続きに分割する

オブジェクト指向の考え方(p.11)

• 分割の単位がオブジェクトになる
• オブジェクトに分割して、それぞれのオブジェクトに仕事を分担してもらう

小さなオブジェクトに単純な仕事をさせるメリット(p.16)

• (1)独立して存在する単純な仕事のみを請け負うオブジェクトは、変更すべき箇所が明確になる
• (2)変更すべき箇所が明確になるので、変更が局所化される
• (3)変更が局所化されるので、変更時の副作用の心配が減る
• (4)変更時の副作用の心配が減るので、修正や拡張が安全かつ簡単に行えるようになる

getter/setterはNG(p.16)

• フレームワークの制約的に必要であるなど、本当に必要な場合を除いて、getter/setterは書かない
• オブジェクトに必要なデータはコンストラクタで渡すようにし、インスタンスにsetterでデータを渡すことを避ける
• getterは処理の意図が不明確になるので、これを避ける
• 実際の処理の内容がgetterと等価であるとして、処理を明確に表現する名前を付けるべき

オブジェクト指向が難しいとされる理由(p.23)

• 1. オブジェクト指向技術の障壁が高い
• 2. オブジェクト指向の広がり
• 3. 手続き指向からの発想の転換コスト

C言語による設計テクニック(p.23)

• 1, 関数による手続きの抽象化
• 2, 型によるデータの抽象化

オブジェクト指向の意義(p.25)

1. 現実世界のものに対応した抽象的なデータ型を定義できる
2. ソフトウェア設計者がデータ型を定義できる
3. データ型を処理するメソッドを定義できる
4. データ型とその処理をまとめてプログラムの単位にできる
5. クラスは安全で独立性の高いプログラム単位になる

組み込み系の開発現場におけるオブジェクト指向(p.29)

• 組み込み系でオブジェクト指向が使われるようになったのは、2000年代に入ってからのこと
• それまでは、オブジェクト指向言語の処理系は、組み込み機器のマシンスペックには重かったので、採用が困難だった
• 時代が進み、組み込み系もソフトウェアが大規模化が進み、それまでの開発手法では色々限界が見えてきた
• 加えて、組み込み系に使われる機械のマシンスペックも向上してきた
• というわけで、組み込み系でもオブジェクト指向が採用されるようになってきた

オブジェクト指向はなぜ難しいか(p.55)

• オブジェクト指向が指す領域が広い
• オブジェクト指向モデリングやオブジェクト指向DBなど無駄に広い領域で扱えるかのように宣伝されている
• 初級者はあくまでプログラムの拡張性、柔軟性、保守性を向上させるものだと考えた方がよい

[MEMO]

• オブジェクト指向XXXが乱立しすぎ問題は前のページでも触れられていた

オブジェクト指向、デザインパターンは極力使わない(p.57)

• 多くの場合、デザインパターンを適用するとクラス数が増加してむしろ冗長になりがち
• YAGNI原則に従って、拡張する必要が出てきた時に改めて考えればよい
• デザインパターンはコードの拡張性のために使うのでなく、コードをDRYにまとめるために使う方がよい

[MEMO]

• フレームワークの上に乗って開発をする場合はそれでもよさそう
• とはいえ、よいコードを書こうと思うとどうしてもデザパタぽいコードになっていくような気もしないでもない

なぜオブジェクト指向で開発するのか(p.74)

• プログラムのメンテナンスを安全で楽なものにするため

[MEMO]

• 実用性に全振りは潔い
• 妙にポエミーなことを言い始める宗教家にはうんざりさせられてきた

変更が困難なプログラムの特徴(p.74)

• どこに何が書いてるかわからない
• 同じ修正があちこちに必要
• 変更の副作用が怖くて変更できない/変更したら思わぬところに副作用がでる

良いオブジェクト指向的なプログラムの特徴(p.75)

• データを操作するロジックは、そのデータをインスタンス変数に持つオブジェクトにまとめる（データクラスと機能クラスに分けない）
  • データとロジックを別クラスに分けると、データを操作するロジックがあちこちで重複する
• インスタンスを生成する時は、必ず操作対象のデータをコンストラクタに渡す
• インスタンス変数を外部から直接で取得できるようにしない（getterメソッドの禁止）
• インスタンス変数を外部から直接変更できるようにしない（setterメソッドの禁止）
  • オブジェクトのインスタンス変数を書き換える操作は、インスタンスの状態を変化させるので、プログラムの動作が不安定になる
  • データを引数で渡すことを繰り返すと、そのデータを使った判断/加工/計算ロジックが何処に書いてあるか見つけ出すのに苦労する羽目になる

プログラムはネットワーク構造である(p.83)

• オブジェクト指向では、ソフトウェア構造をツリー構造とは考えない
• 多種のオブジェクトがネットワーク状に連携するイメージ

UMLに関して(P.83)

• UMLの仕様は膨大かつ複雑なので、全てを理解しようとするのは無理がある
• 全てを理解する必要はないが、クラス図の基本的な記法は覚えておくとチーム内での共通言語として使えるので便利である