オブジェクト指向が苦手コミュのOOPの理解度を図る10の質問

お邪魔します。こういうのはやはり出自に立ち戻るのが肝要かと。

想定している“オブジェクト指向”がケイのであるのならば、「メッセージング」への理解度をはかるべきでしょう。

ストラウストラップのオブジェクト指向ならば、「継承」です（「多態性」ももれなく付いてきます）。もちろんこの背景として、俗に「カプセル化」と呼ばれる「抽象データ型」、つまり、プログラミング言語における「データ型」の役割と、それをユーザーの手により定義可能であることのメリットを知っていることが前提となります。ちなみに「継承」とは、この「抽象データ型」便利に行なうための言語機能に他なりません。換言すれば、（SIMULA の）クラスで（リスコフの）抽象データ型を実現したのが彼の定義したオブジェクト指向となります。ただ、クラスの継承でデータ型を表現するという考え方には、今や、多くの問題があることがすでに分かってきていますから、理解度をはかるという意味では、インターフェイスの継承機構というものに注意を払う（どうしてそうしたものが必要になるのかについての理解度もはかる）べきでしょう。

クックのオブジェクト指向ならば、そのキーコンセプトは「手続きによる抽象化」です。もちろん、ストラウストラップ同様、しかし、この場合は対極の「データ型による抽象化」を理解している上で成り立つ話、ということになります。

くどくど書きましたが、誰が提唱する「オブジェクト指向」かをきちんと定めた上での話でないと、“理解度”というものもなかなか見積もりにくいのではないかな…と思いましたので、老婆心ながら。

手前味噌で恐縮ですが、上述のことに関してはこちらを参考まで。
http://d.hatena.ne.jp/sumim/20040525/p1

はじめまして。興味がありましたので回答させて頂きます。

1) オブジェクトとは？
・何かの「概念」に基づき纏められたもの。
・必要な情報と操作だけを、外に公開し極力モジュール強度を高めるよう設計されたもの。

2) 以下の言葉を説明して下さい
クラス/継承/カプセル化/委譲/多相性(ポリモルフィズム)
・クラス…上記のオブジェクトの元となる設計図。メタ情報。
・継承…指定したクラスの特定のアクセシビリティーの機能を静的に引き継ぐ機能。
・カプセル化…外に公開する必要のない機能は公開しないで外に公開する必要のある機能を公開するようクラス設計する事。
・委譲…使いたい機能を持つクラスを継承しないで、そのクラスのインスタンスを内包し、インスタンスごしで機能を使用する。継承を使用するより柔軟。
・多相性…ひとつのオブジェクトがさまざまなものになる。正確には、ひとつのオブジェクトをさまざまなものに見立てる。　といった感じでしょうか？機能は同じなんですが、色んな型を持たせます。

3) 名前ってどのくらい大切だと思う？
オブジェクト指向を勉強するより大事な事だと思います。

4) 1+2 オブジェクト指向的に読むと？
わかりません。

5) 1+2*3 の戻り値が 9 、コレってバグ？それはなぜ？
7では…。

6) デザインパターンを使ったことがある？それはなに？
場合により使います。
・Builder…オブジェクトの生成パターンが複雑でなくても使う事があります。エンティティクラスとその生成処理は分けたいし、必要な値を全てコンストラクタで受けたくない場合もありますから。
・AbstractFactory…同じようなインタフェースで処理の中身が違うクラスを沢山作った時に、使用する側に全て「AbstractClass hoge = new ConcreteClassA();」とやってもらうのは悪いです…。「AbstractClass hoge = AbstractClass.createInstance(type);」
という感じに。
・TemplateMethod…処理フローを変えず、処理の中身を入れ替えるのに便利ですから…。
・Singleton…アクセサ内で、インスタンス変数がnullの場合のみnewするようにします。無駄にnewしたくないですから…。
・Strategy…業務アプリでは、処理内容だけ挿げ替えたい時がよくあるので重宝しています。

他にも場合によって適用を検討しますが、Prototype、Iteratorはあまり使う事がない気がします。自分で作るというよりは既に言語に使われていて、こちらはその機能を使う側の方が多いような気がします。

7) UMLって読み書きできる？
仕事で成果物に含まれているので、書かざるを得ません…。

8) OOPLに最低限必要な機能ってなに？
Prototype(createClone)は必要です。継承はあまり必要でもないのかも。後、マーカーインタフェースに変わる考え方が必要ですね。

長くなってしまった…＾＾；こういう質問＆回答はなかなか楽しいかもしれないですね。

どもです。

> 鷲見さん

「オブジェクト指向とは何か？」の問いに対し、実は３つの切り口が存在していたとはぜんぜん知りませんでした。勉強になりました。

・メッセージ指向
・クラス指向
・手続きによる抽象化手法

これらを加味すると、私の感覚では「情報隠蔽＋カプセル化」が、最適な回答ではないかと考えています。
（あくまで個人的主観です）

（個人的主観は置いといて）j's_7さんの質問に対し、回答内容が上記３つの観点かどうかを確認すると、理解度の確認がより確かになるのではないでしょうか。

さまざまなご意見ご回答有難う御座います。

>たけぷ〜さん
初めまして。
「オブジェクト指向とはなんですか？」っていう質問はそのものズバリですね。
私はこの質問の存在をすかっり忘れてました…^^;
因みに私が回答するとしたら

　「もの」(とその振る舞い)を中心に据え、物事を捉える考え方

って感じですね。
この回答で合格点を頂けるでしょうか。。。

>とおる。さん
カプセル化がオブジェクト指向だけのものじゃないというのはその通りですね。
ですが私個人の意見としてはたけぷ〜さんの示した良くある回答例の回答では不十分だと感じます。確かに前後の文脈の捉え方では必要十分な回答になるものもあると思いますが、たけぷ〜さんはOOの基本を知っているかを確認する為にこの質問をされているようなので前後の文脈で質問の捉え方が変わるというのはほぼ起きないのではないでしょうか。となれば、やはりその他の回答はイマイチのように思えます。

>鷲見さん
おっしゃる通りです。

2)の質問はストラウストラップのオブジェクト指向なのに対して、4),5)の質問はケイのオブジェクト指向の話ですね。5)の質問に至ってはまんまSmalltalkの話ですし。
出展の違う二つのオブジェクト指向に関する質問が入り混じってる時点で私の理解度が稚拙なのがバレバレですね。^^;

