2016 ObjectOrientedについて

ソフトウェア危機 (wikipedia) とは

1960年代の後半、コンピュータが進歩するにつれて、より複雑 なソフトウェアが求められ始める時代、その複雑さをコントロールするた めの道具やアイデアはあまり多くなかった。

プロジェクトは、複雑化する一方なのに、管理手法もなければ、データ型 は基本的な数値でしかなく、変数はメモリアロケーションそのものだった。

また、プログラムの流れは、gotoやjump命令のようにプログラムカウンタ を直にコントロールする抽象度の低いもので制御されることが多かった。

プログラムはフローチャートで記述され、それをマシン語としてパンチす るといったプロジェクトX的な世界のことを考えれば、その理解が正しいの かもしれない。

なんにせよ、そういった当時の人からすると逼迫していたが、今から見る となんとも牧歌的な世界観の中で、構造化プログラミングという概念が生 まれる。

ダイクストラは構造化プログラミングを提案した

ときどき、勘違いされているが構造化プログラミングとは「手続き型言語」 のことでもなければ「gotoを使わないプログラミング」のことでもない。

こういった背景のなか、プログラムは大きく複雑になり続ける。至極自然 な流れとして、それを分割しようとしていく。

よいモジュール化の肝は、状態と副作用を隠蔽し、データとアルゴリズム をひとまとめにすることだった。

それらを言語的に支援するために抽象データ型という概念が誕生した。

抽象データ型は、今で言うクラスのことだ。すなわちデータとそれに関連 する処理をひとまとめにしたデータ型のことだ。ようやくオブジェクト指 向の話に近づいてきた。ダイクストラの構造化プログラミングでは、デー タ処理をどのように抽象化するかが課題として残っていた。

また、データ型と実際のメモリアロケーションは別であるので、新たに変 数を定義するとデータの共有はしない。あるデータ型を実際に存在するメ モリに割り当てることをインスタンス化という。

抽象データ型のポイントは、その内部データへのアクセスを抽象データ型 にひもづいた関数でしか操作することができないという考え方だ。

これはつまり、たとえば、先ほどのC言語の例でいうと

//people.h

typedef struct {
    //内部構造も公開している
} people;

void people_init(people *p,...);

char * people_get_name(people *p);

void people_set_name(people *p,char *name);

このままだと、構造体の内部構造も公開しているので、

people user;
user.age = 10;
printf("%d years old",user.age);

のように内部構造に直接アクセスできてしまう。C言語では、テクニック としてperson.h　こちらを公開する

typedef struct sPerson person;

void person_init(person *p,...);

char * person_get_name(person *p);

void person_set_name(person *p,char *name);

//people_private.h　こちらはモジュール内で利用する

#include "person.h";

struct sPerson {
    //　ここに内部構造
};

//非公開用関数
_person_private(person *p,....);

公開するヘッダと非公開のヘッダを分けることで、情報の隠蔽を行い抽象 データ型としての役目を成り立たせている。

さて、継承と多態を足した抽象データ型といっても、なんだか良くわからない。

特に多態がいまいちわかりにくい。オブジェクト指向プログラミングの説明で

string = number.StringValue
string = date.StringValue

これで、それぞれ違う関数が呼び出されるのがポリモーフィズムですよと 呼ばれる。

これだけだとシグネチャも違うので、違う処理が呼ばれるのも当たり前に 見える。

では、こう書いてみたらどうか

string = stringValue(number) // 実際にはNumberToStringが呼ばれる
string = stringValue(date)   // 実際にはDateToStringが呼ばれる

このようにしたときに、すこし理解がしやすくなる。引数の型によって呼 ばれる関数が変わる。こういう関数を polymorphic (poly-複数に morphic- 変化する) な関数という。

これをみたときに"関数のオーバーロード"じゃないか？と思った人は鋭い。 https://ja.wikipedia.org/wiki/%E5%A4%9A%E9%87%8D%E5%AE%9A%E7%BE%A9

多態とは異なる概念とされるが、引数によって呼ばれる関数が変わるとい う意味では似ている。しかし、次のようなケースで変わってくる。

function toString(IStringValue sv) string {
    return StringValue(sv)
}

IStringValueはStringValueという関数を実装しているオブジェクトを表す インターフェースだ。これを受け取ったときに、関数のオーバーロードで は、どの関数に解決したら良いか判断がつかない。関数のオーバーロード は、コンパイル時に型情報を付与した関数を自動的に呼ぶ仕組みだからだ。

stringValue(number:Number) => StringValue-Number(number)
stringValue(date :Date)  => StringValue-Date(date)

function toString(IStringValue sv) string {
    return StringValue(sv) => StringValue-IStringValue (無い！)
}

