前回は、Rubyのブロック付きメソッドによる繰り返しの抽象化の効果を示しました。今回は、I/O(ファイルやソケットとの入出力)への読み書きアクセスを題材として、ブロック付きメソッドによるシステム上のリソースへのアクセスの抽象化とその効果を示します。I/Oの開け閉めを直接プログラムするファイルへの読み書きやTCPソケットによる通信では、ほとんどの場合、以下のような手順で処理が行なわれます。最後にI/Oを閉じるまず、この手順を直截的にプログラムしてみましょう。結果を表示-----------------------------------------------このプログラムは以下のような処理をしています。・モサのWebサイトにTCP接続する・HTTPプロトコルのGETを送信し、RSSデータを要求する・RSSデータを受信しながらパースする・接続を閉じる・パース結果の各エントリのタイトルをプリントする同時に開くことのできるファイルやソケットの数にはシステム上の制限がありますから、不要になった時点でそのI/Oは閉じるべきでしょう。閉じる部分を書き忘れてしまうというのはありがちな話だと思います。書き忘れなかったとしても、RSSパース時に例外が発生したりしたら、I/Oは開きっぱなしのままプログラムの実行は外に移ってしまいます。書き忘れはどうしようもありませんが、例外の発生によるI/O開きっぱなし問題には解決策があります。}のようなものを使う方法が考えられます(何が起ころうともtry節から出るときには必ずfinally節を実行する)。Rubyにも、beginとensureを使う同様の構文があります。さきほどのプログラムを改良してみましょう。結果を表示-----------------------------------------------begin節(beginとensureで挟まれた2行)の実行中に何が起きようと、ensure節(ensureとendで挟まれた1行)は必ず実行されます。I/Oが閉じられるようになって少し安心しました。このように書いている時点でI/Oを閉じることを意識しているわけですから、それを書き忘れることはおそらくないでしょう。I/Oの開閉に関する部分は、I/Oにアクセスするどんな目的のプログラムであろうとさほど変わるものではありません。言い換えると、TCPソケットで通信するプログラムには以下のようなパターンがあります。end何度も同じようなパターンが出てくるときは、それを出来る限り抽象化して繰り返さないようにするのが正しいプログラマの姿勢(DRY原則-後述)。ここでブロック付きメソッド呼出しの登場です。TCPSocketクラスのクラスメソッドであるopenは、I/O(ソケット)へのアクセス処理をブロックとして渡すことにより、上記のようなパターンのI/Oの開け閉めを裏でやってくれます。この場合、ブロックの実行結果がopenメソッドの返す値となります。}では、ブロック付き呼出しでさらにプログラムを書き換えてみましょう。}-----------------------------------------------とてもすっきりした上、I/Oの閉じ忘れも書き忘れも起こりえないプログラムになりました。ここまで、TCPSocketを実例としてI/Oへの読み書きアクセスの抽象化を説明しましたが、これはIOクラス(TCPSocketの上位クラス)でサポートしている機能です。ファイルI/Oに関しても同様に使うことができます。このような抽象化をサポートするブロック付きメソッドをプログラマが定義することもできます。(RSSリーダで使っているもの)を使うのが手軽かつ安全で良いでしょう。「同じコードの繰り返しは抽象化してひとまとめにしよう」というプログラミング上の原則のこと。978-4894712744)という本などで紹介されています。#121相変わらず暑い日が続くが皆さん元気にハタライておられますか。いうのをやることになった。ウインドウならSpotlightの検索ボックスとか表示切り替え(アイコン/リスト/カラム)ボタン、Xcodeのプロジェクト・ウインドウなら「ビルド」とか「ビルドして実行」とかのアイコンが表示されているあそこのことである。起動してみていただきたい。Attributesタブを選ぶとこれに関係ありそうな項目は一個しかない。look」というやつで、NSWindowの時に説明したと思うがこれは「タイトルバーとツールバーを境目のない遠近両用眼鏡のような外見にするかどうか」のスイッチである。......早い話があるウインドウがツールバーを持つかどうかはここでは指定できない。Connectionsタブを選んでみる。なかに、おおありますね「toolbar」というのが。連結すればこのウインドウに突如ツールバーが出現する、仕掛けになっているのだな。NSToolbar」ちうメッセージが出て繋がってくれないのである。普通この手のオブジェクトはパレット・ウインドウからドラッグ&ドロップすれば作れるもんなのだが、パレットのどこを探してもツールバーらしきものはないんですな。使って作ることができない、のである。バージョンアップされ、もしかするとそれが可能になるかも知れないから、ね。オレとしてもなって欲しいんだけどさ......。しょうがないから全部コードで書くのである。嫌な顔をしてはいけない。「window」(クラスはNSWindow)と、「report」(クラスはNSTextView)を追加する。Builderは終了。最初の目論見としてはツールバーにアイコンを一個表示し、それがクリックされたらreportに「クリックされたぞ」というレポートを表示したい。あ、アイコンを用意しなくちゃいけないか。ファイルが入ってるからネコとか犬とか好きなのを選んでプロジェクトに追加すればいい(「ファイル」タブの「Resources」の下にドラッグする)。開き、ツールバーを管理するのに必要なインスタンス変数を以下のように定義する。クラスはNSMutableDictionary。セットする......ってもそれがなかなかの難物なんだけどね。以下は次回といたします。X入門(10)〜こんにちは、高橋真人です。今回は、前回の最後に載せたコードについての解説です。アプリケーションの動きを確認して、前のものと比較してみるといくつかの違いがあるのに気付くと思います。違いは、メニュー項目の表示部分です。File、Editの各メニューを開いて確認してみると分かりますが、NewとClose(いずれかのウインドウが開いている場合)以外の項目は、すべて無効化されています。前回までのものは、FileメニューとEditメニューですべての項目が選択できる状態になっていました。上記の2項目以外について、今のアプリケーションでは実際にそれらを実行する処理はどこにも存在しないので、本来なら無効化しておく必要があります。余りに身近な存在であるために、とかく軽視されがちなメニューの表示処理ですが、コンテキストに応じて表示状態を頻繁に変更する必要があるため、案外煩雑なものなのです。Cocoaでは、フレームワークの柔軟性を生かして、なかなかに巧みなメニューハンドリングの仕組みが用意されています。私もオブジェクト指向、非オブジェクト指向の様々なシステムでメニューハンドリングを見てきましたが、Cocoaの処理のスマートさは群を抜いていると思います。ご存知のようにCarbon自体はオブジェクト指向のフレームワークでないため、PowerPlantXのようなフレームワークは、もともとCarbonが持っているメニューの仕組みをうまくオブジェクト指向でくるんでスマートにする使命を負っています。OSの複雑な歴史的背景のために複数のアプローチを用意していましたが、PPxでは、Carbonイベントモデルが用意するコマンドイベントをそのまま利用する形を取っています。具体的には、前回説明したPPxCommandEvents.hに定義してあるいくつかのクラスでこれらを解決しています。前回も触れましたように、このヘッダに定義してあるクラスは、PPxのコマンドハンドリングの中核とも言うべきところなので、全部を説明しようとすると、どうしても話が深く、複雑になってしまいます。そこで、当連載では使い方の部分に徹して説明をします。動作原理の部分に興味のある方は、別途C++の解説書などを参照してください。それでは、再度クラスの定義を見てみましょう。MyApplicationの定義部分を再掲します。ioEvent);};MyApplicationが継承しているクラスの二番目にCommandConveterがあります。これは、これから使うクラスを使うための裏方のクラスでして、「とりあえず、加えておくものなのだ」と覚えておいてください。そのあと,似たような名前のクラスが二つ続いています。SpecificMenuCommandEnableDoerとSpecificMenuCommandDoerです。SpecificMenuCommandEnableDoerの方ですが、これはその名の通り「特定のメニューコマンドを有効にするもの」ということで、つまり、クラス名の直後にある<...>の部分で指定したコマンドが割り当てられているメニュー項目を有効にする機能を持っています。今回の一つ前のPPxForXcode02でのMyApplicationの定義は以下のようになっていました。PPx::CommandProcessDoer{(残りは省略)もう忘れてしまったかもしれませんが、このアプリケーションを走らせた時にメニュー項目はほとんどすべてが有効になっていました(OSが管理してくれるWindowメニューは除く)。この部分を「適切に」するために、このSpecificMenuCommandEnableDoerを使うのです。PPx::SpecificMenuCommandEnableDoerというのを加えることで、New...の項目が有効になります。New...は有効だったでしょ?」と思うと思いますが、それは結果的な話でして、あくまでそれ以外のメニューが有効であったことの方が、ここでは「普通ではない」のです。Builderですべてのメニュー項目を無効にした状態にしてから走らせてみれば、New...だけが有効になっているのが分かるはずです。ここでちょっと面白い実験をしましょう。PPxForXcode02をフォルダごと複製して(前のものを残しておく必要がなければ、複製しないでそのままいじっても構いません)、MyApplication.hのクラス定義の部分を少し書き換えます。PPx::SpecificMenuCommandEnableDoer{と変えてください。目的は、SpecificMenuCommandEnableDoerを加えるだけのことなのですが、以下の理由から上記のようにます。・先ほど触れた裏方のCommandConveterを加える必要がある・もともとあったCommandProcessDoerは、SpecificMenuCommandEnableDoerも含めて、これらのコマンドやメニューハンドリングをするクラスの継承元として含まれているので、取ってしまった方がよい(ただし、残しておいてもコンパイル時に警告が出るだけで、動作的には支障はない)「以上でOK」と言いたいところなのですが、あと少しだけを手を加えます。MyApplication.cpで、MyApplicationのコンストラクタに2行加えて以下のようにします。PPx::SpecificMenuCommandEnableDoer::Install(targetRef);}先ほども言いましたPPx::CommandProcessDoer::Install(targetRef);は、PPx::SpecificMenuCommandEnableDoer::Install(targetRef);から間接的に呼ばれていることになるので、外します。これで実行してみてください。先ほどの説明通りに、ほとんどのメニュー項目が無効になるとともに、アプリケーションメニューのAboutPPxForXcode01の下にPreferences...という項目が表れたはずです。これは、コード変更前にはなかった項目です。今回の変更では、単にこの項目を「有効にせよ」と指示しただけなのですが、システムが環境設定項目が必要だと判断して、用意してくれたのだと思います。2,000円+税アプリケーションに限らずwebページなど「デザイン(視覚的美術的な意味でのデザイン)」は不可欠です。自分でデザインしなければならない場合はもちろん専門家の力を借りることができる人もデザインの素養は必要でしょう。才能はどうすることもできないとしても、基礎的な技術を習得し改善されるならと本書を手にしました。「色」の技法の五つの章に分類された、見開きまたは1ページ完結の技法が載っています。それぞれカラーの図(実例)と簡潔な解説に加え、注、この技法の用途、デザインテイストが載っています。縦組の本文が新鮮でコラムで取り上げている話題も親しみやすく、全体も読みやすい本です。『無難にまとまっているけど○○に似ている』とか『ユニークだけどダサイ』とか自分のデザインにはなかなか満足できないものです。本書でこんな悩みがすべて解決するわけではありませんが、原因の分析や対策一助にはなりそうです。広く、設計の意味でのデザインでも「考」の技法が参考になりそうです。寸法単位の解説や参考文献など「デザイン」関連情報の出発点として開発の現場に一冊どうぞ。OSは米国アップル社の登録商標です。そのほかの各製品名等はそれぞれ各社の商標ならびに登録商標です。Artistsアクセスリンクについて個人情報の取り扱いについて支援のお願いお問い合せこのサイトに掲載されている文章、画像を含む一切のデータの無断転載を禁止します。