とはいえ、自分は4)の式のオブジェクト指向(メッセージ指向)的な読み方が理解できた時、5)の式の戻り値が9になる理由に賛同できた時にオブジェクト指向の壁を一つ乗り越えた(気がする)んで、個人的には好きな質問だったりします。まぁ、その壁を越えた先にはさらにデカイ壁があったんですけど。(^^;

自分はクックのオブジェクト指向に関しては内容を殆ど知りませんのでなんとも言えません。なので、ここで取り扱う質問の対象は

　ストラウストラップ(クラス指向)のOOP理解度を図る

とさせて頂きます。
#やっぱりオブジェクト指向は難しいですね。
#早速勉強させて頂きます。

最後に一つ質問をさせて頂きたいのですが「インターフェイスの継承機構」といった場合のインターフェイスとはJavaのインタフェースを指しているという認識でよろしいでしょうか？

>はやそどんさん
わざわざ回答して頂き有難う御座います。
楽しいって言って頂けるととても嬉しいです。回答するのが楽しいような質問を考えられたら一番良いですよね。でも、きっとオブジェクト指向が好きでない人にはただの苦痛になるんだろうなぁ…とも思います。

しかもこの質問って絶対的な理解度を図れるわけじゃないんですよね。^^;

>おっちゃんさん
私も「オブジェクト指向とは」という問の明確な答えは持ってません。^^;
現状の私の理解はこうですとしかいえないです。
#その内容は上でたけぷ〜さんのレスに書いたとおりです

そんな中最近「何が出来ればオブジェクト指向と呼べるのか」ってのに興味があります。
コレって突き詰めたら「オブジェクト指向とは」と同じ質問ですよね。
#因みに8)の質問はコレに関する質問です
で、自分が今考えてる最低限必要な機能というのは

　インスタンスを(複数)作成できる

と言うものです。
そこにはクラスも継承もカプセル化も何も出てきません。インスタンス(オブジェクト)を作ることができればソレはOOPであるという考え方です。
この認識ってあってるんですかね？とても不安です。。。

>たけぷ〜さん
私は回答者がこれら三つの観点を理解している時点で既にOOPを実用レベルで理解していると言ってもいいのでは？という気がします。^^;
でも、その前に質問を作った人がどの観点に立っていたのかをはっきりさせないといけない気がするのでそれぞれがどの観点から見たものか書き出します。
#私の理解度は底が知れてますので間違いがあればご指摘下さい

凡例：
　【-】全てに属す，【*】判別不能
　【C】クラス指向，【M】メッセージ指向，【F】手続きによる抽象化手法

　1)【-】オブジェクトとは？
　2)【C】以下の言葉を説明して下さい
　　　　　クラス/継承/カプセル化/委譲/多相性(ポリモルフィズム)
　3)【-】名前ってどのくらい大切だと思う？
　4)【M】1+2 オブジェクト指向的に読むと？
　5)【M】1+2*3 の戻り値が 9 、コレってバグ？それはなぜ？
　6)【C】デザインパターンを使ったことがある？それはなに？
　7)【C】UMLって読み書きできる？
　8)【-】OOPLに最低限必要な機能ってなに？
　
といった感じでしょうか。
4),5)の元ネタはメッセージ指向のOOPですが個人的にはこの考え方はクラス指向でも十分に役立つと思っています。
#4)はJavaでは間違いになってしまいますが，Rubyでは正解ですしね
また、8)の質問は回答の内容によって回答者がどのオブジェクト指向に拠っているのか判断できるのでは？と思います。そういった意味では私はクラス指向のOOPに拠っているということになりますね。

因みに、未採用質問の方はこんな感じです。

　・【C】適切でない継承関係はどれ？それはなぜ？
　　　　<略>
　・【C】if〜elseとかswithとかどのくらい使う？
　・【*】selfとthisどっちが好き？
　　※selfが好きな人はOOPを理解してるはず!!という私の偏見なので…^^;

以上、長文失礼致しました。

たけぷ〜さん、どもです。

分析・設計の話になると、またややこしいのですが、こと、OOP に限っては、その特徴（あるいはその本質として語られがちなことら）は、この３つのどれか（あるいは文脈を異にして複数）の要素として登場するものと、個人的な認識でおります。

これらが分かった気になってくると、かなり大御所の書いたりっぱな教科書的記述でも、ああ、これはケイのからの抜粋だな…、こっちはストラウストラップ…、めちゃくちゃじゃん！と色分けができて、昨今のオブジェクト指向についての混乱を鑑みた上でのたいへん興味深い考察が可能になるような気がしています。


j's_7 さん、

念のため。ケイのオブジェクト指向（メッセージング）は、メンタルモデルの範疇に属するものなので、いろいろなものの解釈に使えます。たとえば、C++ や Java などのドット演算子の第一オペランドと第二オペランドを、それぞれ、レシーバと、それに送信するメッセージと解釈することも可能でしょうし、例題で提示されている二項演算子についても同じですよね。

ただ、こと、ストラウストラップのオブジェクト指向に限っていうならば、それに対する理解度をはかるうえで注意すべきは、本来、その本質（たけぷ〜さんの言及されている「カプセル化＋情報隠蔽」、換言すれば「クラスによるユーザー型の定義」）とは無縁な「メッセージ送信」という概念を“あえて”持ち込んでいるんだ…という意識をきちんと持てるかどうかではないかとも考えます。


＞インターフェイスとはJavaのインタフェースを指しているという認識

そうです。言語機能としてのインターフェースです。「データ型」や「型安全性」という概念に頓着しないケイのオブジェクト指向寄りの人には、なぜこんなものが存在しなければならないのか、いまひとつ合点がいかない場合も多いのではないでしょうか。この点も理解度をはかる上でもキーとなるチェックポイントかな、と。

>鷲見さん
いや、ホント勉強になります。

自分はオブジェクト指向を最初に理解した(と思った)のがSmalltalkでしたので、Javaの第二オペランドがメソッドと呼ばれるのに凄い違和感を覚えた記憶があります。なんでメッセージじゃないんだ!!…と。^^;
#今考えれば出展が異なるんだから当然のことだったんですね

例題で挙げている二項演算子もまさにその通りですね。
一見してプリミティブに見える数字やオペランドも実は全部オブジェクトとメッセージであり、メッセージがやり取りされることで計算式が実行される…と。コレに気づいた瞬間は友達と研究室で大騒ぎでした。(笑)
ただJavaでは事実プリミティブな計算なんですよね。まぁ、ソレがJavaの強みの一つであり嫌な部分でもあるんですが。

この例題に関して「メッセージ送信」という概念を“あえて”持ち込んでいるんだ…という意識を持つことは確かに重要ですね。でなければ、私のようにクラス指向とメッセージ指向をごちゃ混ぜに理解した人を生み出しかねませんね。^^;