それに対して、動的なポリモーフィズムを持つコードの場合、次のように 動作してくれるので、インターフェースを用いた例でも予想通りの動作を する。

function StringValue(v:IstringValue){
    switch(v.class){ //オブジェクトが自分が何者かということを知っている。
    case Number: return StringValue-Number(number)
    case Date   : return StringValue-Date(date)
    }
}

このようにどの関数を呼び出すのかをデータ自身に覚えさせておき、実行 時に探索して呼び出す手法を 動的分配*，*動的ディスパッチ と呼ぶ。

このように動的なディスパッチによる多態性はどのような意味があるのか。

それはインターフェースによるコードの再利用と分離である。

特定のインターフェースを満たすオブジェクトであれば、それを利用した コードを別のオブジェクトを作ったとしても再利用できる。

これによって、悪い凝集で例に挙げた論理的凝集をさけながら、 汎用的な処理を記述することができるのだ。

オブジェクト指向がはやり始めた当時は、再利用という言葉が比較的バズっ たが、現在的に言い換えるなら、インターフェースに依存した汎用処理と して記述すれば、結合度が下がり、テストが書きやすくなったり、仕様変 更に強くなったりする。

アランケイの世界観の中では、メモリとCPUとそれに対する命令を持つ機械 をさらに抽象化するとしたら、それは同じくデータと処理と命令セットを もつ仮想機械で抽象化されるべきだと考えていた。

構造化プログラミングの中でダイクストラが仮想機械として階層 的に抽象化すべきだと言っていたこととかぶる。

オブジェクトは独立した機械と見なし，それに対してメッセージを送り、 自ら持つデータの責任は自らが負う。

Smalltalkの実行環境もまた仮想機械として作られている。

Smalltalkでメッセージ送信は下記のように記述する:

receiver message

Objective-Cであれば、C言語の中に次のように書く:

[receiver message]
[receiver methodName:args1 with:args]

メッセージとは通信のアナロジーだ。アドレスさえ知っていれば、メッセー ジは自由に送れる。受信者(レシーバ)はメッセージを受け取っているにす ぎないので、その解釈は自由に行うことができる。

このメッセージらしさが出てくる特徴をいくつか紹介しよう。

このようにメッセージパッシングというアナロジーを使うことで、様々な 性質がオブジェクト指向には加わることになった。

しかし、オブジェクト指向という言葉が意味しているのが、C++の再定義 したオブジェクト指向として理解されることで、このメッセージパッシン グの要素が意識されなくなってしまったため、前述したようにアランケイ はその命名が不適切だったと考えているらしい

https://www.infoq.com/jp/news/2010/07/objects-smalltalk-erlang

この記事は今までの議論の流れをふまえると、理解がしやすいと思う。 特に

私は、オブジェクト指向プログラミングというものに疑問を持ち始めまし た。Erlangはオブジェクト指向ではなく、関数型プログラミング言語だと 考えました。そして、私の論文の指導教官が言いました。「だが、あなた は間違っている。Erlangはきわめてオブジェクト指向です。」 彼は、オ ブジェクト指向言語はオブジェクト指向ではないといいました。これを信 じるかどうかは確かではありませんでしたが、Erlangは唯一のオブジェク ト指向言語かもしれないと思いました。オブジェクト指向プログラミング の3つの主義は、メッセージ送信に基づいて、オブジェクト間で分離し、 ポリモーフィズムを持つものです。

ソフトウェア危機

コンピュータが進歩するにつれて、より複雑なソフトウェアが求められ始める その複雑さをコントロールするための道具やアイデアが不足

プロジェクト管理手法もなければ、 抽象度の低いデータ型，変数，制御構造

構造化プログラミング(wikipedia)

つまり、現代風に言い換えると「レイヤリングアーキテクチャ」のよう なもので、ある土台の上にさらに抽象化した土台をおき、その上にさら に・・・というようにプログラムをくみ上げていく考え方のことだ。

だから、我々は、ひとつのアーキテクチャないし関数の中で異なる抽象 化レイヤの実装を同居することをさける。

大きく複雑になるプログラムの分割

よいモジュール化の肝

• 状態と副作用を隠蔽し、
• データとアルゴリズムをひとまとめにする

それらを言語的に支援するために抽象データ型という概念が誕生した。

抽象データ型は、今で言うクラス

• すなわちデータとそれに関連する処理をひとまとめにしたデータ型のこ とだ。
• 抽象データ型のポイントは、その内部データへのアクセスを抽象データ 型にひもづいた関数でしか操作することができないという考え方だ。

内部構造を隠し，型とインタフェースを公開する。

• 公開するヘッダと非公開のヘッダを分けることで、情報の隠蔽を行い抽象 データ型としての役目を成り立たせている。

