オブジェクト指向でなぜつくるのか 第3版


オブジェクト指向でなぜつくるのか 第3版 知っておきたいOOP、設計、アジャイル開発の基礎知識


日経BP


著者:平澤章


推薦のことば
まえがき
本書の構成

第1章 オブジェクト指向はソフトウエア開発を楽にする技術
オブジェクト指向はソフトウェア開発の総合技術
モノ中心にソフトウェアを組み上げる開発手法
プログラミング言語から総合技術に進化した
オブジェクト指向が難しい理由
理由その1ープログラミング言語の仕組みが複雑
理由その2ー比喩を使った説明による混乱
理由その3ーオブジェクト指向というコンセプトが抽象的
オブジェクト指向技術のwhatとwhyを説明する
本書の構成
COLUMN 今ドキのOOP
とっつきやすくて、奥の深いPython

第2章 オブジェクト指向と現実世界は似て非なるもの
オブジェクト指向を現実世界に対比して説明する
クラスは種類、インスタンスは具体的なモノ
ポリモーフィズムはメッセージの送り方を共通にする
継承は共通点と相違点を体系的に分類して整理する
比喩を強調した説明は混乱を招きやすい
オブジェクト指向と現実世界は似て非なるもの
プログラミングのための仕組みと割り切って理解する
そもそもソフトウェアは現実世界をそのまま表現しない
現実世界と似ていることが可能性を広げた
COLUMN オブジェクトの向こう側
パスワードになったオブジェクト指向

第3章 OOPを理解する近道はプログラミング言語の歴史にあり
OOPは必然性を持って登場した
黎明期には機械語でプログラムを書いていた
プログラミング言語の最初の一歩はアセンブリ言語
高級言語の発明でプログラムはより人間に近づいた
わかりやすさを重視する構造化プログラミング
サブルーチンの独立性を高めて保守に強くする
GOTOレスプログラミングを実現する構造化言語
進化の方向は保守性と再利用性重視に変化した
残された課題はグローバル変数問題と貧弱な再利用
COLUMN プログラミング言語
COBOLコンパイラのニワトリとタマゴの話

第4章 OOPは無駄を省いて整理整頓するプログラミング技術
OOPが持つ構造化言語にはない3つの仕組み
OOPの仕組みは言語ごとに微妙に異なる
三大要素1ークラスに備わる3つの仕組み
クラスの効能1ーまとめる
クラスの効能2ー隠す
クラスの効能3ーたくさん作る
インスタンス変数は「仲間内だけのグローバル変数」
三大要素2ー呼び出す側を共通化するポリモーフィズム
三大要素3ークラス定義の重複を排除する継承
三大要素のまとめ
型にはめられるとプログラマは楽になる
クラスを型として利用する
プログラミング言語は「退化」した?
さらに進化したOOPの仕組み
進化したOOPの仕組み1ーパッケージ
進化したOOPの仕組み2ー例外
進化したOOPの仕組み3ーガベージコレクション
OOPの進化のまとめ
OOPを生かすも殺すも心がけ次第
COLUMN 今ドキのOOP
ホームページツールから進化したPHP

第5章 メモリの仕組みの理解はプログラマのたしなみ
OOPのプログラムが動く仕組みを理解しておこう
コンパイラとインタプリンタの2つの実行方式
中間コードを解釈して実行する仮想マシン
CPUは複数のスレッドを掛け持ちで実行する
静的領域、ヒープ領域、スタック領域で管理
OOPの特徴はメモリの使い方にあり
クラス情報はクラスにつき1つだけロードする
インスタンス生成のたびにヒープ領域が他使われる
変数にはインスタンスの「ポインタ」が格納される
インスタンスを格納する変数のコピーに要注意
ポリモーフィズムは異なるクラスが同じ顔を見せる
継承される情報の種類によってメモリ配置は異なる
孤立したインスタンスはガベージコレクションが処分する
COLUMN プログラミング昔話
OOPはダンプが見づらい?

第6章 OOPがもたらしたソフトウエアとアイデアの再利用
OOPの優れた仕組みにより再利用が進んだ
クラスライブラリはOOPのソフトウェア部品群
標準のクラスライブラリは言語仕様の一部
Objectクラスを頂点とする継承構造
フレームワークにはさまざまな意味がある
フレームワークはアプリケーションの半完成品
世界中で再利用されるソフトウェア部品群
独立性の高い部品を意味するコンポーネント
デザインパターンは優れた設計のアイデア集
デザインパターンはクラスライブラリ探検の道しるべ
設計以外の分野にも広がるアイデアの再利用
クラスライブラリやパターンで知る再利用の恩恵
COLUMN 今ドキのOOP
RailsフレームワークでブレークしたRuby

