マルチプルインスタンスのメリット

１００％の自信をもって回答できる方のみ回答をお願いします。

Java等のオブジェクト指向プログラミング技術において、クラスからインスタンスを
たくさん作れるというのが特徴の一つとなっていますが、クラスからインスタンスを
たくさんつくれるメリットはなんでしょうか。
クラスからインスタンスをたくさん作れなくても、１つ作れば動くプログラムはたくさんありますし、
そういうプログラムであれば、staticなアクセスにすればよいですよね。

クラスからインスタンスがつくれることを説明した本やサイトは山ほどありますが、
インスタンスがたくさん作れることのメリットを説明した本をみたことがなく、
「なぜオブジェクト指向でつくるのか」という本を買って読みましたが、
納得がいくメリットを感じられませんでした。

また世の中のソースをみると、みんな、すぐにクラスを作ってオブジェクトを作っていますが、
みなさんがどうして、オブジェクトを作らなくてもコーディングできるケースのプログラムを
オブジェクトを作るのか不思議でしかたありません。

どうしてオブジェクトを作らなくてもいいケースでもオブジェクトを作るのか、
またたくさんオブジェクトを作れるメリットはなんなのか、教えてください。

No.5 回答者： notnot 回答日時： 2011/01/13 21:20

1行の違い、もっと言えば10%程度の行数の違いが、プログラムの読みやすさ、プログラムのメンテナンスのしやすさには有意に影響しません。

というか、行数が少ないことは、結果であって、目的では無いので、プログラムの理解のしやすさ、メンテナンスのしやすさを第一に考えるべきです。

なので、
＞「オブジェクトが１つしかないクラス」と「スタティック」とで、プログラミングの楽さは有意に変わらないと思いますが。
と書きました。ここでの「楽さ」は、「プログラムのしやすさ、理解のしやすさ、メンテナンスのしやすさ」です。

元々の質問の趣旨と外れるので、これくらいにしておきますが、もし納得がいかなければ、

「プログラムの善し悪しを判断する基準はいろいろあるが、プログラムの短さはその中でどれくらいの順序だろうか？」

という質問をされてはいかがでしょうか。

この回答へのお礼

＞1行の違い、もっと言えば10%程度の行数の違いが、プログラムの読みやすさ、プログラムのメンテナン＞スのしやすさには有意に影響しません。
＞というか、行数が少ないことは、結果であって、目的では無いので、プログラムの理解のしやすさ、メン＞テナンスのしやすさを第一に考えるべきです。

私はソース数が少なければ、それだけ読みやすさやメンテナンスの有意に影響すると思っています。
１０％なんて大きいと思っています。同じことをするのに１０％のコードを減らすなんて、
どれだけ大変でしょうか。
また、ステップ数が少ないことは、目的でもあると思っています。決して結果ではないと思っています。

＞「プログラムの善し悪しを判断する基準はいろいろあるが、
＞プログラムの短さはその中でどれくらいの順序だろうか？」

これは聞くまでもなく、高いと思っています。
究極は、プログラムを書かなくても動くシステムです。
書かなければ、バグも出ない、時間も金も掛からないですからね。

お礼日時：2011/01/13 21:50

No.4 回答者： notnot 回答日時： 2011/01/12 23:21

＞プログラミングが楽になるのであれば、オブジェクトを作ればいいし、楽にならないのであれば、オブジェクトを作らなくてもいいと思います。

＞ここで言う楽とは、コーディング量が少なかったり、可読性が高かったり、バグが混入しにくいといった意味です。

これは#1で私の書いた(1)のケースの話と思って良いでしょうか？
「オブジェクトが１つしかないクラス」と「スタティック」とで、プログラミングの楽さは有意に変わらないと思いますが。

(1)の話じゃなくて、
「プログラミングが楽になるのであれば、オブジェクト指向でつくればいいし、楽にならないのであれば非オブジェクト指向で作ればいい」
ということであれば、賛成です。別にJavaを使うからといってオブジェクト指向開発をしなければならない訳じゃない。