さて、継承と多態を足した抽象データ型といっても、なんだか良くわからない。

特に多態がいまいちわかりにくい。オブジェクト指向プログラミングの説明で

string = number.StringValue
string = date.StringValue

これで、それぞれ違う関数が呼び出されるのがポリモーフィズムですよと 呼ばれる。

これだけだとシグネチャも違うので、違う処理が呼ばれるのも当たり前に 見える。

では、こう書いてみたらどうか

string = stringValue(number) // 実際にはNumberToStringが呼ばれる
string = stringValue(date)   // 実際にはDateToStringが呼ばれる

このようにしたときに、すこし理解がしやすくなる。引数の型によって呼 ばれる関数が変わる。こういう関数を polymorphic (poly-複数に morphic- 変化する) な関数という。

これをみたときに"関数のオーバーロード"じゃないか？と思った人は鋭い。 https://ja.wikipedia.org/wiki/%E5%A4%9A%E9%87%8D%E5%AE%9A%E7%BE%A9

多態とは異なる概念とされるが、引数によって呼ばれる関数が変わるとい う意味では似ている。しかし、次のようなケースで変わってくる。

function toString(IStringValue sv) string {
    return StringValue(sv)
}

IStringValueはStringValueという関数を実装しているオブジェクトを表す インターフェースだ。これを受け取ったときに、関数のオーバーロードで は、どの関数に解決したら良いか判断がつかない。関数のオーバーロード は、コンパイル時に型情報を付与した関数を自動的に呼ぶ仕組みだからだ。

stringValue(number:Number) => StringValue-Number(number)
stringValue(date :Date)  => StringValue-Date(date)

function toString(IStringValue sv) string {
    return StringValue(sv) => StringValue-IStringValue (無い！)
}

それに対して、動的なポリモーフィズムを持つコードの場合、次のように 動作してくれるので、インターフェースを用いた例でも予想通りの動作を する。

function StringValue(v:IstringValue){
    switch(v.class){ //オブジェクトが自分が何者かということを知っている。
    case Number: return StringValue-Number(number)
    case Date   : return StringValue-Date(date)
    }
}

このようにどの関数を呼び出すのかをデータ自身に覚えさせておき、実行 時に探索して呼び出す手法を 動的分配*，*動的ディスパッチ と呼ぶ。

このように動的なディスパッチによる多態性はどのような意味があるのか。

それはインターフェースによるコードの再利用と分離である。

特定のインターフェースを満たすオブジェクトであれば、それを利用した コードを別のオブジェクトを作ったとしても再利用できる。

これによって、悪い凝集で例に挙げた論理的凝集をさけながら、 汎用的な処理を記述することができるのだ。

オブジェクト指向がはやり始めた当時は、再利用という言葉が比較的バズっ たが、現在的に言い換えるなら、インターフェースに依存した汎用処理と して記述すれば、結合度が下がり、テストが書きやすくなったり、仕様変 更に強くなったりする。

• 抽象データ型：データと処理をひもづける
• 抽象データ型：情報の隠蔽を行うことができる
• オブジェクト：データ自身が何者か知っている
• 動的多態：オブジェクト自身のデータと処理を自動的に探索する
• 探索先の設定：継承、委譲

ということになる。

アランケイの世界観

コンピュータを抽象化するとしたら、データと処理と命令セットをも つ仮想機械で抽象化されるべき

構造化プログラミング

仮想機械として階層的に抽象化すべき

オブジェクト指向

オブジェクトを独立した機械と見なし、それに対してメッセージを送 り、自ら持つデータの責任は自らが負う。

Smalltalkの実行環境もまた仮想機械として作られている。

Smalltalkでメッセージ送信は下記のように記述する:

receiver message

メッセージングは通信。

• アドレスさえ知っていれば、メッセージは自由に送れる。
• レシーバはメッセージを受け取リ，その解釈はレシーバ自身が行う

このメッセージらしさが出てくる特徴をいくつか紹介しよう。

https://www.infoq.com/jp/news/2010/07/objects-smalltalk-erlang

オブジェクト指向プログラミングの3つの主義は、

• メッセージ送信に基づいて、
• オブジェクト間で分離し、
• ポリモーフィズムを持つ

• データ構造と機能は一緒にすべきではない

（Objection 1 - Data structure and functions should not be bound together）

オブジェクトは関数とデータ構造が分割出来ない単位としてひとつまとめにし ています。しかし、私はこれこそが基本的でかつ大きな誤りであると考えてい ます。なぜなら、関数とデータは異なる世界に存在するからです。なぜでしょ う。関数は何かを実行します。そして関数はインプットとアウトプットを持ち ます。関数の入力と出力はデータ構造であり、関数により変更されます。