第7章 汎用の整理術に化けたオブジェクト指向
ソフトウェアは現実世界をそのまま表現しない
集合論と役割分担に応用された
上流工程で「汎用の整理術」に化けた
2つの意味を持つことが混乱をもたらした
プログラミング技術と整理術に分けて考える
なぜ汎用の整理術に化けたのか
COLUMN オブジェクト指向の向こう側
言語が先か、コンセプトが先か

第8章 UMLは形のないソフトウエアを見る道具
UMLはソフトウェアの機能や構造を表す図の描き方
UMLには13種類のダイアグラムがある
UMLの使い方は大きく3つある
UMLの使い方1ープログラム構造や動作を表現
クラス図でOOPのプログラム構造を表現
シーケンス図とコミュニケーション図で動きを表現
UMLの使い方2ー汎用の整理術の成果物を表現
集合論で整理した結果をクラス図で表現
役割分担はシーケンス図とコミュニケーション図
UMLの使い方3ー非オブジェクト指向を表現
ユースケース図でコンピュータに任せる仕事を表現
仕事の流れをアクティビティ図で表現
状態の変化をステートマシン図で表現
自然言語とコンピュータ用言語の欠点を補う「言語」

第9章 現実世界とソフトウエアのギャップを埋めるモデリング
現実世界とソフトウェアにギャップがある
得意技は「決まり切った仕事」と「覚える仕事」
業務分析、要件定義、設計でギャップで埋める
モデリングは3ステップを円滑に進めるための技術
アプリケーションによってモデリングの内容は変わる
ビジネスアプリケーションは現実の出来事を記録する
図書館の貸出業務そのものをモデリングする
図書館業務をユースケース図で表現する
図書館システムの情報を概念データモデルで表現する
ビジネスアプリではデータ構造が現実世界を写し取る
組み込みソフトウェアは現実世界の仕事を置き換える
組み込みソフトウェアでは装置の研究開発が重要
全自動で動作する様子をステートマシン図で表現
組み込みソフトウェアは単調な仕事をひたすら実行
モデリングにはソフトウェア開発の醍醐味がある

第10章 擬人化して役割分担させるオブジェクト指向設計
設計が対象とする範囲は広く深い
実行効率よりも保守性や再利用性が重視される時代
設計の目標1ー重複を排除する
設計の目標2ー部品の独立性を高める
部品の独立性を高めるコツ
設計の目標3ー依存関係を循環させない
オブジェクト指向設計の感覚は擬人化と分割分担
役割分担されたソフトウェアが作る奇妙な世界
COLUMN 今ドキのOOP
クラスに縛られずに動くJavaScript

第11章 オブジェクト指向から生まれたアジャイル開発
技術やノウハウだけでソフトウェア開発は成功しない
作業手順や成果物を体系的にまとめた開発プロセス
変更を抑えるウォーターフォール型開発プロセス
ウォーターフォール型開発プロセスの限界
変化に柔軟に対応するための反復型開発プロセス
多くのタブーを破ったXP
チームによる仕事の進め方の枠組みを定めたスクラム
優れたソフトウェアを手早く作るためのアジャイル宣言
アジャイル開発を支えるプラクティス
テストコードを先に書いて動かしながら開発するTDD
動くコードをあとから改善するリファクタリング
定常的にシステム統合を行う継続的インテグレーション
アジャイル宣言の理念を具体的に実践する手法
アジャイル開発はオブジェクト指向から生まれた
決定版の開発プロセスは存在しない
COLUMN プログラミング昔話
昔は許されなかったXP

第12章 オブジェクト指向を使いこなそう
オブジェクト指向という強力なコンセプトが原動力
時代がオブジェクト指向に追いついた
オブジェクト指向はブームで終わらない
オブジェクト指向を使いこなそう
知的なソフトウェア開発を楽しもう

補章 関数型言語でなぜつくるのか
オブジェクト指向と関数型のハイブリッドが主流の時代
関数型言語の7つの特徴
特徴1:関数でプログラムを組み上げる
特徴2:すべての式が値を返す
特徴3:関数を値として扱える
特徴4:関数と引数を柔軟に組み合わせることができる
特徴5:副作用を起こさない
特徴6:場合分けと再帰でループ処理を記述する
特徴7:コンパイラが型を自動的に推測する
7つの特徴のまとめ
関数型言語の分類
関数型言語のメリット
関数型言語の課題
関数型言語とオブジェクト指向の関係
関数型プログラミングを身につけよう
COLUMN 今ドキのOOP
関数型言語の箱庭を用意したJava

あとがき