インターフェースの存在理由は確かに理解度を図る良い基準になりそうですね。私はなんだかんだでJavaが最も親しい言語なのでインターフェースがなきゃやってられんって考えちゃいますが。

ということで、今までの話の流れで私のオブジェクト指向理解度を分析するとこんな感じですかね。

　クラス指向の考えををベースとし、
　部分的に"強く"メッセージ指向の影響を受けており、
　且つ各出展の違いを明確に区別出来ていない。
　クラス指向OOPの本質はまだ理解できておらず、
　各出展に関する知識と理解も浅い。

ズタボロですね。。。
でも今後の課題が明確になったので気分はすっきりって感じです。

追記：
何気にOOPの理解度を図る質問のとして以下の質問も有効なのでは、と感じました。^^;

　・OOPの理解度を図る為の質問を10項目挙げて下さい
　　⇒ 対象者が何を重要視し、どの系統のOOPに寄っているか
　　　 の判断材料となる
　・上記で挙げた質問に貴方なりの回答をして下さい
　　⇒ 上記の前提の上で対象者がどのレベルに達しているか
　　　 の判断材料となる

本当にそんなに上手くまわるんかいな？

> j's_7さん
>
> 「もの」(とその振る舞い)を中心に据え、物事を捉える考え方
>
> って感じですね。
> この回答で合格点を頂けるでしょうか。。。

ええと、自分自身オブジェクト指向を完璧に把握しているわけでは無いので、合格／不合格を語るなんて、おこがましいと思ってます。(^^;)

事実、鷲見さんが紹介下さった「メッセージ指向／クラス指向／手続きによる抽象化手法」すら知りませんでしたし。（滝汗）

> でも、その前に質問を作った人がどの観点に立っていたのかを
> はっきりさせないといけない気がするのでそれぞれがどの観点
> から見たものか書き出します。

カテゴリ分けについては申し分無いと思います。ですが、「実用レベル」かどうかはやはりプログラムを書いて頂いた方が良いかと思います。

書籍／参考書レベルで上述の知識を身につけていたとしても、プログラムを書けるか書けないかは別問題だと思います。

あと、私はC++しか知りませんので、[self]については理解しておりません。(^^;)


> 鷲見さん

まとめると、

■OOP
　メッセージ指向／クラス指向／手続きによる抽象化手法
　の集合体

■クラス指向の本質
　カプセル化＋情報隠蔽（クラスによるユーザー型の定義）

といった感じなんですね。

「カプセル化＋情報隠蔽」とは、「オブジェクト指向とは何か？」より、「オブジェクトとは何か？」という問いに対する回答なんでね。

私は、「クラス指向の本質」こそが、ＯＯの本質であると信じてました。メッセージ指向／手続きによる抽象化は、クラス指向を実現するための手段であると考えておりました。

■クラス指向
　「カプセル化＋情報隠蔽」することで、オブジェクトが生まれる。

■メッセージ指向
　生まれたオブジェクト同士はメッセージによる通信で、情報交換を行う。

■手続きによる抽象化手法
　手続きをカプセルに閉じ込めることで、オブジェクト間の依存度を減らす。

こうして書いてみて整理すると、やはり上記３つの観点はそれぞれ独立したものの
ように感じられます。

今後は、「オブジェクト指向とは何か？」に対し、「クラス指向／メッセージ指向／手続きによる抽象化手法」の３つがセットになったものであると、考えを改めたいと思います。

j's_7 さん、恐縮です。

＞Javaの第二オペランドがメソッドと呼ばれるのに凄い違和感

Java は、がちがちのクラス指向に立脚した言語でありながら、メッセージ指向の Smalltalk の用語を使っていることに問題がありそうです。

＞ズタボロ

そんなことはないと思いますよ。すかさず、ご自身の理解について色分けをして、分析を試みておられるのには驚きました。


たけぷ〜さん、

＞「メッセージ指向／クラス指向／手続きによる抽象化手法」すら知りませんでした

いやぁ。これを知っている人は、そういないと思います。私は（自分でいうのもなんですが…）文献検索は比較的得意なほうだと思っているのですが、それでも調べるのに数万円の論文複製代を投入し、あしかけ２年くらいを費やしました(^_^;)。調べ終わったあとの感想として、みんな、定められた引用もろくすぽせずに、自由きままに「オブジェクト指向」を語り杉！っちゅうかんじでしょうか。ｗ


＞「カプセル化＋情報隠蔽」とは、「オブジェクト指向とは何か？」より、「オブジェクトとは何か？」という

老婆心ながら、念のため。“オブジェクト”指向とは言いますが、「クラス」はおろか「オブジェクト」にも、あまり重きをおかないほうがよいと思いますよ。もともと両者は、“オブジェクト指向”とはほとんど関係のない文脈で SIMULA という言語に備え付けられた言語機能です。ケイやストラウストラップは、それぞれ彼らの考える“オブジェクト指向”を言語にサポートさせるために、便利だからそれを借りているだけです。

実際、いずれのオブジェクト指向においても、クラスやオブジェクトには“オブジェクト指向”するのに、多かれ少なかれ不都合が指摘されています。より良いものがあれば、別の言語機能に取って代わられる可能性もあるかもしれません。もっとも、これだけ“オブジェクト指向”が気ままに語られている状況では、可能性としてはわずかではありましょうが…（でも皆無ではないはずです。事実、クラス指向でクラスの欠点を補うものとしてインターフェース、メッセージ指向では少々古いですがオブジェクトの代替えとしてアクターというものが登場しています）。

オブジェクト指向談義でよく見かける風景で、クラスやオブジェクトを分解したり、意味付けを行なおうとしても、たいてい失敗に終わるのが常なのは、これらがしょせん“借り物”だから…だと考えています。

大切なのは、ツールよりは概念。つまり、ストラウストラップが、なぜ、なんのために（SIMULA の）クラスを必要としたか？ということだと思います。そういう切り口では、たけぷ〜さんの「カプセル化＋情報隠蔽」はクラスにより提供される機能を（すべてではありませんが）突いており、本質と思っておられてもよいのではないかなとも思います。


＞…の集合体

というよりは、最後で述べられているように、

＞それぞれ独立したもの

と考えていただいたほうが混乱が少ないと思います。少なくとも、ストラウストラップのと、ケイのについては、それぞれ、「オブジェクト指向」という名前、「クラス」や「オブジェクト」という言語機能こそ共有するものの、まったく別のものとして区別すべきでしょう。もし、ストラウストラップがクラス指向 and/or ケイがメッセージ指向という名前を付けて、区別が明確になるようにしてくれていたならば、今のような混乱はなかったように思います。

> 鷲見さん

ご意見／ご指摘／ご教授、ありがとうございます。

