「ラッパークラス」の存在意義が分かりません。

Question

ラッパークラスの使い方などについての解説はよく目にしますが、
その意義となると、明確な説明を見たことがありません。
（本質問では、使い方を質問しているわけではありません。）

どういう意味で、便利なのか、
つまり、その存在価値について、お聞きしたいのです。

これがないと乗り越えられない壁があるのでしょうか。
その壁を乗り越えるための道具として、用意されたものであるなら、
その壁というものを教えて頂きたいです。

どなたか宜しくお願い致します。

nda23 · Accepted Answer

個人的に納得している状況を話しますね。
プリミティブなデータ（例えばint）はそれ自体に実体が
あるから、「インスタンス化」なんてしませんよね。
ということは「null」には絶対にならないわけです。
ところで、データベースからレコードを読み込み、整数型の
フィールドのデータを受け取ることを想定します。
そのフィールドがnullだった場合、受け取る変数がint型で
あったら、「nullであること」を表現できません。nullと
0は違いますからね。でも、Integer型の変数ならnullにする
ことができます。それにtoStringで編集したりできるのも
ウレシイところです。
あと、リフレクションをやると分かりますけど、実行させる
メソッドに渡す変数は本体の定義がプリミティブ型でも、
オブジェクト型の配列にする必要があるので、ラッパークラスに
限られます。

hatimiti · Answer

ちょろっと調べてみましたが、あるサイトにこんなことが書かれていました。
「オブジェクト指向言語なのにプリミティブ型を残したのは，C,C++などの互換性と，メモリ節約のためである」

C,C++との互換性というのは、native キーワードを使用する際に関わってくるのでしょうかね？（私も native は使った事ないのでわかりませんが)

メモリの節約というのはちょっと思っていました。無駄なものがない分、プリミティブのほうがメモリ節約になるかと思います。(int=4byte, Integer=8byte なのか？)

あと、引数として扱う場合、プリミティブは値渡し、オブジェクトは参照渡しとなるという違いもあるかと思います。

Tacosan · Answer

ちょろっと #7 に書いたんだけど, それをいうと「だったら最初から全部オブジェクトにしておけばいいじゃん」って突っ込まれそうな気がする＞#9. 実際, 「純粋なオブジェクト指向言語」 (例えば Smalltalk) では「全てのものがオブジェクト」というきれいな世界を実現していたりしますし.
で, こう考えると質問とは逆に「プリミティブ型の存在意義ってなんだろう」となってしまうわけでした.
ああ, 質問に全く答えてないよ....

PecoPlus · Answer

#3です。

また、抽象的な説明になりつつありますが、お許しを。

透過的に扱う例として、比べるというものがあるかもしれません。

int i = 1;
String str = "文字列";

この二つは、比べることができません。

if (i == str)

もだめですし、

if (str.equals(i))

も、だめです。
（オートボクシングについては、とりあえず忘れてください）

false が出てほしいのに、コンパイルエラーで、比べることすら許されません。
　しかし、

Integer i = Integer.valueOf(1);
String str = "文字列";

if (str.equals(i))

これは、可能で、ちゃんと、 false になります。

仮に、配列にプリミティブ型とオブジェクト型が混在できたとしましょう。
　その中から、あるデータと同じものを探すというのは、ありそうなことです。
　そんな時はいったいどうしましょう？
　プリミティブ型とオブジェクト型の型検査ができたとしても（Java では無理ですが）

1. 配列からデータを一つ取り出す。
2. プリミティブ型かオブジェクト型かを調べる。
3. プリミティブ型なら、比べるデータとさらに型があっているかどうか調べ、違うならfalse。
4. 同じなら、改めて、比べる

こんな複雑なことをするくらいなら、最初からラッパークラスに包んで、すべて equals メソッドで比べた方が、透過的で、シンプルです。

PecoPlus · Answer

#3です。

長々と書いてしまいましたが、どちらかというと、

>　プリミティブ型とオブジェクト型、型が違うからと言って、
>「文字の色」「太字か否か」「大きさ」などを別々の場所に
>格納するのはおかしな話です。
>　すべてをオブジェクト型にしてしまえば、これらの意味情報を
>同列に扱うことでできるのです。

こっちを言いたかったわけです。
　「文字の色」「太字」「大きさ」、これらは、文字列を修飾する情報という点で仲間です。
　できるなら、「文字列修飾情報」という一つの袋にまとめて入れておきたいわけです。
　それなのに、

「文字の色はColorクラスなのでオブジェクト袋に入れて、太字はboolean袋に入れて、大きさはinteger袋に入れよう」

なんて事をやっていると、情報がバラバラになってしまいます。
　重要なのはデータの意味であって、型ではありません。
　すべてをオブジェクト型として、情報を透過的かつシンプルに扱うというのは、オブジェクト指向では、重要なのです。

似たような考え方として、抽象クラスやインターフェースが存在します。
　これらも、なくてもプログラムは作れますが、使いこなせば、同じ意味を持つ違うクラスを透過的かつシンプルに扱えるようになります。

Tacosan · Answer

まあ確かに「ラッパクラスの意義」って難しいと思う. 逆に考えれば「プリミティブ型を含めてすべて『オブジェクト』としておけば『ラッパクラス』そのものが不要」なので....
そういう意味では「最初の『アレ』な設計を覆い隠す」というのが意義なのかもしれない.

