ホーム > 読んだ >

TURBO C++/BORLAND C++による
オブジェクト指向狂詩曲(ラプソディー)

書誌

author吉田弘一郎
publisher技術評論社
year1993
price1,900
isbn87408-484-2

目次

1感想
2メモ

履歴

editor唯野
1999.7読了
1999.9.6公開
1999.10.30修正

オブジェクト指向の入門書。おもしろいことはおもしろいのだが、ネタに古過ぎるところがあるため、私のような若輩者には分からない箇所がいくつもあった。著者は C/C++ が嫌いと公言してはばからないものの、そういう前提のもとで C++ を用いた OOP 本というスタンスそのものも変わっているというか、変な感じがする。個人的には『憂鬱なプログラマのためのオブジェクト指向開発講座』の方がためになったが、C++ の文法だけでいきなり OOP というわけにはいかないのも事実なので、そういう本へつなげていくための入口として考えるならば、これでもよいのかもしれない。

メモ

オブジェクト指向言語
Smalltalk, Object Pascal, Objective C, CLOS, Eiffel, Simula

言語が道具でライブラリが材料

言語で用が足りる範囲に思考も限定される傾向がある

プログラム開発環境とプログラムが別物であった時代は終わりつつある
アプリケーションの開発環境と使用環境の共通部分が増えた
Mac のプログラムは Mac な開発環境を要求する

Smalltalk は象牙の塔のものだったが、
そこから Mac のインタフェースとしてのヒントを得て
世間一般のものとしたのは Steve Jobs だった。

ライブラリがコンテクストを規定する
ライブラリの呼び出し形式がプログラムの文脈までを規定してしまう
ライブラリは、それがコンテクストを規定してしまったときに限界がある

手続き型としてコンテクストが規定されればされるほど
呼び出し形式だけにプログラマはとらわれてしまう

Pascal の生みの親である N.Wirth はいった
アルゴリズム + データ構造 = プログラミング

ライブラリのライブラリたるゆえんのひとつは、それがブラックボックスであること
中身よりもどういう機能を提供しているか
ライブラリがライブラリへの全ての理解を要求したのではよいライブラリではない

使わせてやるプログラムの多さと使うだけのユーザの多さ

情報を隠蔽するということはグローバル変数を使わないことに近い

C++ では public: にした途端、透明になってしまい ReadOnly とはならない
(これは私も変に思う 多分、const しろということなのだろうが:唯野)

「オブジェクト = アルゴリズム + データ」
クラスとして動作までを含めてしまえば、
そこではアルゴリズムまでを含めることになる

クラスを用いればアルゴリズムとデータ構造をひとつのものとしてまとめられる
(どちらも同じ次元で扱われているから)

MS-DOS での BIOS コールは
アセンブラな世界というべきでデータ構造はないに等しい

使って天国、作って地獄

きちんとしたアルゴリズムは例外なく単純なので、単体では使い物にならない

アメリカでは
下手なユーザのことを(コンピュータ以外での)プロフェッショナル、
計算機のプロのことをエキスパートと区別する

GUI の世界には相当に確立された標準が存在する
(もちろん、その標準の善し悪しとは別の問題で...)

クラスはオブジェクト型であり、オブジェクトはクラス型変数である
(クラスもオブジェクトである)

オブジェクトを作るときにはオブジェクト製造装置から先に作る

クラスライブラリをユーザの立場から使う意味で継承を行う

protected: すれば子のクラスからはアクセスできる

内部データは protected する
継承は public する

親クラスの苦労を子クラスが知る必要はない

メッセージは外界からオブジェクトへの公的コマンド
内部関数はオブジェクトの私的プロシジャ

virtual で独自性を持った子クラスを定義できる

演算子のオーバーロードを我々は極めて普通に使っている
1 + 2 = 3
0.1 + 0.2 = 0.3
1 + 0.2 = 1.2

オーバーロードされた演算子は friend する

friend AAA operator*(double, AAA);
は
double * AAA が AAA を返す
ということ

わざわざ多重継承をしなくても、
そのクラスのデータメンバを作ることでなんとかなることもある

後期結合を使えば case 文のような分岐が不要になる

クラスの縦関係 : 継承 (is a : である)
クラスの横関係 : クライアント・サプライヤ関係 (has a : 持っている)
プログラムの対象から、この関係を正しく抽出する

2段階ブーム説
第1段階(研究) -> (標準化) -> 第2段階(ビジネス)
専門家             演出      一般化

OOP <- OOD <- OOA
いきなりソースコードを打ち込みコーディングしながら考えることは、
オブジェクト指向では考えにくくなる

OOA とはクラスの抽出ということ

静的な分類 -> 機能やデータの流れ -> クラス・ライブラリの構築

オブジェクト指向でアプリを組む前に
クラス・ライブラリを用意するという前提を置く

サプライヤ側からのクラス・ライブラリと
クライアント側からのクラス・ライブラリは違う

Windows プログラムでは main() が見えない
つまり既にできあがった世界での自由しかないが、
基本的な作法は始めから身に付けている...そういう世界

汎用性の要求される部分と個々の AP に依存する部分との明確な区別

OOP したら膨大なクラス・ライブラリのマニュアルがついてきた...
(ちっともコンパクトになっていないじゃないか !?)

Up