• 「関数とデータは異なる世界に存在するからです」は，理由が希薄です。
  • 「関数とデータは，異なるものです。」は認めます。
  • データとその処理関数は近くにあって，同時に見られた方が，分かりやす いことが多いと思う。
  • データだけからなるクラスがあってもいいし，インタフェースだけからな るモジュールがあってもいい。Rubyではそうなっている。

多くの言語の関数は命令のシーケンスから作られます。すなわち、「まずはこ れを実行して、次はこれを実行しなさい」という手順です。関数を理解するた めにはどのような順序でものごとが実行されるかを理解しなければなりません （遅延評価をサポートする関数型言語と論理型言語ではこの制限は緩やかで す）。

• 関数についての説明はそのとおり。

データ構造はそれそのものです。これらは何もしません。これらは本来宣言的 なものなのです。データ構造を理解することは関数を理解することよりもはる かに簡単なことなのです。

• これは違うと思う。データ構造だけを見て，データ構造を用いてできる ことを理解することは，ほんとうに難しいこと，だと思う。

関数は，入力から出力へと変換するための，ブラックボックスです。入力と出 力を理解すれば，関数を理解したことになります。でも理解したからと言って， 関数を記述できることにはなりません。

• 些細なことですが，「入力と出力を理解すれば関数を理解したことになり ます」ではなくて，関数を利用できることになるだと思います。そして， 「関数を利用できない人に，関数の中身は記述できません」だと思います。

関数は通常、コンピュータシステムにおいてジョブがデータ構造をT1からT2に 変換することの観察を通して理解したことになります。

• ここは最初，理解できませんでした。
• 「関数を書くには，複数のデータを見なくてはいけない。ある一つの型を主 にみて，書くことはよくない」と言ってるのかな。
  • そうかもしれないが，。。。

  • 適切な抽象度で見れば，関数のやってることは下記の3種 (ほんとかな？):

    変換

    自身 -> 自身

    簡約

    自身 -> 自明なもの

    合成

    自身 -> 高いレベルのもの

    だとすると，変換や簡約は自身と一緒に記述してあると，わかりやすい。 合成は，自身の中に記述するのではなく，高いレベルのものと一緒に書 くべきだと，思えます。

    入力が複数ある場合は，「どれか主になるものがある」場合や，「一纏 めとして扱うことができる」場合は，型(データ)を主に，処理の記述が でき，何をやっているのかが，分かりやすいと，思えます。

このように関数とデータ構造は全く異なるタイプの生き物です。そしてそれを 同じカゴの中に閉じ込めるのは全く持って間違っていることなのです。

• 「異なるタイプの生き物を同じカゴに閉じ込めるのは間違い」は，理由になっていません。
• 関数とデータ構造を近くに置いて，同時に見られることは，いいことです。
• 問題があるとすれば，同じデータ構造に対し，異なる操作関数からなるク ラスが沢山ある場合の冗長さかな。

• 「データを理解することは簡単」が考え方の違いの根本ですね，きっと。

  データ駆動なのか関数駆動(こんな言葉ある？)なのかの違いですね。

  関数駆動において，関数をできるだけ汎用にするためには，入力の型は， できるだけシンプルにし，入力の意味を多様に解釈・適応できることが， 関数の汎用性を高めるこになる。

  オブジェクト指向では，その解釈や適応できることを，書いておきたいんだ よね。きっと。

• すべてはオブジェクトではない

(Objection 2 - Everything has to be an object.)

「時刻」について考えてみましょう。OO言語の立場での「時刻」はオブジェク トであるべきです。でも、非OO言語では「時刻」はデータタイプのインスタン スです。例えばErlangでは「時刻」の多くのバラエティがあります。これらは とても明白で曖昧さがありません。

• 時刻を表すデータ型はあったほうがいいでしょう。自明だと思います。時 刻を表すのに整数の組み合わせをもちいたいならそうもできます。 オブジェクトであるべきかどうかの議論にはなっていません。

    -deftype day() = 1..31.
    -deftype month() = 1..12.
    -deftype year() = int().
    -deftype hour() = 1..24.
    -deftype minute() = 1..60.
    -deftype second() = 1..60.
    -deftype abstime() = {abstime, year(), month(), day(), hour(), min(), sec()}.
    -deftype hms() = {hms, hour(), min(), sec()}.
    ...

これらの定義はどの特定のオブジェクトにも属していません。これらはどこで
も利用できるデータ構造で「時刻」を表現しており、システムのどの関数から
でも利用することができます。

そしてどのようなメソッドにも関連していません。

• これらはインタフェース群とクラス (abstime(), hms()) )に見えるなぁ。

(Objection 3 - In an OOPL data type definitions are spread out all over the place.)

