- - PR -
クラスの拡張が理解できません。
投稿者 | 投稿内容 | ||||||||
---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-06-01 19:33
クラスの拡張が理解できません。
例えばExceptionクラスなのですが、私の頭では下記のように理解しています。 Exception < ArrayIndexOutOfBoundsExceptionとかNumberFormatExceptionなどなど。 ということは、ExceptionではArrayIndexOutOfBoundsExceptionなど独自に拡張している 機能がないのでは。。。 しかし、解説書にはExceptionでもNumberFormatExceptionなどの例外を受け取れています。 また実際そうできます。 | ||||||||
|
投稿日時: 2005-06-01 20:21
実体と概念の捉えかたが逆じゃないでしょうか。
実際存在する実体はNumberFormatException型のインスタンスですが、それをException型として扱うということでは? Exceptionのある一種類としてNumberFormatExceptionというExceptionが存在しますが、NumberFormatExceptionはExceptionのため、Exceptionとして扱うことに不都合はないですよね。 生物のある一種類としてヒトという生物が存在しますが、ヒトは生物のため、生物として扱うことに不都合はないですよね。 果物の・・・(以下略) [ メッセージ編集済み 編集者: 一郎 編集日時 2005-06-01 20:22 ] | ||||||||
|
投稿日時: 2005-06-01 21:02
>実際存在する実体はNumberFormatException型のインスタンスですが、それをException型と>して扱うということでは?
そうです。そういうことです。 ですが、"Exceptionのある一種類としてNumberFormatExceptionというExceptionが存在します"ということが理解できません。 本来、拡張するという事は元のクラスに追加する機能を与える事ではないのでしょうか? おっしゃる事はわかるのですが、構造が理解できてません。 Exceptionという大きな円の中にNumberFormatExceptionやその他のクラスが存在すると いうことなのでしょうか?解説書ではこの逆です。 | ||||||||
|
投稿日時: 2005-06-01 21:08
多分ポリモーフィズムのところで引っかかってるんだと思います。
ぜひ、「オブ脳」の「社長命令、起立]をやってみてください。 それはともかく、オブジェクト指向でのスーパークラス(元の場合はException)は下のクラスの共通部分をくくりだした上位概念です。 つまり、計算での例外だろうが、DBでの例外だろうが例外という概念に含まれるということはいっしょです。 そのため、もともとの例外では全ての例外で必要とされるであろう機能をすでに用意しています。 NumberFormatExceptionをExceptionで受けた場合にはこの用意された共通機能を使うことができます。 _________________ http://aglabo.com/ @Homepage http://furukawa-select.com/mt/ @Blog | ||||||||
|
投稿日時: 2005-06-01 23:11
> Exceptionという大きな円の中にNumberFormatExceptionやその他のクラスが存在すると
> いうことなのでしょうか?解説書ではこの逆です。 Extend(拡張、継承)には2つの見方があり、どちらも正しいです。 1.「NumberFormatException」は「Exception」の一種である。 これが「Exceptionという大きな円の中にNumberFormatExceptionやその他のクラスが存在する」です。 2.「NumberFormatException」は「Exception」の機能をすべて持っている。 これは逆に「NumberFormatExceptionという円の中にExceptionが存在する」です。 ……てな説明ではいかが? | ||||||||
|
投稿日時: 2005-06-02 00:07
例えば、携帯電話を考えてみてください。 携帯電話にテレビの機能も付いたテレビ携帯電話を作ったとします。 テレビ携帯電話は携帯電話ですか?イエス。テレビの機能を使わずにただの携帯電話として扱うことができます。 ただの携帯電話の仕事を果たすための十分な機能を持っています。 ある物がテレビ携帯電話であれば、それは必ず携帯電話です。 逆に携帯電話は必ずテレビ携帯電話というわけではありません。 つまり、 テレビ携帯電話 ⊂ 携帯電話 ということです。 テレビ携帯電話の集合は携帯電話という集合のある一部分ということになります。 未記入さんの見ている解説書の図は、携帯電話とテレビ携帯電話それぞれの実体の機能の範囲を図示したもので、集合の範囲について表現したものではありません。
私が、未記入さんが取り違えているんじゃないかと思ったのはこの部分です。 「Exceptionで受け取れ(る)」というのは、Exception型の実体にNumberFormatExceptionの仕事をさせているわけではなくて、メモリ上に存在する実体はNumberFormatExceptionでもコード上ではExceptionとして参照し、Exceptionの機能しか使っていないということですよね。 テレビの機能を使わずにただの携帯電話として扱うことに問題がないのは上で書いた通りです。 [ メッセージ編集済み 編集者: 一郎 編集日時 2005-06-02 00:09 ] | ||||||||
|
投稿日時: 2005-06-02 00:13
javaは詳しくないけど、こう言う事じゃぁないかな?
例として挙げている「Exception」は、丁度
これにあたって。説明上「解らない」という言葉に置き換えますね。 「解らない」とは非常に使い道のある言葉だけど、逆にその言葉からは細かな対応が出来ません。 そこで、この「解らない」の定義を拡張する訳です。 例1:説明文書が英語で解らない。 例2:説明文からイメージはつくのだが、如何利用すればいいか解らない。 例3:機能構成も利用手順も解った、でも利用する想定場面がイメージできずに解らない。 拡張と聞けば、機能拡張がイの一番に思いつくけど。 この様に定義を具体化する意味、つまり文書を拡張(追加文)ともいえますね。(強引かな?) 話の流れで、「解らない時は行動する前に質問をする事。」と言われたときは 「解らない」とはどういう事ですか?とは聞きませんよね。 でも質問している時に単に「解らない」とだけ連呼されていては対応のしようが無い事を 想像して頂けると思います。 つまり、この様に定義とは利用される想定場面によっていい加減な定義であったり、 厳密な定義であったり、段階的な具体性がある方が何かと融通が利く訳です。 もしかするとクラスをグループと考えるよりは、段階的な具体性を定義出来るモノと 考えた方が楽チンでは無いかなぁと思います。 Exceptionの様に、より曖昧な定義で一色単に処理したい時もあれば、 NumberFormatExceptionの様に、より具体的な定義で細かな対応をしたい時もある。 って事で。 | ||||||||
|
投稿日時: 2005-06-02 01:25
るぱんです。
分類と機能をごっちゃに考えてませんでしょうか? 分類:制約が外れれば外れるほど抽象的になっていく →「つまり、一言でくくると〜みたいなもの」=一言にするとなんでもくくれる 機能:機能が追加される=制約が追加される 分類上では詳細分類のそのまた詳細分類の・・・。 制約が外れれば外れるほど表現する単語の数が減っていく。 表現する単語の数が増えれば増えるほど、 具体的になる。 機能が増えると一般的に「拡張された」と表現する。 疑問点は、 「機能が少ないのに何故ボスとして君臨できるのか?」ってなことだと感じました。 でも、このへんは、言葉のあやに引っかかってると思うんです。 一つの視点を二つに割ってみると面白いかもしれません。 |