MOSA Multi-OS Software Artists

MOSA Developer News［MOSADeN＝モサ伝］第175号

2005-09-13

目次

• 「WebObjects Dev Report」　　　　　第21回　　田畑 英和
• 藤本裕之のプログラミング夜話　#76
• 高橋真人の「プログラミング指南」　 第74回
• ニュース・解説　　　　　　　　　　　　　　　 小池 邦人

「WebObjects Dev Report」　　第21回　　田畑 英和

　今回からユーザ情報をどのようにモデル化するかを解説したいと思います。前回ご紹介しましたようにユーザには「MOSA会員」「非会員」「事務局」の3種類のタイプがあります。これらのタイプをEOFの継承を用いて表現していきたいと思います。

　継承とはオブジェクト指向を用いた開発でよく使われる手法ですが、あるクラス(親クラス)を継承してサブクラスを作ることにより、親クラスの機能を引き継いだ新しいクラスを作成することができます。つまり、関連のあるクラスを作成するときはそれぞれ個別に作成するのではなく、親となるクラスから派生させてクラスを作成することにより、効率よく体系だてて開発ができることになります。
　この考えをデータのモデリングに応用しているのがEOFの継承です。共通した属性をもつ複数のEntityを、親Entityから継承することにより作成することができます。このとき共通する属性は親Entityで定義します。そもそも、EOFはオブジェクトをデータベースに永続化(マッピング)するためのテクノロジーですので、オブジェクト指向の世界で頻繁に使用される継承関係をもったオブジェクトであっても、データベースにマッピングできるというのは自然な考え方とも言えます。

　EOFの継承には「水平」「垂直」「単一テーブル」の3種類の方法があり、それぞれ次のような特長を持っています。

◇垂直
　・Entityごとにテーブルを作成
　・各テーブルには対応するEntity固有の属性のみが含まれる
　・パフォーマンスは悪い
◇水平
　・各テーブルは親Entityの属性も含む
　・垂直よりもパフォーマンスがよい
◇単一テーブル
　・1つのテーブルがすべてのEntityの属性を含む
　・パフォーマンスがよい

　「垂直」の場合、テーブルへのマッピングは継承したクラスの実装とよく似ています。つまり、親Entityに対応するテーブルには親Entityの属性のみが含まれ、継承したEntityに対応するテーブルには、そのEntity固有の属性しか含まれません。このように、クラスの実装がそのままテーブルの定義にも対応していますので、分かりやすくはあるのですが、継承したEntityの1レコードを取得する場合、親Entityのテーブルが必ず必要になってきますので、パフォーマンスはよくありません。
　一方「水平」の場合、「垂直」では親Entity用のテーブルに含まれていた属性を、継承したEntity用のテーブルに含めてしまいます。つまり1つのテーブル内にすべての属性を含むことができますので、よりよいパフォーマンスを得ることができます。
　さらに「単一テーブル」の場合は、継承関係をもったすべてのEntityを1つのテーブルで管理します。この場合、Entityによっては使用しない属性が発生してしまいますが、「水平」と同様に1つのテーブルにレコードを構成するすべての属性を含むことができます。「単一テーブル」の場合、テーブル内の全件をFetchすれば、Entityにかかわらず、継承関係をもったすべてのレコードを取得することができます。

　EOFの継承はこのような特長をもっており、パフォーマンスを重視するのであれば「単一テーブル」あるいは「水平」を用いるのがよいでしょう。ただし継承の種類によってメンテナンスの手間が異なってきますので、まずはEntityの属性がどのようにテーブルとマッピングされるかを理解しておくことが重要になります。
　今回のシステムでは「単一テーブル」を用いてユーザ情報をモデル化してみたいと思います。継承の方法については次回解説したいと思いますが、参考になるドキュメントとサンプルを紹介しておきます。

・ドキュメント
http://developer.apple.com/documentation/WebObjects/UsingEOModeler/
「Modeling Inheritance」の章
・サンプル
/Developer/Examples/JavaWebObjects/WOInheritanceExample

藤本裕之のプログラミング夜話　#76

　承前（と、この言葉ばかり使ってるけど他にかっこいい言葉って無いのかな）、例えば編集メニューの「カット」に初期値でターゲットとして結びつけられているのはNibファイルを作ると自動的にできる「First Responder」というアイコンで、その意味するところは「レスポンダ・チェイン」であった。そして、このレスポンダ・チェインの先頭は、その時点のキー・ウィンドウ（キーボード・イベントを受け取るウィンドウ）のfirstResponderになっているのだった。よね？