私の周りにオブジェクト指向erが居ないもので、いつも独りで孤独に考え、結論を出し、実践してみる・・・。そんな寂しい状況なのです。ですから、ご意見／ご指摘頂けると、非常に嬉しいです。

> 老婆心ながら、念のため。“オブジェクト”指向とは言います
> が、「クラス」はおろか「オブジェクト」にも、あまり重きを
> おかないほうがよいと思いますよ。

ご指摘ありがとうございます。
これらの言葉に重きを置こうとしていたのは、何を隠そう「オブジェクト指向」という概念を、皆さんに上手に伝えるために、シンプルなキーワードに置き換えようと考えているからです。

> 大切なのは、ツールよりは概念。つまり、ストラウストラッ
> プが、なぜ、なんのために（SIMULA の）クラスを必要とした
> か？ということだと思います。
> そういう切り口では、たけぷ〜さんの「カプセル化+情報隠蔽」
> はクラスにより提供される機能を（すべてではありませんが）
> 突いており、本質と思っておられてもよいのではないかなとも
> 思います

そのお言葉、心に刻みました。

> 少なくとも、ストラウストラップのと、ケイのについては、
> それぞれ、「オブジェクト指向」という名前、「クラス」や
> 「オブジェクト」という言語機能こそ共有するものの、まった
> く別のものとして区別すべきでしょう。

ご指摘の件、自分の中では理解できたつもりです。

> もし、ストラウストラップがクラス指向 and/or ケイがメッセ
> ージ指向という名前を付けて、区別が明確になるようにしてく
> れていたならば、今のような混乱はなかったように思います。

そうですね、鷲見さんの書き込み内容を見て、私もそう思いました。