最初に、
私＞かならずしもオブジェクト指向開発をしなければならないわけではないので、その場合は、クラスもオブジェクトも使いません。それだけのことです。
と書いた通り。あ、Javaだとコーディング上はｃｌａｓｓが出来ちゃいますが。


私＞複数あるものに対して、１つのオブジェクトを使い回すのは間違っています。
と書いたのは、オブジェクト指向が前提です。これに限らずオブジェクト指向開発を前提に回答してます。

＞オブジェクトはループ毎で作りますが、それを扱う変数は常に一つにしておくということです。

それは普通ですね。

＞社員情報を管理するシステムでも、社員情報を１件つづ処理するのであれば、ループにしてその中でオブジェクトを１つ作れば、稼動しますから

から、そうとは読み取れませんでした。てっきり、文字通りの意味かと。それでも動きますので。

この回答へのお礼

どうもありがとうございます。

>「オブジェクトが１つしかないクラス」と「スタティック」とで、プログラミングの楽さは
>有意に変わらないと思いますが。

私の以下のように思っております。
プログラムには、大きく分けて、２種類つのコードがあると思っています。
１つ目はビジネスロジックのコードで、２つ目はそれ以外のコードです。
ビジネスロジックのコードとは、例えば、商品単価に消費税をかけて合計金額を出すような
コードです。ビジネスロジックのコードは省くことが出来ないコードでもあります。
それ以外のコードとは、表現が難しいですが、ビジネスロジック以外のコンピュータさんに
対する命令です。例えば、
testclass tc = new testclass();
と言った記述です。
こういうコードは、書かなくてもいいのであれば、書かないに越したことがないと思っています。

オブジェクトを作って実行するなら
testclass tc = new testclass();
tc.method();
というように２行です。
オブジェクトを作らないなら、testclass.method()
というように１行です。
まったく同じことが出来るなら、１００行より９０行の方がいいですし、
２行よりも１行の方がいいです。
「なんだ、たった１行じゃないか」といわれるかも知れませんが、楽をすることを目指すのであれば、
例えこの１行でもコードが少ないほうが、ポリシーに即していると思っています。

少し話しが逸れますが、今、デザインパターンの勉強をしています。
あるデザインパターンで書かれたコード（ちゃんとした本にのっているやつ）だと、
デザインパターンを使わなければ１つのクラスで完結する処理が、
デザインパターンだと４つのクラスが必要になり、総ソースコード数も多くなっています。
私が思ったのは、オブジェクト指向というのは楽をするためのものなのに、返ってステップ数が
増えているじゃんということです。
もちろん、後々の改修等の色んなことを考えられてそういう作りにされているのだと思いますが、
初期のコードの少なささや作りやすさを考えたら、オブジェクト指向で作ることが本当に
いいのかという疑問が起こってきます。
ですので、（同じことが出来るのであれば）楽に作ることを考えて作ればよく、
その中でオブジェクト指向のテクニックが使えれば使えばよく、オブジェクト指向を
使うことによって、楽じゃなくなるなら、使わなくてもいいという意味で、たとえ１行であっても
同じことが出来るならstaticを使うほうがいいと思っています。

お礼日時：2011/01/13 20:42

No.3 回答者： notnot 回答日時： 2011/01/11 21:35

#2です。

＞もし、基本的なポリシーをご理解されているのであれば、ご教授ください。

掃除の例でお書きのように、「こういうケースでは」と具体例がでないと、なんとも言い難いです。
自然に決まると書きましたが、もちろん、中には判断に困るケースもあるとは思います。それも具体例がでないとなんとも。


＞複数作るやり方でも１つしか作らないやり方でも出来ると思います。

出来ると正しいは違うというのは前に書いた通り。
複数あるものに対して、１つのオブジェクトを使い回すのは間違っています。オブジェクトは変数じゃないので、違う物に使い回してはいけません。

ただ、今日読んだブログ http://d.hatena.ne.jp/ryoasai/20110109/1294581985 によると、大手ＳＩベンダーでは、お書きのようなstaticばかりのJavaコーディングが普通にされているようです。
コメントも含めてお読みになると良いかと。

この回答へのお礼

回答ありがとうございます。