オブジェクト指向ではデータタイプはオブジェクトとして定義されます。そう するとデータタイプは一箇所で見つけることができません。ErlangやCではす べての私のデータは一箇所であるinclude fileもしくはデータ辞書でみつける ことができます。でも、OOPLではこのようなことができず、データタイプ定義 はあちこちに散らばってしまいます。

• Rubyでは，class/module 単位のまとまりをつくり, 継承やincludeにより 階層を作り，require によって，必要なライブラリを記述し， 適切な抽象度で，見ることができる。散らばっているのではなく， 適切なまとまりごとに*リンク*づけられている。 一望したければ，ツールをつくればいいだろう。

この例を示しましょう。私が汎用的なデータ構造を定義したいとします。この 汎用データタイプとはシステムのすべての場所で使えるものです。

LISPプログラマであれば「わずかな汎用データタイプと多くの小さな関数がこ れらに作用すること」が「数多いデータタイプとこれらに作用する少ない数の 関数よりも良いこと」という真実を知っています。

そして､汎用データ構造としてリンクリストや配列、ハッシュテーブルがあり、 さらには時刻、日付、ファイル名などがあります。

OOPLでは私は汎用的なデータ構造を定義する際にはなにかベースオブジェクト の中から選択しなければならないというとても面倒くさいことをしなければな りません。そして､そのデータ構造はこのオブジェクトを継承して作る必要が あります。もし何か「時刻」のオブジェクトを定義したい場合、これがどのベー スオブジェクトに所属していて、それ自体、どのようなオブジェクトであるか 考えなければならないのです｡

• オブジェクトはプライベートな状態を持っている

（Objection 4 - Objects have private state.）

状態(state)は諸悪の根源です。特に関数の副作用は避けるべきです。しかし ながらプログラミング言語において状態は好ましいものではないのに関わらず、 実世界では状態は至るところに存在します。

• はい，実世界をモデル化するプログラムでは，状態を持つことは 避けら れませんね。

例えば私は銀行口座の状態､すなわちに預金残高に大いなる関心があります。 そしていつ私が入金や出金をする場合には銀行の口座が正しく更新されなけれ ばとても困ったことになります。

実世界でこのような状態が存在したとして、この状態を取り扱うためにはプロ グラミング言語はどのような仕組みを提供すればよいのでしょうか。

OOPLはプログラマから状態を隠しなさいといいます。状態は隠されてアクセス 関数を通してしか見えません。

伝統的なプログラミング言語であるCやPasalでは状態変数の可視性は言語のス コープのルールによってコントロールされます。

でも､純粋に宣言的な言語では状態は存在しないことになっています。このよ うな宣言的言語ではシステムのグローバルな状態はすべての関数の入力や出力 になりうるのです。関数型言語におけるモナドや論理型言語におけるDCGでは 「状態はあたかも関係のないように」プログラミングすることができます。に も関わらず必要な場合にはこれらのシステムの状態に完全にアクセスをするこ とができるのです。

ほんとうは「プログラマから状態を隠す」というOOPLで選択されたオプション はとても悪いものなのです。状態を公開して状態の厄介さを最小限にしようと する努力をすべきなのに､その代わりとしてOOPLではそれを隠し去ってしまっ たのです。

• よく理解できていませんが，「プログラマから状態を隠すのは良くない， OOPLだけがそうしている」という主張と読みました。
• 「隠くすことも，公開することも，できるようにしよう」という立場だと思 います。アクセスすべきものは，アクセスできるようにします。でも，アク セスする時は，その持ち主のメソッドを通してというのが，Rubyのやり方。

1つの入り口と1つの出口を持つようなプログラムは「順次・反復・分岐」の3 つの基本的な論理構造によって記述できる

• 基本3構造
  • 順次（連接）
  • 反復（繰り返し）
  • 分岐
• 段階的詳細化
  • 言葉どおりに捉えれば段階的に詳細にしていくということ
  • つまりトップダウンで詳細化するということ
  • 基準が必要
    • 凝集度
    • 結合度

• 構造化プログラミングにおけるトップダウンの機能分解には、確かに問題がある。
  • この問題がオブジェクト指向の動機にもなっている。
• ただし、構造化プログラミングの実装部分のエッセンス（特に凝集度・結合度の考え方）は今でも参考 になる。
  • 構造化プログラミング – 段階的詳細化 段階的詳細化 - Strategic Choice
  • 構造化プログラミング – 凝集度 凝集度 - Strategic Choice
  • 構造化プログラミング – 結合度 結合度 - Strategic Choice

「構造化プログラミング」時代と呼ばれ、 機能分解（functional decomposition）の手法がとられていました。

• 問題を小さな機能にブレークダウンしていき、複雑さを回避しようとするアプローチで す。
• 図にするとピラミッドストラクチャのようになります。
• ブレークダウンされるごとに凝集度は高まり、見通しも良くなるので自然と複雑度は下がります。