　ここでちょっと老婆心。念のため語句の意味するところを確認しておきたい。
　ワタシが「レスポンダ・チェイン」と呼んでいるのは「NSResponderのサブクラスのインスタンス（面倒なので正確ではなくなるが以降「NSResponder」と略させてちょうだい）が、そのインスタンス変数nextResponderによってつながっているもの」である。特定のモノを指しているのではなくて、一般名詞として使ってるわけ。
　編集メニューの「カット」からのメッセージを受け取るのは、前にmouseDown: を受け取った時に辿ったレスポンダ・チェインとは別の流れだけど、これもレスポンダ・チェインであることに変わりはない。一つのNSResponderが持てるnextResponderは一つだけだが、複数のNSResponderが同じオブジェクトをnextResponderとして保持することはあり得るので、いくつものサブビューを持つウィンドウにおけるレスポンダ・チェインの全体像は、何本もの川が合流して大河になり海に流れ込むような感じになってる。いいかな？

　「カット」とか「コピー」とかの編集関係メニューアイテムからのアクションは、まぁたいていの場合キー・ウィンドウで処理される。でもNibファイルの「First Responder」アイコンに接続されているのは編集関係のメニューばかりではない。
　このテの「ターゲットが動的に変わるアクションがどんな順番でオブジェクトに実行を打診（てのもおかしいが言わんとするトコロは解るでしょ？）していくのかを以下にちと細かく追ってみる。
　最初は上で見たようにキー・ウィンドウのfirstResponderを先頭とするレスポンダ・チェインを辿る。このチェインの最後はご存知の通りキー・ウィンドウ自身になる。そこまで辿っても応答できるオブジェクトが見つからないと、このウィンドウのdelegateに打診する。
　テキストエディタのような、ドキュメント・ベースのアプリでは、次がキー・ウィンドウのNSWindowController、そしてNSDocumentへ進む。お気づきだろうか、「ファイル」メニューの「保存」だの「復帰」「印刷」だのは、こうしてめでたくNSDocumentに到達するのである。もしキー・ウィンドウとメイン・ウィンドウが違ってる場合には、次にメイン・ウィンドウのfirstResponderからのレスポンダ・チェインを辿ってそのNSDocumentまで以下同文。
　それでも応答されなければ、NSApplication（例えば「……を隠す」など）、そしてそのdelegate、おしまいにはNSDocumentControllerが控えていて、こいつが「新規（New Documentのこと、ただ「新規」とだけ書くとわかりにくいな）」や「開く…」を担当してるわけである。やぁ長い長い道のりでした天竺取経の旅ご苦労様（違うな）。

　これで、とにもかくにもNSViewのNSResponderのサブクラスとしての機能についてもあらかたの説明を終えたわけである。隔週のキレギレ話なのでまとめて読むと同じことを繰り返してたりするかもしれないけどそこはご勘弁（一応直前の原稿だけは必ず読み返して書いてるんだけどね）。次回からはNSWindowを取り上げたい。NSWindowもNSResponderのサブクラスである部分は同じだから、NSViewみたいな長丁場にはならないと思うんだが……。
　あ、そうそう。申し込みが始まってると思うけど、今年も湘南ミーティングで講師やります。今回のお題は「Spotlight importerプラグインの作成」。あ、これ簡単なので予習をやったりしないように。講師の存在意義がなくなっちまうので（笑）。
（2005_09_07）

高橋真人の「プログラミング指南」第74回

UNIXとしてのMac OS X

〜Perlについて(20)〜

　こんにちは、高橋真人です。
　量指定子の次は、「言明」というものについて説明します。
　実は白状しますと、この原稿を書くためにLarry WallのプログラミングPerlを参照するまで、私はこれから説明する一連のものに「言明」なる名前が付いているのを知りませんでした。
　もっとも、他の文献もいくつか当たってみた限りでは、この「言明」という表現を使っているものはひとつも見つけられませんでしたから、正規表現使いの中でも、この言い方に馴染んでいる人は多くないでしょう。

　具体的な例を出さずに話を続けても、読んでいる人には何のことか分からないでしょうから、先に例を挙げます。
　今回説明する言明というものには以下のようなものがあります。

^
$
¥b

　まだ他にもあるのですが、よく使われるものに限定しておきます。

　^は行の先頭を表すために使われます。これは前回の最後の説明でも使ったように、「全ての空白を除去したいわけではないが、先頭のものだけは取り除きたい」などという時に使うのに便利です。
　以前説明した否定文字クラスでもこの記号が使われていますが、意味も役割も全く違うことに注意してください。正規表現にはこのように「使われる場所によって全く別のものになる」記号が他にもいくつか存在します。

　$は^とは逆に行末を表現します。
　テキストデータ、特に人間が手打ちしたものであるとか、Webページをブラウザのウインドウからコピーしたようなデータには、とかくムダな空白文字が入りますが、こんなとき、この記号を使って、/[ ¥t]*$/としてマッチさせた文字列を空白に置き換えれば、きれいに取り去ることができます。
　ちなみに全角空白も考慮しようとすると、Perlではちょっと話が複雑になりますが、日本語対応エディタで、正規表現での検索置換ができるものでしたら、上記文字クラスに全角空白を加えてうまく行くケースも多いので、試してみる価値はあるでしょう。ここでも以前紹介したmiではうまく行くようです。