ＵＭＬの様に、オブジェクト指向標準化団体ができて、きちんと言葉の定義づけをしてくれれば、ここのコミュニティも存在しなかったかもしれませんね。(苦笑）

そうなって欲しいと願っております。

たけぷ〜さん、

> これらの言葉に重きを置こうとしていたのは、何を隠
> そう「オブジェクト指向」という概念を、皆さんに上
> 手に伝えるために、シンプルなキーワードに置き換え
> ようと考えているからです。

なるほど。最近、私は、そうした目的には、クラスやオブジェクトをキーワードに据えるのではなく、逆に、「オブジェクト指向を知りたければ、まず“オブジェクト”をいったん忘れよう…」というのを合い言葉のようなものにしてはどうかと考えています。ｗ


j's_7 さんが冒頭で提案されているような、そもそもこのトピックスの本題に立ち戻るならば（というか、余計な茶々入れで脱線させてしまってスミマセン(^_^;)）、ストラウストラップのオブジェクト指向、つまり、現在主流のオブジェクト指向プログラミングの理解度をはかる、もっともシンプルな設問を考えるとすれば、のっけから「オブジェクトとは何か？」というような哲学あるいは実装面から始めるのではなく…、

- プログラミング言語において、「データ型」とはなにかを説明しなさい。

ではないかな、と思うわけです。　まあ、これで終わらせるのは、いくらなんでも端折りすぎですが、オブジェクト指向言語に何をサポートさせようとしているかという意識が正しい方向を向いているかを知る上でも重要なポイントだと考えます。

もちろん、オブジェクト指向プログラミング自体を理解できているか、ということについては、これに付随するかたちで、

- データ型をユーザーが定義できることの意義を述べよ。（抽象データ型、すなわち、カプセル化とはなにか…）
- それについて「クラス」が貢献できるものは何か？　（ユーザー型の定義という、本質的な部分で）
- 型を定義するとき、あると便利な機構や機能は何か？　（差分プログラミングのためのクラス継承機構、情報隠蔽のためのアクセスコントロール機能…、etc）
- 型安全性とは何かを述べよ。　（静的型システムのメリット、デメリット。静的型言語における多重継承の必須性を説明できるか。望ましい継承関係について）
- クラス継承とサブタイピングの違いを型安全性の観点から整理せよ。（多態性の意味とメリット。クラス継承の役割と欠陥。インターフェイス継承の必要性）

などなど…、を問う必要はあるでしょう。その過程で、クラスやオブジェクトが自然に出てくるのがベターかな、とも。　なんだか、細かく詰めてゆくと、早々に破綻しそうな臭いがプンプンですが、とりあえずは“たたき台”として。

>たけぷ〜さん

>「実用レベル」かどうかはやはりプログラムを書いて頂いた方が
確かにその通りですね。
その人の実力を見る道具としてはソースコードに勝るものはないですからね。私にしても現状で身に着けているOOPの知識をすべて使いこなせているかと言えば、答えはNoですし。知っているだけで使いこなせないのではホント無意味ですね。
#未だに3日前に書いたコードを見て「何やってんだ俺？」って思うことがあります。^^;
#これが一ヶ月前のものになると、もう…。(T-T)

あぁ、もっと上手くオブジェクト指向設計できるようになりたい。

>鷲見さん

>そんなことはないと思いますよ。
そういって頂けると凄く救われます。

>- プログラミング言語において、「データ型」とはなにかを説明しなさい。
>- データ型をユーザーが定義できることの意義を述べよ。
>- それについて「クラス」が貢献できるものは何か？
>- 型を定義するとき、あると便利な機構や機能は何か？
>- 型安全性とは何かを述べよ。
>- クラス継承とサブタイピングの違いを型安全性の観点から整理せよ。
早速上記の質問について回答を考えてみました。
で、私はこれらの質問を「難しい」と感じました。まぁコレは単に私のOOPの理解度が鷲見さんのそれに遥かに劣っているということだけなんですけど。^^;
今回は質問の後ろに括弧付きで質問の意図が記載されていましたので私にも質問の意図を理解することが出来ましたけど、単純に質問のみを出された場合、いくつかの質問の意図を私には理解できなかったと思います。これはそのまま、これらの質問がOOPの理解度を図る上で有用だということの証明に他ならないと思うのですが…

　質問のレベルが高すぎて今の私には使いこなせません。(T-T)

質問を出した本人がその質問の意図を理解できていないんではお話にならないですからね。
#これらの質問で私のOOP理解度の稚拙さがさらに浮き彫りになりました。
#学ばなければならないことがいっぱいです。

ただ、最初の質問が「プログラミング言語において…」と始まっているので、回答者がこの質問の前提として「手続き型言語」を想定する危険性が少なからずあるように思いました。前提とする対象言語がオブジェクト指向言語でなければ当然回答も質問者の意図したものとは違ってくるのではないでしょうか？
また、これらの質問においては回答者がどの程度質問の意図を汲み取れるかということもOOPの理解度を図る基準としているように見受けられましたが、コレは逆に質問者の意図が伝わりにくい(回答者が何についてorどこまで答えるべきか分からない)という問題を内包していますので、実際に使用する際は注意が必要になると感じました。

j's_7 さん、

そうですか。難しすぎますか…。うーむ。シンプルにまとめたのが、逆に裏目に出ましたかねぇ…。


＞「手続き型言語」を想定する危険性

これは手続き型言語でもかまわないと思いますよ。データ型というのは OOPL に限らず、普遍的なものなので。　解答例としてはこんな感じです。

処理の対象である情報について、
- それが、いかなるものかを、内（計算機）、および、外（ユーザー）に対して、示し
- それが、どう扱われるべきかを規定する
もの。

…と申しましても、Philippe Jorrand の「Data types and extensible languages (1971)」の冒頭言のまんま、パクりですが(^_^;)。


で、繰り返しになりますが、OOP というのは、この「データ型」というものを、特に「クラス」という言語機能を用いて自由に定義する作業（と、それをサポートする言語、および、考え方）なのです…と続かせます。

>鷲見さん

>そうですか。難しすぎますか…
これは単に私の勉強不足なだけなので気になさらないで下さい。^^;

>これは手続き型言語でもかまわないと思いますよ。
>　<略>
>で、繰り返しになりますが、OOP というのは、この
>「データ型」というものを、特に「クラス」という
>言語機能を用いて自由に定義する作業（と、それを
>サポートする言語、および、考え方）なのです…と
>続かせます。
なるほど、納得です。

私が「手続き型言語」を想定する危険性があるといったのは、回答者がOOPについて十分な理解を持っていたとしても、上記の前提の上で回答した場合にOOPの内容について"あえて"触れないような場合があるのでは？と思ったからです。
ですが鷲見さんの説明を見てそれは杞憂だったかなと思いました。

余談ですがOOPの本質を理解できていない人は「OOPというのは、この「データ型」というものを…」の行で早々に脱落していきそうですね。
#かくいう私もその一人だったわけですが…^^;

j's_7 さん、

＞早々に脱落

そうですね。OOP と言われて「データ型」をまっさきに意識できるかどうかは、その理解度をはかるうえで、相当なキーになると思います。ただ、ケイのオブジェクト指向寄りのスタンスですと（本人がそうと意識できているか否かにかかわらず…）、OOP が「データ型」云々のくだりには、かなり抵抗を示されることが予想されます。そういう面倒くさいものから解放されて問題の記述（ひいては、解決）に集中できるのが、メッセージングというパラダイムの魅力のひとつなので…。

他方で、ストラウストラップのオブジェクト指向において、基本中の基本であるこのデータ型とは何か、ということについての知識が整理できていないがために、オブジェクト指向が難しい…と思っている人もまた、多く見受けられるようにも思います（実際、難しいのは、身近な「データ型」について改めて考えをまとめることのほうで、いったんそれができてしまえば、OOP それ自体はいたってシンプルで素直なものなんですが…）。

ケイのオブジェクト指向向けにも、その理解度をはかる質問を考えてみたいですね。私はどちらかというと、こちらのほうのシンパなので(^_^;)。

■おっちゃんさん

> できれば、説明をする際に説明が必要な技術用語は極力使わず
> もう少し抽象的な説明を心がけてくれると大変助かります。

ええと、私も論点が「OOPの理解度を図る10の質問」から離れてしまっている事に気がついていたのですが、書き込みが止まってしまうと思い、敢えて静観しておりました。(^^;)

ということで、現状の話題は別トピックを立てて頂き、話を元に戻しませんか？
> 皆様


■j's_7さん

個人的な質問で恐縮なのですが、j's_7さんご提案の質問に対する回答を教えて頂け
ませんでしょうか。

いやぁ。きっと、私の横槍が悪いのです。面目ない。(^_^;)

ただ、私には、どれも本論である「理解度をはかる」うえでは重要なことに思えて判断が付きかねますので、論点をはずしていると思われることは遠慮無く無視して（話を戻して）進めてください。

> 「そんな質問意味ないよ」とか「この質問が有用だ」ってご意見を頂ければ幸いです。

OOPの理解度って、どう使うものなのでしょう。
理解度は一次元のベクトルになりますか?

なんというか、言葉としてのそれを知っているのと、
それが身に付いていてコードに染み出てくるのとは
だいぶ違う気がします。

理解度の使い道がわかったら、なにかアイデアが出て
きそうな気がします。(出ないかもしれないけど)

>鷲見さん
私も個人的にはメッセージ指向のが好きだったりします。

>おっちゃんさん

>私はオブジェクト指向を単純に理解していた分、学問的な話で語られると
>「む じ ゅ か ち ー！ 」っとなってしまいました(笑）
確かに学問的に話をすると難しくなりますね。
事実、私も「難しい」と感じてますし…^^;

>　素人に理解できるように説明できないなら、
>　それは自分自身が真に理解していないに他ならない。
>　というのがあります。
これはそのとおりですね。
ただ私自身、真にOOPを理解してないので上手く説明は出来ないと思います。^^;

>たけぷ〜さん

>ということで、現状の話題は別トピックを立てて頂き、話を元に戻しませんか？
了解です。
ですが、個人的に現状の話題についての結論(=何を勉強すべきか)は出ているので、私には別トピックを立てるほどの理由がありません。
みなさんはどうでしょう？

>j's_7さんご提案の質問に対する回答を…
以下に私の回答例を書きます。
現時点での私の認識ということになりますのでコレが正しいという保証はどこにもありません。しかもこの回答はクラス指向とかメッセージ指向とか全く考慮してません。^^;

　1) オブジェクトとは？
　　　具体的な「もの」です。
　　　
　　　それは"鉛筆"のように形あるものかもしれないし、
　　　"命令"のように形のないものかもしれません。
　　　
　　　別の表現をすれば"固有名詞"又は"冠詞を伴った一般名詞"です。
　　　
　2) 以下の言葉を説明して下さい
　　　■クラス
　　　　・抽象化された「もの(=オブジェクト)」・分類
　　　　・オブジェクト指向を実現する為に導入された機能/概念
　　　　
　　　　別の表現をすれば「一般名詞」及び「それを表現する為の手段」です。
　　　　⇒例えば"国"という一般名詞はクラスに当たり、「その国」や
　　　　　「日本」などはオブジェクト(インスタンス)になります。
　　　
　　　■継承
　　　　・クラスをより具体的な(抽象度の低い)「もの」・分類に細分化(特化)すること
　　　　・必ずis-a関係やkind-of関係が成り立つ
　　　　　なお間違った細分化をすると(一見するとis-a関係が成り立っていても)
　　　　　問題となることがある。例えば以下の例
　　　　　
　　　　　人<-従業員 ： 従業員は人の特殊型ではなく、役割である
　　　　　人<-子供　 ： 子供はいずれ大人になる
　　　　
　　　　別の表現をすれば抽象的な一般名詞をより具体的な一般名詞に細分化する作業
　　　　⇒例えば「車」という一般名詞をより具体的な「トラック」や「乗用車」
　　　　　といった一般名詞に細分化する作業
　　　
　　　■カプセル化
　　　　・お互いに強く関連づいた「もの(=属性=データ)」や振る舞いを纏めて扱うこと
　　　　　なおカプセル化と情報隠蔽は全くの別物。

