[ruby-list:21320] Re: How does OOP excel?

石橋秀仁です。

> 原です。

> この例は、なかなか良いのでありがたく収納いたしました。（何処に？）

どうも(^^)
# でも「収納」って... (^^;;;

> ところで、
> 
>   構造化 : オブジェクト指向 = ツリー : ネットワーク
> 
> と大雑把に言ったとして、さて、それではなぜオブジェクト指向プログラミング
> は理解しやすく書きやすいのでしょうか。
> 
> だって、昔の BASIC なんか、「スパティー・プログラミング」とか言って
> まさにネットーワークそのものだったんじゃないですか？

では、設計手法をおおまかに、
 (1) 手続き指向 (PO)   (2) オブジェクト指向 (OO)
と分けてみます。BASICもモジュール分割も(1)になります。

それぞれの手法の「着眼点」と「設計の成果物」は、
 (1) 手続き、処理、処理の流れ    --> フローチャートなど
 (2) データ、オブジェクトの協調  --> 静的構造図 (クラス図)、協調図など
ですよね。

さて、それぞれの「ネットワーク」の「頂点」にあたる構成要素
(単位要素)が何なのか、が重要です。フローチャートでは「処理」です。
クラス図では「クラス」、協調図では「オブジェクト」で、どちらも
「データ」です。

フローチャートは処理の流れを与えます。しかし、そのステップごとに
どのデータがどのように変化するのか、調べるのは大変ですね。
人間デバッガと言ってもいいでしょう。

これがフローチャートの問題です。フローチャートが表すのは処理の流れです。
しかし、検証はデータに対して行なっています。処理とデータが結びついて
いません。最も大事な、データの扱いがお粗末になっています。

いっぽう、オブジェクト指向分析設計はデータに注目することを徹底した
手法です。メッセージシーケンス図はフローチャートのような図なのですが、
かならずオブジェクトの「協調」に注目しています。

また、まえに「計算の進行はメッセージ渡し」と書きました。この
「メッセージ渡し」は「(レシーバ)オブジェクトの状態変化」と不可分です。
"a = Person.new('bob'); a.get_sick"と書けば、`a'の状態が変わります。
# メソッドには`this'や`self'という概念がありますよね(*1)。

# (*1)
# その意味で、"String#sub"と"String#sub!"は、オブジェクト指向的には
# "sub!"の動作のほうが自然だと思います (subは毎回dupするから)。
# "!"という余計なものが付いているので、「フツーは"sub"を使うんだな」
# と感じますが、それは意図されたものでしょうね。Stringはプリミティブな
# 型ですし、コードの美的感覚の問題でもあります。「気持よく書く」が
# ポリシーのRubyならではの仕様だと思います。


では結論を。オブジェクト指向の「ネットワーク」が、フローチャートの
「スパゲッティ」よりも理解しやすい(*1)のは次の理由によると思います。

# (*1)
# 構成要素の数が同じなら、機械にとっては五十歩百歩かな 
# (テストケースとか)。「人間にとっては理解しやすい」という意味です。

 (a) クラスは問題領域中の概念を表わす (例：医療アプリの"Karte")
     だから単位要素 (クラスやオブジェクトやメッセージ)の意味が明確である。

 (b) 計算の進行とオブジェクトの状態変化が不可分である
     (例："karte.stolen"で"karte.@owner"が変更されるのが明白)。
     そのために、オブジェクトの状態の設定／参照用メソッドがあるはず。

ただし、上の(a)と(b)は相互に補完するものです。どちらかを壊すような
コードはかんたんに書けるでしょう(*2)。そういう状態を、ぼくたちは、

  「オブジェクト指向していないJavaのコード」

とか呼んでいるように思います(なぜかRubyではない:-)。

# (*2)
# 人間どうしの「約束事」ですから。だからこそ、「人間にとっては
# 理解しやすい」としました。UMLもコードを自動生成するのが目的ではなく、
# エンジニアどうしのコミュニケーションのツールだといいます。また、
# 
# From: Matsuo Hisanori <[e-mail]>
# Subject: [ruby-list:21286] Re: 引数コピーとオブジェクト指向
# Date: Fri, 10 Mar 2000 12:48:26 +0900
# Message-ID: <[e-mail]>
# 
# > 多分荻野さんは「こういうコードも許すようにPersonを実装」すべきではない
# > のか? と思っておられるのでしょう。でも違うんです。ちゃんと分析が出来て
# > いて、スキルの高い開発者間で意思統一が出来ていれば、そういうことは全く
# > 必要がなくなってくるのです。
# 
# には大納得できます。

# 以下は余談：

# ソフトウェア工学の最重要課題は、構成要素数における「マジックナンバー」
# の達成だと思います。「マジックナンバー」というのは、「人間が一度に
# 把握できる項目の数」で、定説では「７±２」です。
## どんな図でも、ぱっと見て、要素が7つ程度なら、すんなりわかるよね？
# そのための手法として、分割統治という階層化や分散化によって、複雑度を
# 軽減するのが、あらゆるソフトウェア工学の手法に通じる考え方だと思います。

# 「メッセージ渡し」と「オブジェクトの状態変化」について：
# シーケンス図を使うと、「処理の流れ」に偏る悪癖が出てしまいそう。
# その意味では、同じ相互作用図にしても、シーケンス図より
# コラボレーション図のほうが気が楽かも。

# もっとぶっとんだ発言：
# 「関数型」と「オブジェクト指向」って方向性が逆ですよね。
# 関数は、「それが、いつ、何回目に呼ばれても、同じ結果を返す」。
# いっぽうで、「オブジェクト」＝「データ」＝「内部状態」ですから。
# 「純粋な関数型の、オブジェクト指向言語」ってあるのでしょうか？
# てゆうか意味があるのでしょうか？

--
Hideto "rubyholic" ISHIBASHI