しかし、ここには落とし穴がありました。

• このアプローチでは、結果的に「メイン」モジュールが必要となります。

  機能の組合わせとその呼び出し順を正し く制御する、大きな責任を持ったモジュールです。

• こういった構造になっていると、モジュールの変更が制御できなくなります。

  「他の関数」「データ」「やり取り」「順番」等、注意を払うべき項目が多 すぎるからです。

• 機能やデータを変更すると、他の機能や他のデータに影響が及び、それがま た他の機能に影響を及ぼすという修正の連鎖が「芋蔓式」に発生し、「将棋 倒し」が起こります。

• その中でも特に影響が大きいのが「データ」の変更についてで、

  データが機能に従属して拡散してしまっているため（方々で使っているだけ でなく、引数による上下渡り歩きも含む）、影響範囲の見極めが非常に困難 になります。

この時代、多くのバグが、変更によって生み出されていました。

• 変更による不具合のことを「好ましくない副作用」といいます。
• 機能に注力することは、発見しにくい副作用を生み出す近道になってしまう のです。
• そして保守作業とデバッグ作業にかかる時間の大半は、バグの除去に充てら れる時間ではなく、バグの発見、および修正によって生み出された好ましく ない副作用の回避手段を考え出す時間に充てられていました。

つまり、機能分解は、ソフトウェアライフサイクルに常備されている「変更」 というイベントにおいて、例えばバグ修正時であれば二次バグ、機能追加時で あればデグレードの発生など、常に危険に晒されている手法だということです。

そして、本来使うべき開発そのものの時間ではなく、この副作用の収束に多く の時間を取られるという形で問題が顕在化したのです。

変更は必ず発生するものです。

どう変わるかはわかりませんが、どこが変わりそうかはある程度予想できるの です。

そこでオブジェクト指向が登場します。

書籍「オブジェクト指向入門」の中でトップダウン機能分解の弊害に言及して います。

オブジェクト指向でないアプローチでは何の抵抗もされずに、機能がデー タを支配するが、その後データが「復讐」を始めた。復讐はサボタージュ の形で現れた。アーキテクチャの基礎そのものを攻撃することによって、 データはシステムを変更に耐えられないようにした。

トップダウンの機能階層図は一見きれいですが、実はごちゃ混ぜのデータ転送 が含まれており、変更時は管理不能に陥ってしまいます。

変更して、その変更が原因で、元の機能に不具合が発生してしまうのがデグレー ドです。このデグレードが発生した時、私は「もう少し気をつけて修正すれば」 とか「もっと慎重に修正すればよかった」と反省してしまいます。しかし、そ もそもの根本原因は、修正方法よりもその設計にあることが多いという実感が あります。

そこに気が付いて、「割れ窓理論」（＠書籍「達人プログラマー」）に陥らな いよう、変更に強い設計に改善していかなければなりません。

そのためのオブジェクト指向だと思っています。

• オブジェクトとはデータ＋操作である。
• カプセル化とはデータの隠蔽である。
• 継承は特殊化と再利用の手段である。

これらはもっともらしく見えますが、本質ではありません。

((s-:)) 実装寄りの見方なんですね。

正しい理解は以下になります。

• オブジェクトとは責務である。
• カプセル化とは流動的要素の隠蔽である。
• 継承はオブジェクトを分類する手段である。

((s-:)) 概念・仕様レベルの見方ですね。

• 調査対象領域における概念を表現。
• 実装とは関係なく導き出される。
• 「私は何に対して責任があるのか？」

• ソフトウェアを考慮。
• 実装ではなく、インターフェイスの考慮 。
• 「私はどのように使用されるのか？」

• ソースコード自体を考慮。
• 上の2つを考えた後。
• 「私はどのように自身の責任を全うするのか？」

この観点の使い分けが非常に重要

• 概念レベルでコミュニケーションを取とると、お互いの詳細は知らなくて良 いことになります。
• 設計はまずここで考えることになります。すなわちソフトウェア以下は考慮 しません。
• すると設計アウトプットにおいて、使用者に概念をそのままにして実装を変 更できるため、結果的に使用者に対して（発生しやすい変更である）実装変 更から守ることになります。

ソフトウェア開発プロセスの観点とオブジェクト指向設計がよくマッチするから。 以下にオブジェクトと観点のマッピングを示す:

オブジェクト指向では、機能に分解するのではなく、 オブジェクト に分解 します。

オブジェクトとは「データ＋操作」ではありません。

• 決して「賢いデータ」程度の物ではないのです。
• これは実装の観点からしか見ていない, 狭いものの見 方です。

それではオブジェクトとは何か。