　　　　カプセル化したものに名前をつけるとそれがクラスになります。
　　　　※正確にはカプセル化を実現する為に導入されたのがクラス
　　　　
　　　■委譲
　　　　・自分が行う振る舞いの一部/全部をより適切な「もの」にお願いすること
　　　　・has-a関係が成り立つ
　　　
　　　■多相性(ポリモルフィズム)
　　　　・具体的なものをより抽象的な角度からみて、複数のものを区別無く扱うこと
　　　　
　　　　別の表現をすれば一般名詞をより抽象的な一般名詞でグループ化し、
　　　　同一のものとして扱うこと
　　　　⇒「トラック」や「乗用車」をより抽象的な「車」として区別無く扱う
　　　
　3) 名前ってどのくらい大切だと思う？
　　 一番大切だと言っても過言ではないくらい凄く大切。
　　 個人的に名前を疎かにする人はOOPを理解していないと感じます。

　4) 1+2 オブジェクト指向的に読むと？
　　 "1"という数値オブジェクトに"2"という数値オブジェクトを引数とした
　　 "+"(引数を加算せよ)というメッセージを送る
　
　5) 1+2*3 の戻り値が 9 、コレってバグ？それはなぜ？
　　 四則演算をただのメッセージとして特別扱いしないOOP処理系においてはバグとは
　　 ならない。また、上記の処理系においては通常メッセージは前から処理される為
　　 上記の式は以下のように処理されます
　　
　　 　1+2*3 ⇒ 1.add(2).times(3) ⇒ 3.times(3) ⇒ 9
　　 　※数値は全てオブジェクト
　
　6) デザインパターンを使ったことがある？それはなに？
　　 あります。
　　 Composite,Facade,Mediator,Singleton,Strategy,Template Method,Visitor等
　　 Iteratorとかは自分で実装することはかなり稀です。
　　 珍しいところではInterpreterパターンとかも使ったことあります。

　　 個人的な考えとしてはデザインパターンは何があるのか(名前と利点/欠点)が
　　 分かっていれば十分だと思ってます。(実装詳細は調べなおせば良い)
　　 で、どちらかと言うとコミュニケーションツールとしての役割が大きいかなぁ
　　 とも思ってます。
　　
　7) UMLって読み書きできる？
　　 一応出来ますが数種類だけです。
　　 上流の設計工程で使われるUML図程読み書きできません。
　　 個人的に良く使っているのはクラス図だけです。
　
　8) OOPLに最低限必要な機能ってなに？
　　 オブジェクト(インスタンス)を(複数)作成できる機能

>咳さん

>OOPの理解度って、どう使うものなのでしょう。
私個人としては以下の用途を想定してました。

　・新人がどの程度OOPを理解しているか把握し、今後の教育方針を立てやすくする
　・質問という形でOOPを学ぶ為の足がかりを提示する

二番目は理解度ではなく質問の使い方ですね。
なお、これらの質問は基本的に質問者と回答者の相対的な理解度しか図れないと思っています。なので理解度に対して何かしらの点数をつけることは無意味なことだと思っています。これらの質問はOOPの理解度を図る絶対的な尺度にはなりえないってことですね。
また、回答者の方がOOPをより理解しているという状況では質問者に理解できない回答がされる可能性が十分にあります。
その場合、

　・理解できない回答はより高いレベルでの回答である可能性が高い。
　　⇒どのような理由でその回答に至ったのかを学ぶことはOOPを理解する
　　　手助けとなるはず

と考えています。
まぁ、回答が理解できるできないに関係なく、他の人の回答について考えるということ自体がOOPの理解を深める為の良い機会になるのでは？と思います。
また、こちらは副産物になりますが

　・現在の自分の認識を明確にする

なお、これを書いたらちょっと怒られそうですが…
#でもコレがこのトピックを立てた一番の理由…だったりします。^^;

　・そんな質問があったら面白そうだから

といったところです。
こうして列挙してみると分かりますけど、私は質問によって得られる"理解度"自体をあまり重要視していないです。私が重きを置いているのは理解度を図る為の"質問"の方ですね。

>理解度は一次元のベクトルになりますか?
すいません、この文面の意味するところを理解できませんでした。orz

>なんというか、言葉としてのそれを知っているのと、
>それが身に付いていてコードに染み出てくるのとは
>だいぶ違う気がします。
同感です。
でも概念を理解しているに越したことはないと思います。

以上、長文失礼致しました。
#話題が戻っていないと感じるところは軽くスルーして下さい^^;

根本的な質問をさせてください。

「オブジェクト指向」はどこかの学会や資料で明確に
定義された言葉ですか?
それとも、多くの人が似たような考えを言い合って
習慣的に出来た言葉なのですか?

多分、後者なので議論が絶えないのだろうと思います｡

melfina さん、

「オブジェクト指向」は、この言葉を世の中に広めるのに貢献した Smalltalk と C++ という二つの言語の設計者である、アラン・ケイとビアルネ・ストラウストラップ両氏により、それぞれが、どんな考え方なのかについての説明が試みられています。

前者は、端的には、データやプログラム間でメッセージを送り合うというアイデアに基づいて、コンピュータシステムを従来のものより変更に強い、柔軟なものにしようという考え方です。

後者は、端的には、それまで言語によって決められていて、プログラマが変更することができなかった「データ型」というものを、プログラマが自由に定義できるように言語機能を拡張して提供しようという考え方です。

ケイとストラウストラップは、時期こそ前後していますが、それぞれ独立して、SIMULA という言語にオブジェクト指向とは関係ない目的で備え付けられていた「オブジェクト」と「クラス」という言語機能を拝借することで、それぞれの考え方をサポートさせる言語を作りました。

具体的には、ケイはメッセージのやりとりに「オブジェクト」を使うことを思いつき、ストラウストラップはデータ型を定義するのに「クラス」を使うことを思いつきました。こうして作られたのが Smalltalk と C++ です。

