オブジェクト指向の壁

質問

Java言語などは「オブジェクト指向」が売り？だと思うのですが
素人や初心者が、ぶち当たる「オブジェクト指向の壁」って何だと思いますか？

暇な時にでも回答ください。

回答No.14

amanojaku1 · ベストアンサー

>クラスのインスタンス化がはっきり分かること

そこは、そんんな難しくないと思いますが。

>★クラス(設計図)からインスタンス(実体)を量産できる。
>分かりやすく生物で例えるとDNAを再利用してクローン(複製)を量産できる(この場合 、オブジェクトからオブジェクトをクローニングすると言う意味ではありません。)

↑この説明でOKかと。

回答No.15

amanojaku1

細かい事を言うなら、オーバーライドによる多態性が分かりにくいですね。

親クラスA、その子クラスBが有ったとして、両方に同じメソッドM(子クラスBがオーバーライドしている)が有ったとします。
子クラスBをインスタンス化した場合、親クラスA内からメソッドMを呼び出す処理があると(デフォルトの場合)クラスBのメソッドMが呼ばれます。

参考。

オーバーライドとオーバーロード間違えないために
http://qiita.com/ShirakawaYoshimaru/items/058484a8fb584eb452b2

回答No.13

seastar3

クラスのインスタンス化がはっきり分かることが大切だと思います。つまり、インスタンス（実体）はクラス（設計図）をコンピュータのメモリー上に在処を確保した機械語プログラムのまとまりです。別名で複数のインスタンスを生成し、インスタンス名.メソッド() や インスタンス名.プロパティ などと指定して操作することは、　例えば、1000番地から始まるインスタンスの500番地目のメソッドを働かせよとか、1000番地から始まるインスタンスの200番地目にあるプロパティを呼び出せとか、指示しているのです。これが別名であれば、3000番地から始まるインスタンスのメソッドやプロパティを操作せよと指示すればいいのです。
　この手順を意識すれば、クラス（型）とインスタンス（実体）の違いやオブジェクト指向らしい記述の手順が理解しやすくなります。

　また、オブジェクトを使う技術とオブジェクトを作る技術と分けて考えれば、オブジェクト指向の壁を乗り越える手掛かりになると思います。割と簡単なオブジェクトを使うことをオブジェクト指向的に捉えることができるようになると、オブジェクト指向プログラミングについても理解しやすくなることでしょう。具体的には、表計算ソフトの各ワークシートもオブジェクトなので、シート１をシート２に複写してみたり（複数のインスタンス生成）シート２だけ売上金額を消費税込みの列にしてみたり（継承）、ワークシート関数の（ ）内の引数を省略できたり、セル内の値を状況により四捨五入の指定や日付形式の表示指定ができたり（多態性）することが、オブシェクトを使っていることに対応しています。
　そのような使い方をオブジェクト指向として捉えれば、ＶＢＡでシートやセルの操作する基礎になるわけです。そこまでできれば、オブジェクト指向プログラミングのさらに高度な活用法が分かるようになっていくでしょう。

回答No.12

hiodraiu

初心者だと、最初は小さなプログラムから作り始めるだろうと思います。そうなると、オブジェクト指向を使うメリットがなかなか見えてこないように思います。

そこそこの規模のあるソフトウェアで、複数のクラスがある中で、インターフェースを使ってポリモフィズムを使ったりすると、メリットも見えてきそうですが、初心者では、そこそこの規模って時点で、難しい気がします。

回答No.11

amanojaku1

稀にクラスでプログラムを作れば「オブジェクト指向」だとか勘違いしてる人も居ますので、ご注意を。
人に「オブジェクト指向」の話を聞く場合、それを見抜くぐらいの能力が必要です(笑)
また、(「オブジェクト指向」とか)簡単にできちゃう人も自分基準でモノを話すので自分基準でモノを話すので参考にならないと思います。
そう言う人は「難しい事を考えずに普通にプログラム組めば良いんだよ」とか言っちゃたりします、いわゆる(野球選手だった)「長嶋茂雄」タイプですね。
非常にスランプに苦しんでる選手が「長嶋茂雄」にバッティングの話を聞いた時に、「長嶋茂雄」は「ピューと来た玉をカーンと打てば良いんだよ」とか言ったそうです(それぐらいの事でスランプから脱出できたら苦労はせんわい、と言う話)。