PecoPlus · Answer

#3です。

ArrayListじゃあ納得できませんか。
　では、もっと、具体的に。
　サンプルコードをみてください。

public class Test extends JFrame {
　　JTextPane textPane;
　　DefaultStyledDocument document;

public static void main(String[] args) {
　　　　SwingUtilities.invokeLater(new Runnable() {
　　　　　　public void run() {
　　　　　　　　Test frame = new Test();
　　　　　　　　frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
　　　　　　　　frame.setSize(400, 300);
　　　　　　　　frame.setVisible(true);
　　　　　　}
　　　　});
　　}

public Test() {
　　　　document = new DefaultStyledDocument();
　　　　textPane = new JTextPane(document);

try {
　　　　　　//属性情報を作成
　　　　　　SimpleAttributeSet attribute = new SimpleAttributeSet();

//属性情報の文字色に赤を設定
　　　　　　attribute.addAttribute(StyleConstants.Foreground, Color.RED);
　　　　　　//属性情報に太字を設定
　　　　　　attribute.addAttribute(StyleConstants.Bold, Boolean.TRUE);
　　　　　　//属性情報に文字サイズ20を設定
　　　　　　attribute.addAttribute(StyleConstants.FontSize, Integer.valueOf(20));

//ドキュメントにその属性情報つきの文字列を挿入
　　　　　　document.insertString(0, "あいうえお
", attribute);
　　　　} catch (BadLocationException ex) {
　　　　　　ex.printStackTrace();
　　　　}

add(textPane, BorderLayout.CENTER);
　　}
}

属性情報の作成部分をみてください。
　文字色を赤、太字、サイズを設定しています。
　太字とサイズの第２引数に注目してみてください。
　ラッパークラスです。
　どうしてでしょう？
　それは、このメソッドの第２引数がObject型しか受け付けないから、致し方なくラッパークラスにせざるを得ません。

「いやいや、こんなのメソッドオーバーロードで対処可能でしょう。このメソッドを作った人が手抜きです」

と、言うかもしれませんが、そんなに単純ではありません。
　SimpleAttributeSet クラスは、内部では Hashtable を使ってこれらの情報を格納しますので、結局、最終的にはラッパークラスにせざるを得なくなります。

プリミティブ型とオブジェクト型、型が違うからと言って、「文字の色」「太字か否か」「大きさ」などを別々の場所に格納するのはおかしな話です。
　すべてをオブジェクト型にしてしまえば、これらの意味情報を同列に扱うことでできるのです。

mtaka2 · Answer

ラッパークラスは、既存のライブラリを流用するときに力を発揮します。

似たような機能を提供するクラスAとクラスBがあり、
提供する機能の違いとかの理由で、
この二つのクラスを使い分けしたい場合を考えます。

(例えば、特殊な画像フォーマットに対する読み書きを行いたい場合とかで、
 全形式を網羅するライブラリが無いから、画像フォーマットごとに複数のライブラリを使い分ける必要がある、とか)

ここでAとBは機能は似てますが、メソッド名などはてんでバラバラだったら…
そうなると、Aを使うコードとBを使うコードは別個に書く必要が出てきます。

そういうとき、同じインターフェースを持つラッパークラスを作り、
それを通してAとBを使うようにすると、
利用するコード側は共通化できますので、無駄がなくなりシンプルにできます。

PecoPlus · Answer

こんにちは。

>こんな私に、端的な例として、何か挙げて下さると
>大変有り難く思います。最も単純な例で結構です。

int n = 1;
ArrayList list = new ArrayList();

「ああ、ArrayListは、Object型しか入らない。どうしよう」
「えーい、包んじゃえー」

list.add(new Integer(n));

D-Matsu · Answer

ラッパー(wrapper)、要は「包む」ことですね。

何を包んでいるのかというと、「面倒な手続き一切合財」であるものがほとんどです。
ある機能を実現するのに必要な手続きを全てラッパー関数内に押し込めて、使う人はその関数を呼ぶだけにしておけば非常に楽ですし、間違いも起こりにくいですよね？

これについては、使う方よりも使わない方に壁がある事が多いです。
ないと面倒、ってところから来ているので。

「ラッパークラス」の存在意義が分かりません。

個人的に納得している状況を話しますね。

ちょろっと調べてみましたが、あるサイトにこんなことが書かれていました。

#3です。

#3です。

まあ確かに「ラッパクラスの意義」って難しいと思う. 逆に考えれば「プリミティブ型を含めてすべて『オブジェクト』としておけば『ラッパクラス』そのものが不要」なので....

#3です。

ラッパークラスは、既存のライブラリを流用するときに力を発揮します。

こんにちは。

ラッパー(wrapper)、要は「包む」ことですね。

似たような質問が見つかりました

このQ&Aを見た人はこんなQ&Aも見ています

関連するカテゴリからQ&Aを探す

このQ&Aを見た人がよく見るQ&A

デイリーランキングこのカテゴリの人気デイリーQ&Aランキング

マンスリーランキングこのカテゴリの人気マンスリーQ&Aランキング

　#3です。

　#3です。

　#3です。

　こんにちは。