• オブジェクトとは 責任 です。責務を備えた実体です。
• それは 概念レベル, 仕様レベル から考察した結果導き出されるもので す。実装レベルを混ぜてはいけません。
• オブジェクトがどう実装されるか ではなく オブジェクトが何を実行するのか に着目しなければならないのです。

オブジェクト指向に沿ったソフトウェア開発の手順はこうなります。

1. 詳細をすべて考慮することなく、予備的な設計を行う
2. その設計を実装する

つまり、

1. まず概念レベル（＝責任）で考えることになります。

2. そして、責任を果たすために、他のオブジェクトが使用するためのインター フェイスを考えます。

   これを 公開インターフェイス といいます。

   実装をそのインターフェイスの背後に隠蔽することで、実装とそれを使用 するオブジェクトを分離しているのです。

実装レベルで考えているだけだと、結局機能分解の時と同じ問題が発生します。

• つまり、変更から守られないということです。
• 差分プログラミング的な、誤解されたオブジェクト指向もこの範疇に入ります。

一方、概念レベルでコミュニケーションをはかり、別のレベルで（実装）要求 を遂行する、という風に分けて考えると、

• リクエストする側は何が起こるかの概略だけ知っていればよいことになります。
• つまり、その概略（責任・インターフェイス）をそのままに、実装詳細の変 更から、リクエスト側を守ることができるということです。

オブジェクトの共通する作業やデータを クラス に持たせる。 クラスは以下の要素を含む:

• オブジェクトが保持するデータ項目
• オブジェクトが実行出来るメソッド
• データ項目やメソッドにアクセスするための方法

抽象データ型の一つの表現方法がクラス， 抽象データ型は以下の特徴をもつ:

• 型定義を公開できること。
  • プログラマがデータ型を定義。
• インスタンスに対する操作が利用出来ること。
  • 「do(data)」ではなく「data.do()」。
• 内部のデータを保護し、上記の操作のみがアクセス出来ること。
  • 情報隠蔽。
• 複数のインスタンスを作れること。
  • マルチプルインスタンス。

ある型のグループを包含するような汎用の型が必要性となる

• 汎用の型が 抽象クラス*（ *基底クラス ）と呼び，
• それを継承している型を 具象クラス と呼ぶ。

抽象クラスは、それが表現している概念を具体化したクラスの実装を まとめることができる。

つまり、継承は オブジェクトの分類 に使用する：

• 抽象クラスによって関連のあるクラス群に名前を割り当てる方法が与えられ、
• 関連のあるクラス群を１つの概念として扱えるようになる

「継承は特殊化と再利用の手段である」というのは本質ではない。

• 問題が起こる例

  図形で5角形を表現するPentagonクラスがあるとします。

  継承を使って「縁」機能を持つPentagonBorderを作成します。

• 以下のような不具合が発生します:
  • 凝集度が低下する可能性がある
    • Pentagonの責任にBorderは関係ない。
  • 再利用の可能性が低下する
    • 縁機能ロジックが他の図形で再利用出来ない。
  • 変化に追随できない
    • 違った観点の変更に対応出来ない。
    • 次に「網掛け」機能が必要になったら、クラスの組合わせが爆発してくる。

• 継承はかつて実装的側面で語られることが多かったといいます。いわ ゆる「差分プログラミング」と称して推奨された 特化の継承 にはこのような問 題点もあったわけです。

継承に関する多くの問題を起すキーは 責任 という概念だと思います。

• オブジェクトは「責任」であり、
• さらに責任とは「責任をもった者同士の委譲である」といいます。
• 継承は同じ責任内で働くため、委譲をうまく取り扱えません。

カプセル化は、オブジェクトが自らのことに対して責任を持ち、必要のない物 は見せない、という事です。

カプセル化はあらゆる種類の隠蔽を意味しています。例えば以下のようなこと も含んでいます:

• 派生クラス
  • ポリモーフィズムにより、実際の具象クラスを知らなくても良い。
  • 「型のカプセル化」（抽象が具象を隠してる）といえる。
• 実装
  • 実装する側は、インターフェイスが決まっているので、呼び出し側 を気にしないで変更出来る。
  • 「メソッド（実装）のカプセル化」（メソッドの実装を隠せる）といえる。
• 設計の詳細
  • 使用する方から、その詳細を気にしなくても良いようにする。
  • 「メソッド（使用）のカプセル化」（メソッドの実装を気にしない） といえる。
• 実体化の規則
  • 別途実体化専門の役割がいて、使用する側は気にしなくても良い。
  • 「生成のカプセル化」といえる。
• サービス
  • アダプタオブジェクトの背後の何かを隠し、実際に動作しているサー ビスクラスを使用する側は気にしなくて良い。
  • 「オブジェクトのカプセル化」といえる。

