K.Maebashi's BBS

>私はオブジェクト指向勉強中の身なので色々勉強はしていて、 >バートランド・マイヤーさんの「オブジェクト指向入門」も >絶版のため結局買えてません。英語は面倒ですし...。 うわ、絶版でしたか。知りませんでした。 # 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の要素を取得している ので何とかしたいのですが・・どうぞ宜しくお願いします。 長々と申し訳ありません・・

はじめまして。 隠れファンです。 勝手に返信させて頂きます。 「センス・オブ・プログラミング」読ませて頂きました。 データ構造のあたりの考え方はかなり参考になりました。 >>抽象化・データ構造重視というとまさにオブジェクト指向的な考えですよね。 > >そう思います。「センス・オブ～」はオブジェクト指向の手前で止まっていますが、 >延長線上にある概念だと思います。 >オブジェクト指向を、従来のプログラミング技術と「まるで違う」もので >あるかのように宣伝したがる人も多いようですけど。 私も同感です。プログラミングの本質は言語が何であろうと変わらないと 思っています。「まるで違う」という人の意見は設計ではなく実装よりの ことを言っているのかもしれません。ただし設計と実装の境界が微妙な場合も 多々あると思います。 データ構造に関してですが、私はデータを処理するアルゴリズムがデータ構造に 依存しているために、仕様の変更時にデータ構造の変更は、アルゴリズムの変更も 伴うため、データ構造が重要だと思っています。但し、重要なデータほど オブジェクト指向ではインターフェースを利用しモジュールを分離するので、 結合度をどの程度にするかは結局は他とのバランスだと思っています。 >>オブジェクト指向に関する本もやがて出ると（勝手に）期待してます。 > >えーっと f(^^;; >たぶん私を逆さにして振っても、「Java謎+落とし穴～」に書いてある以上のことは >出てこないと思います。 ># でも、Webページの方も更新しないとなあ。 私も期待しています。特に最近のキーワードでもある「アジャイル開発」や「XP」 あたりのテーマを書いてほしいです。 オブジェクト指向の実装よりではなく設計よりの内容でのバイブルを作れるのは 前橋さんだと思っています。

有難うございます。。 返信遅れてすみません。。 >>実は、XMLファイルの検索のプログラムを作成し様としているのです。 > >ということは、 >・たくさんあるXMLファイルを片っ端から開いて、 >・内容を読み込み、解析し、 >・ある特定のキーワードが、(ある特定のタグの下に)あるファイルを抽出する。 >という動作になりますよね? (合ってますか?) 合ってます。 >私ならそもそもそういうメソッドは、 >ファイル名と検索キーワードを引数で受け取って、マッチしたかどうかを >booleanで返すようにしますけど。 なるほど具体的にいうと例えばどのようなプログラムでしょう？ 簡単な受け取り部分のサンプルプログラムを教えていただけると嬉しいのですが・・ booleanが戻り値 public　boolean　a（引数） 引数は、ファイル名とキーワードは、複数ある場合があるから、配列で示すのかな ？？ アホみたいな質問ですみません・・ >このページではDOMの環境構築の話から書いてあります いいページです。勉強中～。。 >これが「難しくてわけわからない」ということだとすると、 >今の神奈川さんには、ちょっと問題の難易度が高かった、ということだと思います。 初心者なので探り探りです・・・

はじめまして。 >前々から、前橋さんの本は結構気に入っていて、 >全部読んでいます。 ありがとうございます。大変励みになります。 >抽象化・データ構造重視というとまさにオブジェクト指向的な考えですよね。 そう思います。「センス・オブ～」はオブジェクト指向の手前で止まっていますが、 延長線上にある概念だと思います。 オブジェクト指向を、従来のプログラミング技術と「まるで違う」もので あるかのように宣伝したがる人も多いようですけど。 >オブジェクト指向に関する本もやがて出ると（勝手に）期待してます。 えーっと f(^^;; たぶん私を逆さにして振っても、「Java謎+落とし穴～」に書いてある以上のことは 出てこないと思います。 # でも、Webページの方も更新しないとなあ。

はじめまして。 前々から、前橋さんの本は結構気に入っていて、 全部読んでいます。 今回のセンス・オブ・プログラミング！も さっそく読ましていただきました。 今回の本で、抽象化とデータ構造の重要さを改めて認識することができました。 仕事でコーディングする時は、ロジックに焦点がいきがちで、 ついデータ構造がおざなりになってしまいがちなんですよね。 私自身、そこまで意識して、データ構造を明確に意識して設計することは、 あまりなかったなぁと感じて、反省しています。 （でかいグローバルな構造体を用意して、そいつにすべての情報を詰め込み、 あらゆるところから、参照するという「やっちゃいけない」パターンを やってることが多いです。） 抽象化・データ構造重視というとまさにオブジェクト指向的な考えですよね。 オブジェクト指向に関する本もやがて出ると（勝手に）期待してます。 仕事もしながら、執筆は大変だと思いますが、今後もがんばってください。

難易度って難しい℃なのかやさしい℃なのか、いつもわかりません。 素直に難度といえばいいのにとか思う今日子の頃。 燃費がいいってどっち？とか。

>実は、XMLファイルの検索のプログラムを作成し様としているのです。 ということは、 ・たくさんあるXMLファイルを片っ端から開いて、 ・内容を読み込み、解析し、 ・ある特定のキーワードが、(ある特定のタグの下に)あるファイルを抽出する。 という動作になりますよね? (合ってますか?) 抽出した後のファイルをどうするのかわかりませんが、ファイル名(パス)を 表示するだけなら、ファイルを探すメソッドの戻り値は、ファイル名(文字列)で よいように思います。ただ、私ならそもそもそういうメソッドは、 ファイル名と検索キーワードを引数で受け取って、マッチしたかどうかを booleanで返すようにしますけど。 で、フォルダ内のファイル名を片っ端からそのメソッドで判定する、 という処理は、その一階層上でやらせます。 具体的な実現手段を探してうろうろする前に、自分がなにをしたいのかを 明確にしないと、プログラムは書けませんよ。 また、こういうことをしたいのなら、難しいのはむしろXMLのパース(構文解析) でしょうが、XMLの構文解析はDOMなどを使うと簡単です。 JavaでHello World!: http://www.hellohiro.com/xmldom.htm このページではDOMの環境構築の話から書いてありますが、 1.4以降のJavaなら標準で入っています。 APIリファレンスはこちら: http://java.sun.com/j2se/1.4/ja/docs/ja/api/org/w3c/dom/package-summary.html これが「難しくてわけわからない」ということだとすると、 今の神奈川さんには、ちょっと問題の難易度が高かった、ということだと思います。

早速ありがとうございます。＾＾ >本当にやりたいことは、ファイル名から「ファイル」を得ることじゃなく、 >「そのファイルを読み書きするためのナニモノか」を得ることなんじゃないかなあ、 >という気がします(合ってますか?)。 （ぱ）さんは、すごく鋭いですね＾＾ 現在知識の詰め込み中でして・・多々解らない事がありまして。勉強中なんです。。 実は、XMLファイルの検索のプログラムを作成し様としているのです。 前のスレで似たような質問があったみたいですが、僕には解らなくて・・ タグで検索するという形なのですが、 例えば、入力のキーワードを「２ちゃん」とすると（下のxmlファイルを参照して） 下の<a>のタグの下に<b>内にある文字列である「２ちゃん」 を検索してこのxmlファイルを戻り値として返すという感じです。 入力キーワードが2つ以上ある場合は、それをandで計算して、その二つのキーワード が含まれる<a>のタグの下に<b>内にある文字列を検索します。 一致したファイルをxmlファイルを戻り値として返すという感じです。 ******②ちゃん.xml********* <c> 　　　<b>ギコ</b> 　　　<b>おにぎり</b> </c> <a> 　　　<b>２ちゃん</b> 　　　<b>掲示板</b> </a> *************************** 実は、二人で作業していまして、僕がファイルを戻すという作業をすることになったのです。 目的としては、見つけたファイルを戻して終了という感じです。 もしよろしければ、このようなサンプルプログラムとかあるでしょうか？ なければ、どのような本を見れば乗ってるでしょうか？ 宜しくお願いします。

どうも、はじめまして。 ご質問の件ですが、一般に 「自分が何をしたいのか、きちんと日本語で説明できないうちは、 　プログラムは書けない」 と言えます。(ちょうど「センス・オブ・プログラミング!」にそんなことを書きました。) >引数が文字列で,戻り値がファイルというような形です。 ... >「おにぎり」というキーワードを入力 >↓ >ファイル名がおにぎりというファイルを出力 ここだけ読むと import java.io.*; class Test { File hoge(String path) { return new File(path); } } こんなことがしたいようにも読めますが… File f = Test.hoge("hoge.txt"); と呼び出した後で何をしたいのかが不明ですし。 本当にやりたいことは、ファイル名から「ファイル」を得ることじゃなく、 「そのファイルを読み書きするためのナニモノか」を得ることなんじゃないかなあ、 という気がします(合ってますか?)。 だとすれば、Fileではなく、FileInputStreamやFileOutputStreamを使うことになるでしょう。 このへんのクラスの説明については、JavaのAPIリファレンス http://java.sun.com/j2se/1.4/ja/docs/ja/api/index.html を参照してください。 http://java.sun.com/j2se/1.4/ja/docs/ja/api/java/io/File.html http://java.sun.com/j2se/1.4/ja/docs/ja/api/java/io/FileInputStream.html http://java.sun.com/j2se/1.4/ja/docs/ja/api/java/io/FileOutputStream.html

質問ですー JAVAでプログラムを組もうとしています。 JAVAでは文字列や数字などintなどの変数によって格納できますが、 ファイルを格納するということは、できるのでしょうか？ 例えば 引数が文字列で,戻り値がファイルというような形です。 「おにぎり」というキーワードを入力 ↓ ファイル名がおにぎりというファイルを出力 というような形です。 宜しくお願いします。 プログラム初心者なので、出来もしない事を書いてあるかもしれません。 初歩的なことかもしれませんが宜しくお願いします。 そこも踏まえて宜しくです。。

>これは、この構造体の例よりも もっと合法な使い方である、 >単なる可変長配列を realloc() した場合にも起きる問題ですね。 うーん、たとえば折れ線を表現するときに、 typedef struct { int point_count; Point *point; } Polyline; typedef struct { int point_count; Point point[1]; } Polyline; というふたつの実現方法があって、どちらを使うかを考えたとき、 後者の方法だと、pointの数を増減させるたびにPolylineのアドレスが 変わってしまう、ということを言いたかったのですが。 確かにどちらもrealloc()すればpointの指すアドレスは変わりますが、 「pointはPolyline以外誰も指してないけど、Polylineを指してる奴は いっぱいいる」というケースはたぶんたくさんあって、後者の方が 危険度がかなり高いと思います(程度問題にせよ)。 >この手法は、C99 で合法化されたと考えて良いと思います。 >以下参照: >http://seclan.dll.jp/c99d/c99d04.htm#dt19990726 これはそうですね。 そういえばGCCにも、point[0]と書ける拡張機能がありました。

> このテクニックで可変長配列を実現すると、realloc()で配列を > 拡張したとき、 これは、この構造体の例よりも もっと合法な使い方である、 単なる可変長配列を realloc() した場合にも起きる問題ですね。 例としては、むしろ、pArry[1] みたいなアクセスでまずいことに なることを挙げた方がいいような気がします。 > 微妙です。少なくとも合法と言い切ることはできません。 この手法は、C99 で合法化されたと考えて良いと思います。 以下参照: http://seclan.dll.jp/c99d/c99d04.htm#dt19990726

>「センス・オブ・プログラミング」読ませていただきました。 >読んで良かったと思いました。 はじめまして。読んでいただきありがとうございます。 >ところで、可変長配列について説明(P153)がちょっと足りないのでは？ このテクニックは、私も「ポインタ完全制覇」では説明していますが、 今回の本で必要だったかというとどうかと思います。 Cに特化した話ですし(だからこそ「Cに特有の話」の項になら書いてよいのでは、 というご意見なのだと思いますが)、それに、このテクニックは、使用できる 状況が限定されますし。 このテクニックで可変長配列を実現すると、realloc()で配列を拡張したとき、 構造体本体のアドレスまで変わってしまう可能性があります。 よって、この構造体を指しているポインタがどこかにあるときは、 このテクニックは使えません。 また、可変長配列にできる要素が最後のひとつだけ、という問題もあります。 このテクニックを使う機会は、「その構造体を、連続した塊としてファイルに 吐いたり、ネットワークでどこかに送りたい」というケースに限定されるように 思います。 >Ｃではこれが間違いではありません。---① 微妙です。少なくとも合法と言い切ることはできません。 C-FAQには以下の記述があります。 http://www.kouno.jp/home/c_faq/c2.html#6 | この技巧は人気がある。ただしDennis Ritchieは「Cの実装への | 根拠のない馴れ馴れしさ」と呼んだ。公式な解釈によると上の | 技巧は Cの 規格に厳密には準拠していないと考えられる。 私も同じように思います。が、ほぼ全ての環境で動くと思うので、 移植性を根拠にこれを使うことをためらう必要はないでしょうけど。 >この２点が「Ｃに特有の話」である事で、この説明が足りないと思いました。 補足の形で(Webに)載せた方がよいかどうかは、現在思案中です。

「センス・オブ・プログラミング」読ませていただきました。 読んで良かったと思いました。 特に３章は共感する所が多くありました。 私もコピペやっちゃうんですよね、そして後で後悔してますね。 新人の頃に読めたらもっと何か違っていたかもと思いもしました。 ところで、可変長配列について説明(P153)がちょっと足りないのでは？ 特に「Ｃに特有の話」の部分にかかります。 typedef struct _VARIABLEARRY { int valMaxIndex; char val[1]; // １つの配列のインデックス値は本来０だけが有効。 // char val[0]; の記述はコンパイラの実装により異なる。 }VARIABLEARRY; たとえばこの場合 int maxIndex = 10; VARIABLEARRY *pArry; pArry = malloc( sizeof(VARIABLEARRY) + maxIndex ); pArry->valMaxIndex = maxIndex; pArry->val[1] = 'a'; // 配列のインデックス値が宣言した範囲を超えている。 の表記が許される事です。 BASICでは配列のインデックス値が範囲を超えるとエラーです。 Ｃではこれが間違いではありません。---① また、構造体の最後のメンバを配列にする事でこれが可能である事です。---② typedef struct _VARIABLEARRY { char val[1]; int valMaxIndex; }VARIABLEARRY; とした場合は正しく機能しません。 この２点が「Ｃに特有の話」である事で、この説明が足りないと思いました。

>ところで本文中でちょっとした誤りだと思われる箇所を見つけました。 >goto文について解説しているところで、JavaとC++にはラベル付きbreakが >存在すると記述されていますが、C++では聞いたことがなかったので念のために ご指摘ありがとうございます。 とりあえず手元のStroustrup本で確認しましたが、C++にラベル付きbreakは ありませんね。なぜかは知りませんが勘違いしていたようです。 これは罪の重い間違いだと思います。申し訳ありません。 正誤表に載せておきました。

センス・オブ・プログラミング読ませて頂きました。 プログラミングにおけるポイントを押さえていていい本だと感じました。 またループに使用する変数i,j,k,...の由来を知ったときは感激でしたね。 ところで本文中でちょっとした誤りだと思われる箇所を見つけました。 goto文について解説しているところで、JavaとC++にはラベル付きbreakが 存在すると記述されていますが、C++では聞いたことがなかったので念のために ISO/IEC FDIS 14882:1998を調べてみました。ところが自分が調べた限り そのような記述は見つかりませんでしたので、ご確認していただけないでしょうか？ 一応自分が参照したFDISのbreakに関する部分を掲載させていただきます。 では失礼致します。 6.6.1 The break statement The break statement shall occur only in an iterationstatement or a switch statement and causes termination of the smallest enclosing iterationstatement or switch statement; control passes to the statement following the terminated statement, if any.