　さて¥bですが、これは単語の区切りを表現します。よく単語境界とかアンカー文字などと呼ばれます。ただ単語の区切りといっても、普通の考え方とは少し異なるので注意が必要です。
　たとえば、以下のようなテキストがあるとします。

orange, banana, peach, apple and cherry

　ここから、eで終わる単語を抽出したいとしましょう。いろんな正規表現が考えられますが、今回は以下のような表現を使います。

/¥b.+?e¥b/

　まずドットですが、何とまだこの連載では説明していませんでしたが、正規表現においては「改行以外の任意の文字にマッチする」役割を持ち、極めて頻繁に使われます。
　このドットに前回説明した + 記号を組み合わせて、「単語境界、任意の文字の1つ以上の連続、e、そして単語境界」という表現になります。+ のあとに? が一つ付いていますが、これは正規表現には「最長マッチ規則」というのがあって、「可能な限り長い部分にマッチする」のが決まりです。これを抑制するために、+ や * のあとに ? を付けるのです。
　さて、このようにしてマッチさせると、「orange」と「apple」を取り出すことができます。重要なのは、「apple」の a の直前のスペースはマッチ範囲に含まれていないということです。正規表現における単語境界というのは、いわゆる「区切り文字」のことではなく、単語を構成する文字（アルファベットなど）とそれ以外の文字（空白文字など）との間の部分そのものを意味します。
　冒頭で言明（英語で言うとassertion）と言いましたが、これは「ここ（¥b）に単語とその他の境界がある」と言明しているということなのです。

ニュース・解説

今週の解説担当:小池邦人

Carbon ドキュメント & サンプル ＆ SDK ナビゲーション（2005/9/9）

【開発環境】

前号で木下さんも紹介されていますが、Apple社のサイトに「Developer Transition Resource Center」というWebページが登場しました。「Performance Optimization Development Mailing List」といメーリングリストへの参加もできるようですね。

http://developer.apple.com/transition/

【テクニカルドキュメント】

前回から9月9日の期間中、Apple社のDocumentationサイトには数多くのドキュメントが登録されました。ただし、ほとんどは内容のマイナーチェンジです。今回も、その中で初版と内容が大幅変更になったドキュメントだけをピックアップして記載しておきます。注目は「AltiVec/SSE Migration Guide」ですが、さて、これによりどこまでAltiVecユニットが失われてしまった状況をカバーできるのでしょうか（笑）。また、新規のデベロッパー向け読み物が2つ登録されました。「Working with Xcode: Building Applications for the Future」については、前号の木下さんの記事を参照してみてください。

「AltiVec/SSE Migration Guide」（PDFあり）（初版）
「FireWire Device Interface Guide」（PDFあり）
「HIToolbar Reference」（PDFあり）
「HIView Reference」（PDFあり）
「Internationalization Programming Topics」（PDFあり）
「iWork Programming Guide」（PDFあり）（初版）
「Kernel Extension Concepts」（PDFあり）
「Message Framework API Reference」
「QuickTime 7 for Windows Update Guide」（PDFあり）（初版）
「Spotlight Reference」（初版）
「Universal Binary Programming Guidelines」（PDFあり）
「vDSP Library」（PDFあり）
「vecLib Framework Reference」（PDFあり）（初版）
「What’s New In QuickTime」
「Window Manager Reference」

http://developer.apple.com/documentation/index-rev-date.html

「Adopting Universal Binaries on Mac OS X」（読み物）

http://developer.apple.com/macosx/adoptinguniversalbinaries.html

「Working with Xcode: Building Applications for the Future」（読み物）

http://developer.apple.com/tools/xcode/xcodefuture.html

前回から9月9日の期間中、新規テクニカルノートはひとつも登録されませんでしたが、新規テクニカルQ&Aの方は3つ登録されています。

QA1400「Adding Unicode characters to Text Media in a Text Track」
QA1440「Implementing a CVFillExtendedPixels- CallBack」
QA1401「Registering custom pixel formats with QuickTime and Core Video」

http://developer.apple.com/technicalqas/index-rev-date.html

【サンプルソースコード】

前回から9月9日の期間中、Apple社のSample Codeサイトには、新しいサンプルソースコードが2つ登録されました。両方ともQuickTime関連なのですが、「QTKitPlayer」の方は、CocoaのQTKit Frameworkの使い方の総合的なお手本となっています。

「CaptureAndCompress- IPBMovie」（QuickTime関連）
「QTKitPlayer」（QTKit関連）（初版）

http://developer.apple.com/samplecode/index-rev-date.html

【デベロップメント SDK】

前回から9月9日の期間中、Apple社のSDKサイトには新しいSDKがひとつも登録されませんでした。

http://developer.apple.com/sdk/

MOSAからのお知らせと編集後記は割愛します