>掃除の例でお書きのように、「こういうケースでは」と具体例がでないと、なんとも言い難いです。
>自然に決まると書きましたが、もちろん、中には判断に困るケースもあるとは思います。それも具体例が>でないとなんとも。

そうでしょうか。私は具体的な例がなくても、ポリシーは示せると思っています。
私は、オブジェクト指向プログラミングは「従来のプログラミングを多少なりとも楽にする技術や考え方」
と認識しています。その具体的な手法や概念が、クラスであったり、継承であったり、ポリモーフィズム
だと思っています。
この認識が正しいかどうか分かりませんが、私の認識が正しいと仮定すれば、開発時や後々の保守の
プログラミングが楽になるのであれば、オブジェクトを作ればいいし、楽にならないのであれば、
オブジェクトを作らなくてもいいと思います。
ここで言う楽とは、コーディング量が少なかったり、可読性が高かったり、バグが混入しにくいといった
意味です。

>出来ると正しいは違うというのは前に書いた通り。
>複数あるものに対して、１つのオブジェクトを使い回すのは間違っています。
>オブジェクトは変数じゃないので、違う物に使い回してはいけません。

私はそうは思いません。
コーディングは思想に似ているところがあると思っており、一概にこれが正しいというものは
ないと思っています。
それぞれの思想にメリット／デメリットがあるように、コーディング方法にも一長一短があります。
なお、複数あるもにに対して１つのオブジェクトを使いまわすという意味ではなく、
オブジェクトはループ毎で作りますが、それを扱う変数は常に一つにしておくということです。
これなら、オブジェクトはたくさん作られますが、アクセスできるオブジェクトは常に１つですよね。

コラム拝見させていただきました。
ただ、このコラムを書かれた方が本当にオブジェクト指向を理解されている方なのかどうかが
分かりません。Javaでプログラムを１５年書かれているようですが、それとオブジェクト指向の
本質を理解されていることは別ですから、この方の意見が適性なのか判断できないです。
逆に私は、オブジェクトは必要なところであれば使えばよく、そうでないケースであればstaticでも
いいと思っていますので、なんでもかんでもオブジェクトを作っている世間一般の風潮には、
疑問を感じます。

お礼日時：2011/01/12 12:30

No.2 回答者： notnot 回答日時： 2011/01/10 22:35

(1) オブジェクトが１つしかあり得ないようなクラスに於いて、唯一のオブジェクトを作るケースと、オブジェクトを一切作らずすべてstaticで行うケースが考えられるが、それぞれのメリット・デメリットは？

＞オブジェクトを作らなくてもいいケースでもオブジェクトを作るのか、

「オブジェクトを作らなくていいケース」でオブジェクトを作るのは間違っています。

「あなたがこれはオブジェクトを作らないでいいと思うケース」では、実はあなたの「オブジェクトを作らないでいい」という判断が間違っていて、オブジェクトを作るべきケースなのかもしれず、その場合はオブジェクトを作るのが正解です。
そのケースを別の言い方をすると「オブジェクトを作っても作らなくてもコーディングが出来て動くケース」でしょうけど、コンパイル出来て正常動作さえすればよいという考えは間違っており、問題に応じて自然にどちらが良いか決まると思います。


(2) あるクラスから複数のオブジェクトを作れて嬉しいのはどんな場合？

自明ですが、そのオブジェクトが表すものが複数ある場合です。
例えば、社員の情報を管理するプログラムであれば、社員クラスを作って、社員の数だけのオブジェクトが作られます。これを作らないというのなら、それはオブジェクト指向開発ではないです。
かならずしもオブジェクト指向開発をしなければならないわけではないので、その場合は、クラスもオブジェクトも使いません。それだけのことです。

この回答へのお礼

回答ありがとうございます。

＞そのケースを別の言い方をすると「オブジェクトを作っても作らなくてもコーディングが出来て
＞動くケース」でしょうけど、コンパイル出来て正常動作さえすればよいという考えは間違っており、
＞問題に応じて自然にどちらが良いか決まると思います

もちろんそうで、そこが肝だと思っています。
が「それを自然にどちらが決まる」という回答であれば、判断が付きませんよね。