回答No.10

amanojaku1

>大雑把にいえば「オブジェクト指向の壁」は、例えばグラフィックの描画で「DrawLine、DrawPolygon、DrawCircle」とかが(人に言われなくても)同じ機能だと認識できるか どうかです。

蛇足ですが、大抵の場合 抽象クラスを作っておきます、例えばグラフィックの描画関係ならFigureとか。

回答No.9

amanojaku1

>(グラフィックの描画の描画だけでなく)つまり(同系統のクラスで)同じ機能が同じ機能だと認識でき、それをクラスに実装できる能力があるか どうかです。

この辺の感覚は(言葉として分かっても)プログラミングしてみないと、実感として分からないと思います。

回答No.8

amanojaku1

>同じ機能は、同じ名前にする。
>例えば、グラフィックの描画で、「DrawLine、DrawPolygon、DrawCircle」とか やってはダメ、(特に同系統のクラスなら)全て「Draw」に統一する。

大雑把にいえば「オブジェクト指向の壁」は、例えばグラフィックの描画で「DrawLine、DrawPolygon、DrawCircle」とかが(人に言われなくても)同じ機能だと認識できるか どうかです。
(グラフィックの描画の描画だけでなく)つまり(同系統のクラスで)同じ機能が同じ機能だと認識でき、それをクラスに実装できる能力があるか どうかです。

回答No.7

amanojaku1

>★ラップ(分かりやすく例えるとプラグイン)によるオブジェクトの再利用。
>様々なオブジェクトを乗せ変えて活用させる事ができます(実際の PC で分かりやすく例えるなら高性能グラフィック・ボードを挿す、高音質サウンド・ボードを挿す、高速LANボードを挿す、みたいな感じで機能を拡張できる)。

すみません、この説明だと もの凄い自由度があるように勘違いしてしまいそうですね。

実際の PC で分かりやすく例えるなら、NVIDIAのグラフィック・ボードがさせるとか、AMDのグラフィック・ボードがさせるとか、その他のメーカのグラフィック・ボードがさせるとか、その程度の自由度です。

回答No.6

amanojaku1

>同じ機能は、同じ名前にする。
>例えば、グラフィックの描画で、「DrawLine、DrawPolygon、DrawCircle」とか やってはダメ、(特に同系統のクラスなら)全て「Draw」に統一する。

ブラックボックス化と言う表現は良くないかもしれないですが、プログラマーが「DrawLine、DrawPolygon、DrawCircle」とか考える必要がなければ、ヒューマン・エラーを削減できます(引数も(設定以外は)共通にする)。

オブジェクト指向プログラミングの理念はヒューマン・エラーの削減です。
以前はオブジェクト指向プログラミングの理念に反し、インスタンスを なんでもObjectに放り込む事も多々あったのですが、Genericsにより その辺の改善されました。
下記は再利用によるヒューマン・エラーの削減を目的としたモノです(つまりオブジェクト指向プログラミングの肝は再利用によるヒューマン・エラーの削減です)。

★クラス(設計図)からインスタンス(実体)を量産できる。
分かりやすく生物で例えるとDNAを再利用してクローン(複製)を量産できる(この場合 、オブジェクトからオブジェクトをクローニングすると言う意味ではありません。)

★クラスを継承し機能を拡張できる。
この場合、当然ゼロから作るのではなく継承元のクラスを活用する事ができるので、その分 労力の削減でき、手間が少なくなるので その分 プログラミング上のヒューマン・エラーも多少 減らせます。

★ラップ(分かりやすく例えるとプラグイン)によるオブジェクトの再利用。
様々なオブジェクトを乗せ変えて活用させる事ができます(実際の PC で分かりやすく例えるなら高性能グラフィック・ボードを挿す、高音質サウンド・ボードを挿す、高速LANボードを挿す、みたいな感じで機能を拡張できる)。

★オブジェクト志向プログラミングのデメリットは肥大化です。
つまり、上記のように再利用できないモノはオブジェクト化のメリットがなく、デメリットだけだと言って良い程です。

回答No.5

amanojaku1

>メソッドの名前とかではなく、メソッドの機能

同じ機能は、同じ名前にする。
例えば、グラフィックの描画で、「DrawLine、DrawPolygon、DrawCircle」とか やってはダメ、(特に同系統のクラスなら)全て「Draw」に統一する。