両者の考えは、かなり異なる状況を前提としているのですが、「オブジェクト指向」という同じ名前と、結果的に「オブジェクト」と「クラス」という同じ（当時としては目新しい）言語機能をともに備えていたため、「オブジェクト指向」を紹介しようとする人達に大きな混乱と誤解を与えてしまいました。

その結果、説明者たちは、Smalltalk と C++ の言語機能から推測したり、あるいは、自らの印象や経験に基いたりしながら、両者の考え方や登場する要素を適当に組み合わせ、自分たちなりの「オブジェクト指向」を語ることを試みるような風潮ができあがってしまったわけです。

ですから、ご質問の答としては、「オブジェクト指向」には、本来、定義らしきものはある（あった）けれど、ひとつではなく違った文脈で二つ。しかも、それぞれが前提とするところは、ほとんど無視されたうえ、それぞれの要素だけ（たとえば、ケイのからはメッセージ、ストラウストラップのからはカプセル化・継承・多態性…という具合に）抽出されて好き勝手に多くの人によって語られてしまっている…といったところが妥当ではないかなと思います。


人によって、曖昧なイメージとして語られる「オブジェクト指向」の理解度をはかるのは不可能だという点では同意ですが、発案者により定義が試みられた「オブジェクト指向」についてならば、そのどちらに立脚しているのかをきちんと整理して再構築できさえすれば、それぞれの本質をどのくらい把握できているかをはかる程度のことは可能だと個人的には考えます。

26: 鷲見 さん
早速のご回答ありがとうございます。
Smalltalk系統とC++系統で大分されるんですか、
初めて知りました｡

C++は現状のハードウェアで動かすのに現実的な表現であり
信頼性の高いシステムを組むのに適切な存在である｡
Java, C#も思想は同じである｡
この様に解釈しています｡

Smalltalkを真似ている言語は思い当たりませんね。
現在のハードウェア性能なら満足に走るのでしょうか｡

melfina さん、

＞Smalltalk系統とC++系統で大分される

細かいことで恐縮ですが、この場合、「ケイのオブジェクト指向とストラウストラップのオブジェクト指向の二系統で大分される」と表現したほうが語弊が少ないと思います。たしかに上で、Smalltalk や C++ は、ケイやストラウストラップがその考え方によって作った言語だと書きましたが、逆から見て、言語のほうでは必ずしも設計者の考え方をきちんと具現化できているわけではないので…。

実際、C++ で仮想関数呼び出しを全然関係のないメッセージと解釈する人もいますし、Smalltalk でのプログラミングやクラスライブラリでもストラウストラップのオブジェクト指向の考え方はいまや支配的です。設計者の意図から外れることで当然、弊害は出ますが、それでも元の考え方がパワフルだと、工夫次第でメリットもあるため、一概には間違いと切り捨てることもできません。こうした実情もまた、こと“概念”の理解度をはかるうえではやっかいな要素のひとつであると感じています。

＞Smalltalkを真似ている言語は思い当たりませんね。

有名で比較的よく使われているところでは、Mac OS X の、いわゆる“ネイティブな”言語である Objective-C というのがあります。参考まで。

むしろ、現在、OOPL であることを設計者が公言してはばからない言語で、Smalltalk からの影響が皆無であるものを探すことのほうが難しいように個人的には考えます（この事実も、また、「オブジェクト指向」を学びにくいものにしてしまっている要因のひとつなわけですが…）。

>Smalltalk からの影響が皆無であるものを探すことの
>ほうが難しいように個人的には考えます

JavaはC++よりもSmalltalkに近いと思っているので、
JavaをC++側に分類されるのすら抵抗がある私です。

そりゃまあSmalltalkにはinterfaceはないし、
JavaにはBlockclosureやらはないし、Javaも
C系である以上コードを見たらC++に似て見えるのは
当然ではありますが、プログラミングで常に考慮
するべき変数宣言やメモリ管理でガベコレがある
なしってのは決定的なコーディングスタイルの
差になるので。

このトピに絡めていえば、あれほど違うJavaとC++が
どっちも「C系」でひとくくりにされているあたりに
「分かりにくさ」の一因があるのでは。

otakutalker@金ツ49a さん、

> JavaはC++よりもSmalltalkに近いと思っているので、
> JavaをC++側に分類されるのすら抵抗がある私です。

「C++側」ではなく「ストラストラップのオブジェクト指向側」に分類すると表現してあったとしても駄目でしょうか？　たしかに仕様や実装的には Java は C++ よりは Smalltalk に近いのですが、設計者の意図としてはどうなのでしょう。

これは少々うがちすぎかもしれませんが、Java における、インターフェイスの導入や、逆にクロージャ導入へのかたくなな拒絶は、Java が立脚するところが（ケイの…ではなく）ストラウストラップ寄りであることを示しているように個人的には思えてなりません。

ご指摘のメモリ管理に関しては、大筋でストラウストラップの流れをくむメイヤーがその必要性を説いていることからも、本来はあるべきものを、たまたまストラウストラップの嗜好で C++ からは排除されただけ…と考えることはできませんでしょうか？

> 「ケイのオブジェクト指向とストラウストラップのオブジェクト指向の二系統で大分される」

あ。好きなOOPLを自慢してもらう、ってのはどうでしょうね。

>　・新人がどの程度OOPを理解しているか把握し、今後の教育方針を立てやすくする

一緒に仕事をするであろう新人さん向け、ですかねえ。
経験的に「OOPを学ぶ」ってことはなくて、「プログラミングを
学ぶ」な気がします。

「オブジェクト指向がわからないのでうまく書けません」では
なくて「プログラミングがわからない」ことが多いです。

OOP以外のプログラミングのパラダイムとOOPとの差分を
OOPの特徴とするなら、OOP以外を理解していないと
OOPの特徴を知れません。

なんていうのかな。OOPのキーワードは知ってる人、っていて
理解度テストはパスするけど、実際にどう書いていいかわから
ないというか‥


>　・質問という形でOOPを学ぶ為の足がかりを提示する

彼/彼女のそれまでのプログラミング経験によって
変わってくるような気がするなあ。なんとなく。
バックボーンによって、OOPを理解していくメタファが
何通りもあるようです。ADTの延長と捉える人や
デバイスドライバを想像する人とかWindow Systemから
連想する人とか。

私は、いろいろな話をしながら適切なメタファを示すように
しています。# いつもうまく行く訳じゃないですけど。

>>理解度は一次元のベクトルになりますか?
>すいません、この文面の意味するところを理解できませんでした。orz

理解度が数値になっちゃったりするのかなあ、です。

