K.Maebashi's BBS

うわ、こりゃまた思わぬ方から。 ごぶさたしております。 お買い上げいただきありがとうございました。 昨晩の飲み会は行きたかったのですが、[169]で書いたようにその日はちゃんと 寝てなかったので、帰宅してしまいました。 サイン、というか名前を書くぐらいいくらでもしますので、次の機会(どうせ 頻繁にあるでしょう)でお会いしましょう。

　前橋さん、プログラミングの本は私には難しいのですが、最近だされた本は私でも読めそうでしたので買いました。　今度お会いする機会があった時、著書にサインしてください。

>こう考えると、このケースでも多重継承は不要ですねえ。 よく考えてみたら前橋さんのおっしゃる通りでした...。 さすがです。 >Perlは詳しくないですが、PerlからCを呼ぶことぐらいはできるはずなので、 >ラクダ本第2版を今見てみました。perlxstutというキーワードが出てきたので >Googleして見つかったのがこちらです。 > >http://www.kt.rim.or.jp/~kbk/perl5.005/perlxstut.html ありがとうございます。参考になります。 買って読んでいない本がだいぶたまってきたので、 また色々勉強して、その内投稿するかもしれません。 ありがとうございました。 「オブジェクト指向開発講座」を超える本を期待しています。

>はじめまして、前橋さん。 はじめまして。 >『センス・オブ・プログラミング』を読ませていただきました。 >初心者の私にとって、とても示唆に富む面白い本でした。 ありがとうございます。大変励みになりますです (_o_) …が、これ以上何を書いてよいかわからないので、大変嬉しいのですが こういう投稿への返答には困るのでした。f(^^;;

>1)インターフェース継承による多重継承によりWINDOWを表す方法 >2)集約によりWINDOWをもつ方法 >の2つでは、若干違いがあると思います。 >クラスのクライアント側から見た場合、2)の場合、あくまでも外面は >TREE_NODEであり、WINDOWではない訳です。 ちょっと今まで出た案を整理しますね。 案1)多重継承。WINDOWがSCREEN_OBJECTとTREE_NODEを多重継承する。 案2)インタフェースと委譲を使う。WINDOWはSCREEN_OBJECTを継承し、 　TREE_NODEインタフェースを実装する。 　TREE_NODEの実装はTREE_NODE_IMPLクラスにあって、WINDOWは 　TREE_NODE_IMPLへの参照を保持し、add_child()などのメソッドを 　そっちに委譲する。 案3)コレクションクラスTREEを作り、そのTREE_NODEがWINDOWへの 　参照を保持するようにする。 案3)は、私がうっかりこれでいいかと思っちゃった案ですが、WINDOWの場合は ダメです。たとえばWINDOWのrepaint()メソッドが呼び出されたとき、 WINDOWは自分の子を再帰的にrepaint()しなければなりません。 つまり、「外から見て木構造に見える」のではダメで、 WINDOW自身が自分の子を知っていないといけないわけで、 TREE_NODEからWINDOWに参照を持つような構造では困ります。 案2)ですが、この方法で、外から見れば多重継承と実質同じことができますが、 考えてみれば、外から見て、WINDOWがTREE_NODEに見えて嬉しいことは なさそうなので、わざわざinterfaceを使う必要はなさそうです。 つまり委譲だけでよいと。で、何に委譲するかですが、TREE_NODE_IMPLなんぞ 作らなくても、ArrayListで良いような… こう考えると、このケースでも多重継承は不要ですねえ。 >ところで、知っていたら教えてほしいのですが、PerlとCのリンク方法で >詳しいページとか書籍とかあったら教えてほしいです。 >つまりCのメモリ上にPerlで処理したデータを取得したいのです >(外部ファイルとか、ソケットなどを使わずに)。 Perlは詳しくないですが、PerlからCを呼ぶことぐらいはできるはずなので、 ラクダ本第2版を今見てみました。perlxstutというキーワードが出てきたので Googleして見つかったのがこちらです。 http://www.kt.rim.or.jp/~kbk/perl5.005/perlxstut.html

「飲み会以外では飲まない」という軟弱な断酒中ですが、木曜の晩は飲み会で、 日付が変わる頃帰宅して風呂に入って、朝の5:00頃目がさめました。風呂の中で。 というわけで昨晩も帰宅後即寝てしまったので返事が遅れましてすみません。 # ていうか他のどなたかが答えてくれてもいいような… >ここでは、真となるファイル名のみをtopfnameの配列に格納したいのですが >配列の長さも真となるファイルの個数になるようにしたい。 >現在の状態だと、topfnameのサイズを「10」と定義しているので、これをなんとか >真となるファイルの個数をサイズにしたいのですが、どのようにすればよいでしょうか？ Javaの配列は拡張できないので、java.util.ArrayListクラスあたりを 使えばよいでしょう。 で、最終的に配列が欲しければ、 String[] s = (String[])arrayList.toArray(new String[0]); で変換します。 このへんのことは「Java謎+落とし穴徹底解明」のp.329あたりに書いてあります。