オブジェクト指向技術を使うとき重要なのは「変更に強いソフトウェアを作る」 という目的意識です。

「変更に強いソフトウェアを作る」には、流動的要素をカプセル化します。

そこ以外の部分を再利用することができます。

• 分析・設計時は責任を考えながらオブジェクトを考え、
• ソースコードではそれがクラスになり、
• 実行時にはそのクラスのインスタンスとなります。
• クラスのインスタンスはオブジェクトとも言いますので、ややこしいです。

継承はパワフルで、その種類も豊富です:

• 「オブジェクト指向プログラミング入門」では「継承の形態（7.3）」で8種 類の継承が、
• 「オブジェクト指向入門」では「継承の使用（24.5）」で12カテゴリの正し い継承の使い方が紹介されています。

今の私は、様々な情報から

• 「継承のようなクラス間の静的な関係より、オブジェクト間の動的で柔軟な 関係の方がよい」
• 「役割を継承でつくるとクラスが爆発する」
• 「多重継承なんて○○○」など「継承＜委譲」と洗脳されています

が、継承もしっかり理解して使えば、思っている以上に強力な武器なのか もしれません。

データ項目をオブジェクト毎に保持し、メソッドは共通に使用できる仕組みは マルチプルインスタンスが実現しています。

クラスを抽出していく方法。

• 問題領域の「どこ」が流動要素となるのかを識別し（共通性）、

• その後、それらが「どのように」変化するかを識別します（可変性）。

  それには

• まず「ファミリ構成員」を探します。

  これが共通性です。

• そして次に構成員がどのように違っているかを明らかにします。

  これが可変性です。可変性は共通性のコンテキストの中でのみ意味を持ちま す。

つまり、

• 問題領域中の特定部分に流動的要素がある場合、
  • 共通性分析によってそれらをまとめる概念が定義できることになり、
  • これが抽象クラスです。

この後、

• 可変性分析によって洗い出された流動的要素が

  具象クラスです。

「共通性/可変性分析」は

• 「ソフトウェア開発の観点」と
• 「クラス階層」にあてはめることができます。

オブジェクト指向黎明期、要求仕様の文章から「動詞」と「名詞」を抽出し、 それを元にクラスを設計していた。

• これは要求仕様に（＝現実世界に）全てのクラスが埋まっているわけではな いので、当然うまくいかないことになります。

  ((s-:)) 完全ではないけれど，とっかかりには最適な方法だと，僕は思って いる。

• 要求仕様に完全網羅性は期待できませんし、自然言語で書かれていて、かつ その書式で変更されていくものなので、これを基に設計をするのは労多くし て功少なしです。

  ((s-:)) では何を基に？

「オブジェクト指向入門」での抽象クラスを見つける方法についての言及:

抽象を見つける方法は、知的発見（いわゆるユリイカ、そのための確実な 方法は存在しない）の過程で見いだすか、あるいは誰かがすでに解決策 を見つけている場合には、その人の抽象を再利用するかである。

より確実である後者は、まさにデザインパターンのことを言っているのでは ないでしょうか。

複雑さに勝ち、かつ 変更に勝つ ことです。

• 変更を考慮する設計アプローチがオブジェクト指向の本質です。

変更を考慮する:

• 変更「内容」を正確に予測しようとせず，
• 「どこに」変更が発生するかを予測する
• その変更地点が 流動的要素
• 流動的要素 を考慮した設計アプローチ

具体的なアプローチ法は、GoF本で紹介されている以下の原則:

• 実装を用いてプログラミングするのではなく、
• インターフェイスを用いてプログラミングしてください。
• クラスの継承よりもオブジェクトの集約を多用してください。
• 何を流動要素とするべきかを考察してください。

このようにデザインパターンの原則がオブジェクト指向の本質に近しくなっ ています。

デザインパターンのテーマもやはり:

• 「設計変更を強いる可能性のある物」が何かを考えるのではなく
• 「再設計をせずに何を変更可能にするのか」を考えることです。
• デザインパターンはオブジェクト指向上達のショートカットと言っています。

オブジェクト指向のメリットをデザインパターンで釣り上げることができ るのです。

まさに邦題通り「オブジェクト指向のこころ」は「デザインパターンで学べ」 ということです。

• どのように（How）変わるかではなく、
• どこが（Where）変わるのかを特定し、
• 分離し、囲い込む

• 値と定数
• データ構造体
• 型と演算
• 変数と代入
• 文と流れ
• 関数（手続き)
  • 定義
  • 呼出し
• スコープ
• モジュール

• コードインタープリタ
• 環境
  • 実行の流れを保存するスタック
  • 名前を解決する束縛
  • 静的か動的か

• プログラムを生成するプログラムをつくること