たとえば、自宅に掃除機と箒（ほうき）を持っていて、どちらを使って掃除をするか考える場合
・（例えば深夜で）周りの迷惑になる場合は、箒をつかう
・コップを割ったりして、細かい破片を残らず拾いたいときは掃除機をつかう
・何も考慮する必要がない場合は、楽な掃除機をつかう
といったように、使い分けを判断するポリシーというのがあると思います。
同じように、オブジェクトを作るかつくらないかについても基本的なポリシーあって、
それが分かっていなければ判断できないと思います。
もし、基本的なポリシーをご理解されているのであれば、ご教授ください。

＞自明ですが、そのオブジェクトが表すものが複数ある場合です。

ま、それはそうなのですが、そんなケースってありますか？
あるかないかでいえばあるになりますが、ケース的にはレアだと思います。
例えに示されてる、社員情報を管理するシステムでも、社員情報を１件つづ
処理するのであれば、ループにしてその中でオブジェクトを１つ作れば、稼動しますから
複数作るやり方でも１つしか作らないやり方でも出来ると思います。
この例では、どちらが最適なのかは判断できませんが、複数作らないとブジェクト指向では
ないというのは、オブジェクト指向に対する明らかな認識間違いです。

お礼日時：2011/01/11 10:41

No.1 回答者： noname#161640 回答日時： 2011/01/10 17:19

うーん、別に100%の自信を持って答えるわけではないのですが。

一体、どこが納得できないのかが質問文ではうまく伝わって来なかったのです。

例えばですが。マルチウインドウのプログラムがありますね？　あれは、「インスタンスを複数作れない」とすると、どうやって作るのでしょう。普通に考えれば、ウインドウのクラスを用意し、それを必要に応じてインスタンス化していくことで、いくらでもウインドウが作れますね。これを「１つしか作れない」とした場合、ウインドウのクラスをいくつも用意しなければいけないことになりませんか？　あるいは、「インスタンスを複数作成する」というのよりもっとわかりやすく効率的な方法を考えられますか？

従来ならば、こうした場合、ウインドウの構造体を定義し、その変数を作成し管理する、というようなアプローチだったと思います。それが「構造体→クラス」「変数→インスタンス」と呼び名がかわっただけで、やっていることは昔から同じだと思うのですが。

オブジェクト指向に限らず、どのプログラミング言語でも、ある型の変数は複数作れます。int型の変数は１つしか作れない、ということはありませんね。必要なだけいくらでも作れます。int型はシンプルな構造ですが、もう少し複雑な構造体も、その構造体からいくつでも変数を作れます。

オブジェクトというのは、ありていにいってしまえば、単に「構造体に関数ポインタを標準でもたせるようにしたもの」でしょう。普通の基本型や構造体で、必要に応じていくらでも変数が作れるのに、構造体を少し強化して「クラス」と名前を変えただけで、なぜいくらでも変数（＝オブジェクト）を作れるということに疑問を感じるのでしょうか。別に何の不都合もないと思うのですが。

>世の中のソースをみると、みんな、すぐにクラスを作ってオブジェクトを作っていますが

本当に不要なケースなのにいちいちインスタンスを作るというのは、単によくわかってないからでしょう。そうではなくて、きちんとしたプログラマがクラスではなくインスタンスを作って利用する場合は、「インスタンスとして利用するほうがよいと考えてクラスが設計されているから」でしょう。

「オブジェクトを作らなくてもコーディングできる」というのは、「オブジェクトを作らないほうが効率的である」というのとは違います。単にそのコードだけでなく、そのクラスがどのようなシーンで活用されるかということを広く想定した場合、たいていは「インスタンス化して利用出来るようにしたほうが効率がいい」ということに落ち着くのだと思います。そうではないケース、例えばMathクラスなどは、静的クラスに設計されていますね？　単に「そのほうが使いやすいかどうか」ということで設計しているだけでしょう。

この回答へのお礼

せっかく回答してくださって申し訳ないのですが、１００％の自信がないのであれば
回答くださらなくても結構です。ありがとうございました。

お礼日時：2011/01/11 10:21