はじめまして、前橋さん。 『センス・オブ・プログラミング』を読ませていただきました。 初心者の私にとって、とても示唆に富む面白い本でした。 これからもがんばってください。 では。

ツリーがあまりに長くなってしまったので新しく投稿させていただきました。 現在,配列の格納の仕方で迷っています。 下にプログラムを表記します。 import javax.xml.parsers.*; import org.xml.sax.*; import org.xml.sax.helpers.*; import java.io.*; public class Q extends DefaultHandler { public static void main(String[] argv) { BufferedReader br = null; String fname; int l=0; int k=0; String[] topfname=new String[10]; //キーワードとなる文字列 String[] r={"空"}; try { br = new BufferedReader ( new InputStreamReader ( new FileInputStream( "fname1.txt" ), "SJIS" ) ); //ここでfname1.txtに表記されているファイル名を順番（1行ずつ）に抽出 while( ( fname = br.readLine() )! = null) { 　　　　　　 　　　　　　//XML検索で抽出プログラムを呼び出し KnowledgeExtract myKnowledgeExtract=new KnowledgeExtract(); 　　　　　　 　　　　　　//ファイル名とキーワードを送り,戻り値として真偽を取得 boolean xxx=myKnowledgeExtract.Ext(fname,r) ; System.out.println(xxx+" "+"top:"+fname); //ここが問題点・・ 　　　　　　if(xxx){topfname[l]=fname;l++;}else{} } } catch( Exception ex ) { ex.printStackTrace(); } //truuになったファイル名を表示 for (int i=0; i < topfname.length ; i++) System.out.println("topfname:"+topfname[i]); } ここでは、真となるファイル名のみをtopfnameの配列に格納したいのですが 配列の長さも真となるファイルの個数になるようにしたい。 現在の状態だと、topfnameのサイズを「10」と定義しているので、これをなんとか 真となるファイルの個数をサイズにしたいのですが、どのようにすればよいでしょうか？

>MAYERさんのはこっちですね。品切れ、中古もなしですねえ… 手に入らないとなると余計にほしくなります。 いろいろと探してみます...。 >>>一瞬納得しそうになりますが、TREE_NODEが、その要素への参照を持てば >>>済む話ですよね。EiffelにはGenericsがあるわけですし。 > >>委譲が面倒でなければ前橋さんのやり方の方が柔軟性ありそうですね。 > >うむむ。私が書いたやり方は、実は普通にコレクションクラスライブラリに >オブジェクトを突っ込む方の意味のつもりでしたが、WINDOWは本質的に >親子関係を持つわけですからadd_child()とかはWINDOW側に付くべきですよね。 ># ていうかWINDOW自身が自分の子を知らないと困るわけで… ># 今回いろいろぼけてました。 > >てなわけでinterfaceにして委譲することになるわけですが、 >面倒だという意見もあるでしょう。 コレクションライブラリにオブジェクトを突っ込むということで Genericsがあるという意味がやっと分かりました。 しかし自分で書いておいて後からよく考えてみると、 1)インターフェース継承による多重継承によりWINDOWを表す方法 2)集約によりWINDOWをもつ方法 の2つでは、若干違いがあると思います。 クラスのクライアント側から見た場合、2)の場合、あくまでも外面は TREE_NODEであり、WINDOWではない訳です。 クライアントクラスに渡す場合、WINDOWとして処理したい場合でも クライアントは、TREE_NODEとして受け取らなくてはならないからです。 TREE_NODEからGetterでWINDOWを取り出し、渡すという方法もありますが、 あまり気楽に渡したのでは参照を保持する意味がありません。 1)と2)は機能的には同じですが、外面という意味では違いそうです。 恐らく一般的に、実装継承と比較すると集約の方が柔軟性あるということですね。 前橋さんのコレクションクラスを利用する方法は一番シンプルだと 思いますが、前橋さん自身がおっしゃってるように、真面目に考えると 本来WINDOWクラス自身に持たせたい機能を他で持つのはあまり 好ましくないかもしれません。 >>テストケースを書く前に決まっているとすると、結局は初めにUMLありき >>なので、テストケース自体単なる動作チェックもしくは、 >>後でリファクタリングをするのだけが目的ということになり、 >>あまりおいしくはなさそうです。 > >うーん、UMLで言えば、クラス図よりは後だけどシーケンス図よりは前というか。 >また、いつでも気楽に自動テストができるなら、それだけでもおいしいと思います。 確かにそうかもしれません。使い方次第ですかね？ ところで、知っていたら教えてほしいのですが、PerlとCのリンク方法で 詳しいページとか書籍とかあったら教えてほしいです。 つまりCのメモリ上にPerlで処理したデータを取得したいのです (外部ファイルとか、ソケットなどを使わずに)。 前橋さんに聞くのはどうかとも思いましたが、特にCのプログラミングのことなら 知らないことないというイメージだったので...。 もし知っていたらで結構です。

ありがとうございます。。できました。また基本的な質問だったかもしれません 11月27日に投稿してから5日たちました。 最初は、javaなんて聞いた事がある程度だったんですが、 ここまでプログラムを完成できるように指導してくださって有難うございます。 以前（ぱ）さんがお話していた。 引数をキーワード及びファイル名にして 戻り値の型をbooleanにして真偽を返す事に成功しました。

>この場合return文のsyutokusuとkeyが認識せず、 >どのようにすればsyutokusuとkeyを認識し返せるのでしょうか？ 変数のスコープ(見える範囲)は、その宣言を囲む最小のブロック({}で囲まれた範囲)で 終わってしまうので、syutokusuとkeyの宣言をtryのブロックの外に出せばよいです。

>私が間違っているのかもしれませんが、恐らく同一な書名なのですが、 >バートランド・マイヤーさんのではありません。 うわわ、すみません、うっかりしてました。 MAYERさんのはこっちですね。品切れ、中古もなしですねえ… http://www.amazon.co.jp/exec/obidos/ASIN/4756100503/qid=1101915980/sr=1-38/ref=sr_1_2_38/249-6600035-2383509 >>一瞬納得しそうになりますが、TREE_NODEが、その要素への参照を持てば >>済む話ですよね。EiffelにはGenericsがあるわけですし。 >委譲が面倒でなければ前橋さんのやり方の方が柔軟性ありそうですね。 うむむ。私が書いたやり方は、実は普通にコレクションクラスライブラリに オブジェクトを突っ込む方の意味のつもりでしたが、WINDOWは本質的に 親子関係を持つわけですからadd_child()とかはWINDOW側に付くべきですよね。 # ていうかWINDOW自身が自分の子を知らないと困るわけで… # 今回いろいろぼけてました。 てなわけでinterfaceにして委譲することになるわけですが、 面倒だという意見もあるでしょう。 >テストケースを書く前に決まっているとすると、結局は初めにUMLありき >なので、テストケース自体単なる動作チェックもしくは、 >後でリファクタリングをするのだけが目的ということになり、 >あまりおいしくはなさそうです。 うーん、UMLで言えば、クラス図よりは後だけどシーケンス図よりは前というか。 また、いつでも気楽に自動テストができるなら、それだけでもおいしいと思います。

>同じ要領でelementlistからelementのElementを取り出して、そこからさらに >getElementsByTagName()を呼び出せば、elementの子のpretestを取り出すことが >できるでしょう。 （ぱ）さん！！！やりました！！何とか動きました～(^o^)ｖ 有難うございます。keyさんも有難うございます。 後は、戻り値として真偽をbooleanに返すだけだす。。 しかしちょっとここで問題が起こりましたです。。 例えば下に自作で創った簡単なサンプルプログラムを記述します。 class T { 　　　public boolean tyu(int h) { 　　　　　try { 　　　　　　　　int syutokusu,key; 　　　　　　　　syutokusu=2; 　　　　　　　　key=h; 　　　　　　　　System.out.println(syutokusu); 　　　　　　　} 　　　　　catch (Exception e) 　　　　　　　 { 　　　　　　　　e.printStackTrace(); 　　　　　　　　} 　　　　　return (syutokusu==key); 　　　　　　　　　　　　　　　　　} 　　　　　} この場合return文のsyutokusuとkeyが認識せず、 どのようにすればsyutokusuとkeyを認識し返せるのでしょうか？ try文の内部で処理した（定義した方や変数は使えないのかな？？） なんかまた間違えてるのかな？

>うわ、絶版でしたか。知りませんでした。 > ># amazonで中古品が買えるようではありますが。 >http://www.amazon.co.jp/exec/obidos/tg/detail/offer-listing/-/4274075400/all/ref=sdp_srli_u/249-6600035-2383509 ご紹介ありがとうございます。ページ拝見しました。 私が間違っているのかもしれませんが、恐らく同一な書名なのですが、 バートランド・マイヤーさんのではありません。 上記の本は、日本人が書いた本だと思います。 中古品とかで色々探してみます...。 >インタフェースの多重継承はよく使いますよね。 Javaのイメージで話してたので勘違いしていました。 私が言いたかったのは実装継承による多重継承のことでした。 確かにインターフェースの多重継承は必要ですね。 >継承関係は、スーパークラスの分類とも言えますから、複数の軸について >分類したければ多重継承になる…という考え方もありますが、 >それをやるとクラスの数が掛け算で増えていくので実用的ではないと私は思います。 なるほど...。難しいですね。 >「オブジェクト指向入門」では、階層構造を持てるWINDOWが、 >SCREEN_OBJECTとTREEを多重継承するという例が出ています(このTREEは、 >TREE_NODEと呼ぶべきだと思う)。 >一瞬納得しそうになりますが、TREE_NODEが、その要素への参照を持てば >済む話ですよね。EiffelにはGenericsがあるわけですし。 委譲が面倒でなければ前橋さんのやり方の方が柔軟性ありそうですね。 私は1つのクラスに複数の役割を持たせるのはあまり好きではありません。 ただし本に載っているサンプルは実装を簡単にするため (あるいは、インターフェースの多重継承の説明のため） なのかもしれないですね。 >テストファーストって、設計の前にテストケースを書くということではなく、 >実装の前にテストケースを書くのでは。メソッドの引数など細かいところは >テストケースを書きながら詰めていく面もあるでしょうけど、 >クラス間の関係のような重要な点は、テストケースを書く前に決まっていると思います。 確かに実装の前にテストケースを書くのだと思うのですが、 テストケースを色々書いていく内に必要なクラスと不要なクラスが 浮かび上がってきてクラスの関係が導きだせるという感じだったと思います。 テストケースを書く前に決まっているとすると、結局は初めにUMLありき なので、テストケース自体単なる動作チェックもしくは、 後でリファクタリングをするのだけが目的ということになり、 あまりおいしくはなさそうです。 ># テストファースト、良いと思うんですが、現場ではなかなか。 ># 私の場合、「使用例」として、Wordでせこせこサンプルコードを書いて、 ># レビューを通してから若いのに実装してもらうことが多いような。 私は仕事では数値計算関係のプログラムを作成することが多く、 テストケースを作成しにくいです(つまりテストケース自体のテストをしないと いけないので)。 ただ無理にでも使っていかないと、結局使う機会がなく勉強にならないので なかなか難しいです。 前橋さんは若い人に実装してもらえるのはいいですね。 私の場合、小さいチームなのでそこまではいきません。 以前別の部署の後輩にやってもらったら余計仕事が遅くなりました。 やはり上司はブルックスの法則を理解していないのだと思いました。 最近「人月の神話」を購入して、XPの考え方の基になったという印象が あります。XPの歴史とか知らないので何とも言えないですが。 前橋さんは、他の人に仕事を手伝ってもらったら余計遅くなったこと ありませんか？

>ちなみに、買った帰りにぺらぺらめくって眺めていたんですが、第3章の扉絵を見た瞬間 >吹き出してしまいました。・・・電車の中で。 > ># 本筋と関係ない話ですみません。 本筋とは関係ないんでしょうが、ここに反応していただけるとムチャクチャ嬉しいです。 かなり狙って描いたので w >「なぜオブジェクト指向が生まれたのか」という経緯を、自分の中で追体験するような >形で学ばないと、そのありがたみもわからないのかな、などと、最近思ったりもします。 そう思います。そういう意味じゃ、BASICなどの経験も無駄ではなかったかも。

>私はオブジェクト指向勉強中の身なので色々勉強はしていて、 >バートランド・マイヤーさんの「オブジェクト指向入門」も >絶版のため結局買えてません。英語は面倒ですし...。 うわ、絶版でしたか。知りませんでした。 # amazonで中古品が買えるようではありますが。 http://www.amazon.co.jp/exec/obidos/tg/detail/offer-listing/-/4274075400/all/ref=sdp_srli_u/249-6600035-2383509 >私はartonさんと前橋さんの本が気に入っています。 >「C言語ポインタ完全制覇」でCに開眼したので。 ありがとうございます (_o_) >ところで、多重継承って使ったことないのですが必要な機能なのでしょうか？ >使う目的が分かりません。 インタフェースの多重継承はよく使いますよね。 継承関係は、スーパークラスの分類とも言えますから、複数の軸について 分類したければ多重継承になる…という考え方もありますが、 それをやるとクラスの数が掛け算で増えていくので実用的ではないと私は思います。 「オブジェクト指向入門」では、階層構造を持てるWINDOWが、 SCREEN_OBJECTとTREEを多重継承するという例が出ています(このTREEは、 TREE_NODEと呼ぶべきだと思う)。 一瞬納得しそうになりますが、TREE_NODEが、その要素への参照を持てば 済む話ですよね。EiffelにはGenericsがあるわけですし。 >テストケースを書くことで本当にクラスの設計ができるのでしょうか？ >クラスの設計って経験がものをいうというイメージだったのですが。 テストファーストって、設計の前にテストケースを書くということではなく、 実装の前にテストケースを書くのでは。メソッドの引数など細かいところは テストケースを書きながら詰めていく面もあるでしょうけど、 クラス間の関係のような重要な点は、テストケースを書く前に決まっていると思います。 # テストファースト、良いと思うんですが、現場ではなかなか。 # 私の場合、「使用例」として、Wordでせこせこサンプルコードを書いて、 # レビューを通してから若いのに実装してもらうことが多いような。

>>>Elementを取り出すとは、何でしょう？ … >Element element = (Element)pretestlist.item(i); >これは、item(i)⇒要素を順番に取得していくという意味ではないかとお思います つまりここでpretestの要素(Elementオブジェクト)が取り出せているわけですよね。 getElementsByTagName()はElementのメソッドです。 前回の神奈川さんのプログラムは、NodeListのgetElementsByTagName()を 呼ぼうとしていて、NodeListにそんなメソッドはないのでエラーになっていたわけです。 同じ要領でelementlistからelementのElementを取り出して、そこからさらに getElementsByTagName()を呼び出せば、elementの子のpretestを取り出すことが できるでしょう。 # ElementはJavaの(DOMの)クラスで、elementは神奈川さんが書いているXMLの # 要素名です。念のため。

>仮にAPIリファレンスを見なくても、getElementByTagName()がElementの >メソッドである、ということは、神奈川さん自身が投稿したソースを見れば >わかることですし。 あー。。 スレッド別表示にして見ていたので、下の方にひょろっとあった[145]の投稿に 気づかず、それを読まずに投稿してしまいました。（気付けよ、自分） ・・・と言うか神奈川さん、すでに答えをご自分で（ほぼ）書いていたんですね。。 >神奈川さんが越えるべきハードルはたくさんありそうです。 実は、僕もそれを感じたので >>神奈川さんが抱えている問題は複数あるように感じます。 って書いちゃいました、なんだか偉そうに。 >プログラムを書くには、まず自分が「何をしたいのか」を日本語でちゃんと >説明できなければならない、なんてことは「センス・オブ・プログラミング!」にも >書きましたけど。 実は、「センス・オブ・プログラミング!」は購入済みなんですが、忙しくて ほとんど読めていなかったりします。すみません。せっかく10月29日に買ったのに！ ちなみに、買った帰りにぺらぺらめくって眺めていたんですが、第3章の扉絵を見た瞬間 吹き出してしまいました。・・・電車の中で。 # 本筋と関係ない話ですみません。 >今時の入門者は、「梯子が外された」状態にあるのかもしれません。 それは、良く感じます。 僕は運良く、プログラムを始めた時期に前橋さんの本で学ぶことが出来たわけですが、 同時期にプログラムを始めた人間は、研修でいきなり「StrutsでWebアプリケーション」 だとか、そんなことを勉強させられたりしたようです。 そう言えば、「オブジェクト指向で全ては抽象化されているんだから、細かい アルゴリズムなんて覚える必要は無い！」とか、トンでもなことを言い出している 上司もいました。 「なぜオブジェクト指向が生まれたのか」という経緯を、自分の中で追体験するような 形で学ばないと、そのありがたみもわからないのかな、などと、最近思ったりもします。 で、「センス・オブ・プログラミング!」には、きっとそんなことが書かれているのかなぁ などと妄想してみたり（笑） # うーん、「溝」という話題とは微妙にそれてしまったような。。

隠れファンです。 返信ありがとうございます。 >これはその通りでしょう。でもまあ、それで細部は隠せても、 >大まかなところはオブジェクト間の関係のような形で見えてしまいますし。 >多重度の設計をしくじって拡張の際にはまる、なんてことは多いですよね。 ># Hogeに対してPiyoはひとつでよいはずだったのに、今度の機能拡張では ># n個にしなきゃいけなくなった。HogeのgetPiyo()には引数ないぞ。どうしてくれよう。 私は設計に失敗した場合、その部分を作り直してしまった方が早いと思っています (もちろん関連が多すぎるなど、そうできない場合も多いと思います)。 例えばクラスをラップしていって機能を追加してうまくごまかして 無理やりつじつま合わせようとしてもどんどん泥沼にはまりそうです。 >オブジェクト指向のバイブルは、私にとってはMAYERさんの「オブジェクト指向入門」 >でした。第2版は(買いはしたものの)まるで読めてませんけど。 ># なにせ英語なので… (^^;; > >継承がらみの議論では(特に多重継承)首をひねるところもありますが、 >今でも名著だと思います。 私はオブジェクト指向勉強中の身なので色々勉強はしていて、 バートランド・マイヤーさんの「オブジェクト指向入門」も 絶版のため結局買えてません。英語は面倒ですし...。 ご存知だと思いますが、オブジェクト指向の本では 「憂鬱なプログラマのためのオブジェクト指向講座」が売れているみたいですが 今ではほとんど役に立たないと思っています。 最近購入した「アジャイルソフトウェア開発の奥義」という本は かなり気に入っていて新たな発見がありそうです。 私はartonさんと前橋さんの本が気に入っています。 「C言語ポインタ完全制覇」でCに開眼したので。 ところで、多重継承って使ったことないのですが必要な機能なのでしょうか？ 使う目的が分かりません。 あとテストファーストについてどう思われますか？ 本を読んでると何かよさげなのですが...。 テストケースを書くことで本当にクラスの設計ができるのでしょうか？ クラスの設計って経験がものをいうというイメージだったのですが。

>>Elementを取り出すとは、何でしょう？ > >[145]で神奈川さんが投稿されたリストの、 > > Element element = (Element)pretestlist.item(i); > >この部分は、どういう意味だと思って書いていましたか? 皆さん私のために親身に教えてくださって有難うございます。（TOT) （ぱ）さんの仰ったとおり「溝」に陥っているのかもしれません。。 Element element = (Element)pretestlist.item(i); これは、item(i)⇒要素を順番に取得していくという意味ではないかとお思います 例： タグpretestに対して item(０)が１番初めpretest要素取得 item(１)が２番目のpretest要素取得 とこのような感じだと思ったのですが、この状態だと全ての＜pretest＞タグ要素 を取得してしまう気がするんですけど。 間違っているでしょうか？？

>隠れファンです。 >勝手に返信させて頂きます。 どうもです f(^^;; >但し、重要なデータほど >オブジェクト指向ではインターフェースを利用しモジュールを分離するので、 これはその通りでしょう。でもまあ、それで細部は隠せても、 大まかなところはオブジェクト間の関係のような形で見えてしまいますし。 多重度の設計をしくじって拡張の際にはまる、なんてことは多いですよね。 # Hogeに対してPiyoはひとつでよいはずだったのに、今度の機能拡張では # n個にしなきゃいけなくなった。HogeのgetPiyo()には引数ないぞ。どうしてくれよう。 >オブジェクト指向の実装よりではなく設計よりの内容でのバイブルを作れるのは オブジェクト指向のバイブルは、私にとってはMAYERさんの「オブジェクト指向入門」 でした。第2版は(買いはしたものの)まるで読めてませんけど。 # なにせ英語なので… (^^;; 継承がらみの議論では(特に多重継承)首をひねるところもありますが、 今でも名著だと思います。

また件名かえました。 >・ DOMのAPIドキュメントをちゃんと読んでいない。 > >というのが差し当たっての問題のように思えます。 それもそうだと思うのですが、 >「なぜ、NodeListに対してgetElementsByTagName()が出来ないのか」 という言葉の意味がわかるなら、そしてAPIリファレンスの何たるかを知っていれば、 別に熟読しなくても、その部分だけでも読みそうなもんですし、 仮にAPIリファレンスを見なくても、getElementByTagName()がElementの メソッドである、ということは、神奈川さん自身が投稿したソースを見れば わかることですし。 神奈川さんが越えるべきハードルはたくさんありそうです。 以下、別に神奈川さんを責めているわけではありません。 「闘わないプログラマ」に「溝」という文章がありますが、 http://www.amy.hi-ho.ne.jp/~lepton/program/p1/prog181.html 神奈川さんの最初の投稿の >ファイルを格納するということは、できるのでしょうか？ というのを読んで私が連想したのが実はこの文章でした。 質問者の側に知識が不足していると、往々にしてこういうことは起こってしまうわけで、 じゃあどうすればいいのかというと、私もLeptonさんと同じく「名案は無いですねえ」 状態なわけで。 本なんか書いてる身としては、こんなこっちゃいかんわけですが。私のほうにセンスが 足りてないんでしょう。 プログラムを書くには、まず自分が「何をしたいのか」を日本語でちゃんと 説明できなければならない、なんてことは「センス・オブ・プログラミング!」にも 書きましたけど。 正直、APIリファレンスの読み方がわからない人が、XMLを解析してどうこうする プログラムを書くのは難度が高すぎやしないか、と思うわけですが、 現代の初心者にはありがちな話のような気がします。 私がプログラミングを始めた頃は、そんな複雑なAPIもなく、そもそもそんな 凝ったことをするマシンパワーもなくて、簡単なプログラムから順次入門して いったわけですが、今時の入門者は、「梯子が外された」状態にあるのかもしれません。 うーん。まとまらなくてすみません。

>Elementを取り出すとは、何でしょう？ [145]で神奈川さんが投稿されたリストの、 Element element = (Element)pretestlist.item(i); この部分は、どういう意味だと思って書いていましたか?

> 神奈川さん こんにちは。 スレッドを拝見していて思ったんですが、神奈川さんが抱えている問題は 複数あるように感じます。 が、とりあえずは ・ DOMのAPIドキュメントをちゃんと読んでいない。 というのが差し当たっての問題のように思えます。 Javaでプログラミングをする時は、APIドキュメントを読むことが必須だったりします。 「なぜ、NodeListに対してgetElementsByTagName()が出来ないのか」理由が わからないのでしたら、前橋さんがご提示してくださったDOMのAPIドキュメントを 読み返してみてはいかがでしょうか？ そうすれば、次に自分が何をすべきか見えてくると思いますよ。 ヒントを書くと、「NodeListの2つのメソッドを組み合わせて使えば。。」って 感じです。 # って、なんか偉そうですね。。すみません。 それから、今回はもう間に合わないと思いますが、世の中にはxmlとJavaオブジェクトの バインディングのためのライブラリなども存在しますので、次回はそういったものも 勉強してみると、同じことが楽に出来るかもしれないですよ。

>> NodeList pretestlist = elementlist.getElementsByTagName >... >>しかしこの状態だとエラーが発生してしまいました・・ > >そりゃNodeListに対してgetElementsByTagName()はできないでしょう。 >Elementを取り出してからにしないと。 たびたびすみません。 うーん・・解らないですね。。 Elementを取り出すとは、何でしょう？ どうすれば、elementの下のpretestのみを取得できるのでしょう？ 僕のイメージは、親を指定して例えば（element） その後に子を指定する（pretest）を行って初めて、 そのpretestにたどり着くようなイメージがあるのですが、 とんでもない勘違いをしているのでしょうか？ Element root = doc.getDocumentElement(); ⇒ルート要素取得（ドキュメントの下のノードを取得したことになりますよね？） NodeList list = root.getElementsByTagName("タグの名前"); ⇒タグの名前要素のリストを取得（ルート要素で取得したノードに対してタグの名前要素のリス　　　　　　　　　　　　　　　　トを取得） リストを取得して⇒ノードを取得⇒リストを取得して⇒ノードを取得 を繰り返す事で末端の要素にたどり着くのでしょうか？ すみません。。ほんとに解らなくて・・・ここさえ解れば、あとは何とか成りそうなんですが・・（実は、ものすごい単純なのかもしれませんが宜しくお願いします） 下のようなxmlならば、elementの下のpretestを指定する。 （後はitemごとにtextを取得するこれ自体は、可能） <?xml version="1.0" encoding="Shift_JIS" ?> <site> <title>JavaでHello World</title> <element id="28"> <pretest id="28"> <title>EJB編</title> <file>ejb.htm</file> </pretest> <pretest> <title>DOM編</title> <file>xmldom.htm</file> </pretest> </element> <element1 id="28"> <pretest id="28"> <title>neko</title> <file>neko.htm</file> </pretest> <pretest> <title>DOMneko編</title> <file>xmldomneko.htm</file> </pretest> </element1> </site>

> NodeList pretestlist = elementlist.getElementsByTagName ... >しかしこの状態だとエラーが発生してしまいました・・ そりゃNodeListに対してgetElementsByTagName()はできないでしょう。 Elementを取り出してからにしないと。

有難うございます＾＾ あまり理解できなくすみません。 >まずelementを見つけて、そのelementに対して >getElementsByTagNameをやればよいだけの話では? とのことでしたので、（先ほど記述したプログラムの一部を抜粋） DocumentBuilder builder = dbfactory.newDocumentBuilder(); // パースを実行してDocumentオブジェクトを取得 Document doc = builder.parse(new File("site.xml")); // ルート要素を取得（タグ名：site） Element root = doc.getDocumentElement(); // element要素のリストを取得 NodeList elementlist = root.getElementsByTagName("element"); // pretest要素のリストを取得 （elementの下のpretest） NodeList pretestlist = elementlist.getElementsByTagName このようにすればよいのでしょうか？ NodeList pretestlist=elementlist（ここで親を指定するという形でいいのでしょうか？） .getElementsByTagName しかしこの状態だとエラーが発生してしまいました・・ エラー内容は、 java21：シンボルが解決されません シンボル：getElementsByTagName(java.lang.string) 場所：org.w3c.dom.Nodelist NodeList pretestlist = elementlist.getElementsByTagName 　　　　　　　　　　　　　　　　　　＾ とのようになりました。。難しいです。。記述の仕方がまずいのでしょうか？

>難易度って難しい℃なのかやさしい℃なのか、いつもわかりません。 >素直に難度といえばいいのにとか思う今日子の頃。 確かに。 Google検索してみると… 難易度が高い の検索結果 約 34,300 件 難度が高い の検索結果 約 5,350 件 「難易度が高い」の方が多いことは予想していましたが、 「難度が高い」も結構ありますねえ。

件名を変えました。 >>私ならそもそもそういうメソッドは、 >>ファイル名と検索キーワードを引数で受け取って、マッチしたかどうかを >>booleanで返すようにしますけど。 ... >引数は、ファイル名とキーワードは、複数ある場合があるから、配列で示すのかな >？？ キーワードは配列で渡すのでしょうが、ファイル名はひとつだけ渡すことを 想定していました。だから戻り値がboolean 1個でいいわけです。 戻り値は「そのファイルにキーワードが含まれていたかどうか」を表現します。 もちろん、それ以外の情報も返したいなら、booleanではなく、何らかの オブジェクトに値を詰めて返さなければなりません。 で、もちろん検索はたくさんのファイルの中から行いたいのでしょう。 でも、たくさんのファイルでぐるぐるループするのは、このメソッドの 呼び出し側で行えばよい話で、だから >で、フォルダ内のファイル名を片っ端からそのメソッドで判定する、 >という処理は、その一階層上でやらせます。 こう書きました。 >となります。このように「この親（element）のこの子(pretest）」 >という指定はできるのでしょうか？今の状態だと全てのpretestの要素を取得している >ので何とかしたいのですが・・どうぞ宜しくお願いします。 elementとpretestの間に何かが挟まったり、pretestがネストしたりする 可能性がないのであれば、まずelementを見つけて、そのelementに対して getElementsByTagNameをやればよいだけの話では?

>http://www.hellohiro.com/xmldom.htm >このページではDOMの環境構築の話から書いてあります （ぱ）さんの指定したリンク先を元にプログラムを作成してみました。 下は、xmlファイルです。 <?xml version="1.0" encoding="Shift_JIS" ?> <site> <title>JavaでHello World</title> <element id="28"> <pretest id="28"> <title>EJB編</title> <file>ejb.htm</file> </pretest> <pretest> <title>DOM編</title> <file>xmldom.htm</file> </pretest> </element> <element1 id="28"> <pretest id="28"> <title>neko</title> <file>neko.htm</file> </pretest> <pretest> <title>DOMneko編</title> <file>xmldomneko.htm</file> </pretest> </element1> </site> 僕のプログラム public class A { public static void main(String[] args) { try { // ドキュメントビルダーファクトリを生成 DocumentBuilderFactory dbfactory = DocumentBuilderFactory.newInstance(); // ドキュメントビルダーを生成 DocumentBuilder builder = dbfactory.newDocumentBuilder(); // パースを実行してDocumentオブジェクトを取得 Document doc = builder.parse(new File("site.xml")); // ルート要素を取得（タグ名：site） Element root = doc.getDocumentElement(); System.out.println("ルート要素のタグ名：" + root.getTagName()); System.out.println("***** ページリスト *****"); // element要素のリストを取得 NodeList elementlist = root.getElementsByTagName("element"); // pretest要素のリストを取得 NodeList pretestlist = root.getElementsByTagName("pretest"); // pretest要素の数だけループ for (int i=0; i < pretestlist.getLength() ; i++) { // page要素を取得 Element element = (Element)pretestlist.item(i); // title要素のリストを取得 NodeList titleList = element.getElementsByTagName("title"); // title要素を取得 Element titleElement = (Element)titleList.item(0); // title要素の最初の子ノード（テキストノード）の値を取得 String title = titleElement.getFirstChild().getNodeValue(); // file要素のリストを取得 NodeList fileList = element.getElementsByTagName("file"); // file要素を取得 Element fileElement = (Element)fileList.item(0); // file要素の最初の子ノード（テキストノード）の値を取得 String file = fileElement.getFirstChild().getNodeValue(); System.out.println("タイトル：" + title + " " + "ファイル：" + file); } } catch (Exception e) { e.printStackTrace(); } } } というように作成してみました。 そうすると実行結果が、 タイトル：EJB編　ファイル：ejb.htm タイトル：DOM編　ファイル：xmldom.htm タイトル：neko　ファイル：neko.htm タイトル：DOMneko編　ファイル：nekoxmldom.htm となりました。私としては、elementの下にあるpretestのみを取得したいのですが 詰まり実行結果としては、 タイトル：EJB編　ファイル：ejb.htm タイトル：DOM編　ファイル：xmldom.htm となります。このように「この親（element）のこの子(pretest）」 という指定はできるのでしょうか？今の状態だと全てのpretestの要素を取得している ので何とかしたいのですが・・どうぞ宜しくお願いします。 長々と申し訳ありません・・