例えばCMMでは組織の成熟度を測って5段階の数値で表すと
ころが特徴なのですが、そんな風にOOP理解度レベルn級を
示したいのでしょうか? という質問でした。

>咳さん

>経験的に「OOPを学ぶ」ってことはなくて、「プログラミングを学ぶ」な気がします。
>「オブジェクト指向がわからないのでうまく書けません」ではなくて
>「プログラミングがわからない」ことが多いです。
うっ、確かにその通りですね。^^;

>OOPのキーワードは知ってる人、っていて理解度テストはパスするけど、
>実際にどう書いていいかわからないというか‥
確かにいますね、こういう人。
そういう意味では言葉を知っているだけでは答えられない理解度テスト(この場合は習熟度テスト？)なんかがあると便利そうですね。
ん〜、そうなるとやっぱり実際に小さな問題の分析/設計/実装をしてもらうのが一番よさそうな気が…。

>私は、いろいろな話をしながら適切なメタファを示すようにしています。
なるほど。それは良い方法ですね。
今度試してみます。
#とはいっても今は無職なんでいつになるやら…^^;

>理解度が数値になっちゃったりするのかなあ、です。
そういう意味でしたか。
私の回答は「数値化出来ないし、するつもりもない」になります。

がると申します。
ちと古い書き込みですが、ネタが面白かったので書いてみました。


1) オブジェクトとは？
モノ。大抵の場合「メモリ資源を使って構築されたマテリアル」。

2) 以下の言葉を説明して下さい
　クラス/継承/カプセル化/委譲/多相性(ポリモルフィズム)
クラス：意味は広いけど、狭い意味だと「設計図」
継承：同じ処理２回書くくらいなら上に持ち上げればそれですむでしょ？
カプセル化：中は覗かないで!!
委譲：ごめん代わりに処理やっといて ノシ
ポリモーフィズム：文字？数字？ようはオブジェクトでしょ？

3) 名前ってどのくらい大切だと思う？
データを設定するときにgetとか書かれると混乱のもと。
動作させたいのにstopとか書かれても困るだけ。
同じ意味を違う名前で書かれるのも嫌いだなぁ。

4) 1+2 オブジェクト指向的に読むと？
１オブジェクトに対して、(１オブジェクトの)＋演算子経由で２オブジェクトを投げつける。
結果？ １オブジェクトに聞いて。

5) 1+2*3 の戻り値が 9 、コレってバグ？それはなぜ？
1 2 + 3 *
なら９になるし、
2 3 * 1 +
なら７になるし。
上がわからない人は「逆ポーランド記法」参照。

6) デザインパターンを使ったことがある？それはなに？
一部。使えるのもあるし、使い物にならないのもあるし。リファクタ時限定なパターンもある。

7) UMLって読み書きできる？
読めるけど書かない。

8) OOPLに最低限必要な機能ってなに？
とりあえず…アクセス修飾子がなくて困ったことがあるのでそこをひとつ。
個人的には「多重継承」必須だと思うのですがこの辺は微妙。
マルチインヘリタンスできないOOPは想像もつかない。

以上なんかかなりざっくりとですが。

本題から多少外れてるかもしれませんが・・・
PHPってOOPというか、オブジェクト指向言語ですか！？
出来ればその理由も教えてください。

こんなのがあったんですけど、
http://d.hatena.ne.jp/keyword/%A5%AA%A5%D6%A5%B8%A5%A7%A5%AF%A5%C8%BB%D8%B8%FE%B8%C0%B8%EC
これで言う「ハイブリッド型オブジェクト指向言語」ってのに分類されるんでしょうか？

>>37
>PHPってOOPというか、オブジェクト指向言語ですか！？

継承を用いたクラスを自作してそのインスタンスを普通に操作できるので、そう名乗る資格は十二分にあります。

>これで言う「ハイブリッド型オブジェクト指向言語」ってのに分類されるんでしょうか？

オブジェクトでない型を処理できるので、そういうことになりますね。
ちなみに、はてなの記述を参考にするよりは、Wikipediaの記述を参考にすべきだと思います、個人的には。

http://ja.wikipedia.org/wiki/PHP_Hypertext_Preprocessor

なんかいまさらですが、sumin さんの書き込みがとても勉強になりました。

実際のコーディングでは、概念としてのオブジェクト指向と、それぞれの言語に置ける言語機能の仕様を、きちんと切り離して理解することが大事だなあと最近は思うようになりました。

個人的には、C++ でクラスの構成を考えるときなんかは、「これとこれは is-a 関係か？」のように考えるのではなくて、「これとこれが共通の親クラスをもっていると、ラクができるんじゃないか？」という観点で考えるようにしています。仮想関数のように呼び出しにコストがかかる場合もあるので、そういうのも含めて。

あ、sumin さんじゃなくて sumim さんでした。名前を間違えてしまってごめんなさい。

>>38

PHPもそう名乗っていいんですね。

Wikipediaの内容はある程度知っていたのですが、
はてなを載せたのは単に「オブジェクト指向言語とは」でぐぐったら最初に出てきたからです。
シェルみたいなことが出来たり、組み込み関数を使えたり、ソースにHTMLをそのままかけたり・・・
この言語はかなり変わった言語のように思えたので、オブジェクト指向言語という分類に当てはまるんだろうか・・と思ってました。
PHP5系はOOPできてるって思えるけど、PHP4系って微妙な気がします。
PHP5系でもまだ足りない気はしますけど・・
インターフェースは継承させて！

とおる。さん、言及いたみいります。

概念と仕様をきちんと切り離せるようになると、いろいろなことがすっきりと理解できてよいですよね。

はじめまして、doloopと言います。
いきなりで不躾ですが・・・
　4) 1+2 オブジェクト指向的に読むと？
　5) 1+2*3 の戻り値が 9 、コレってバグ？それはなぜ？
　6) デザインパターンを使ったことがある？それはなに？
　7) UMLって読み書きできる？
この４つの質問は、『オブジェクト指向そのもの』には関係無いと思います。

4)5)は、C++の演算子オーバーロードの仕様に依存した質問です。
演算子は普通クラス内で定義しますが、オブジェクト指向には関係ないと思います。

6)7)は、JavaやC++を扱う上では重要ですが、UMLは大規模なクラスのシステムを扱うためのもの、デザインパターンはJavaやC++の欠点を回避するためのものという意味合いが強くて、それ以外の条件では必要ないかもしれません。

オブジェクト指向・・・というとC++やJavaは主流な言語なので、それの話題になってしまうのですが、趣味でPythonを使っているとどうも違和感を感じてしまいます。
Pythonのオブジェクト指向は邪道と言われることもありますが。