僕が図書館というものを「使った」ことは今までに一度だけある。学生の時、日本史のレポートで、どうしても地元の図書館で文献を漁る必要があった。

レポートの内容は「○○という地名から中世をさぐる」というタイトルで、自分の生まれた地の中世の様子を論文にするというものであった。

もちろんインターネットでは文献や史料をカバーすることは不可能なため、市立図書館で文献をいくつか見たがそれでも史料不足ではあった。

図書館を使ったのはこれだけだ。それ以外の情報、知識についてはすべてインターネットで賄っている。小説など娯楽のための本やいくつかの技術書に関しては、借りることは無く購入している。

さて、大学の図書館と市立図書館を比べてみると、その使われかたがかなり違うのだろう。

大学であれば図書館は読みたい専門書や雑誌を買ってもらえて、それが置いてある場所だろうし、市立図書館では新刊がタダで読めるために利用されているのではないかと思う。

インターネットや書店が多くある今、歴史的な文献を除いて、情報を調べるために来るひとがどれだけいるのだろうか。

日本の図書館と外国、例えばアメリカの図書館ではその定義や使われかたが大分異なる。

日本だと図書館=本が置いてある場所 or 試験勉強するための場所 だろうし、極端な例であるが、司書=アルバイトである。

アメリカであれば、図書館=勉強する資料を提供する場所で、ライブラリアン=教養のある何らかの専門家である。

日本であれば司書と話をすることはほとんどないだろうが、アメリカでは司書(ライブラリアン)

と話をしてどんな本があるのか、どんな本を読むべきなのか相談にのってくれる。

アメリカのほうが日本よりも、図書館の考え方、情報の考え方が進んでいるのだ。日本の図書館はそれが発達する前にインターネットなど別のメディアが普及してしまったため、図書館の扱い、司書の扱いが中途半端な状態になっていることは否めない。

このままいけば、どんどん図書館というものの存在感が薄れていくだろう。利用者が横ばいだとしても時代から見て古くささがどうしても残ってしまう。

いよいよ「モダンな図書館」というものを考える時期ではないだろうか。

これからの図書館はそれ自体の機能はすべてWebに移行すればよいと思う。

もちろん、本をただスキャンして、それをデジタル化するというのでは意味が無い。それでは今、電子書籍がやっていることと同じである。図書館が扱うコンテンツそのものをどうするか、どうやって見つけるか、どうやって見せるかを抜本的に考える必要がある。

(現状の本の扱いをどうするかという問題もあるが。)

もう一つの図書館の機能である、交流や勉強をするスペースという意味では、図書館＝カフェでよい。

カフェというのは場所を提供するところである。これとイコールで、同じ分野、同じ専門についての人々がしゃべれる。そこで一人で勉強してもよい。

ただ、普通のカフェとの違いとして、

普通のカフェ＝娯楽の空間

図書館カフェ＝知識の空間

というように、来る人の前提やコンセプトを作ったほうがいいかもしれない。

これはまさに東大が行っているプロジェクトに近いものである。(参考文献)

おおよそ講義が終わったあと、広いホワイトボードや机のあるスペースに教授、学生、研究者が集まり、そこでディスカッションするという。

まさに、図書館カフェだ。

そして、会話のネタや文献や資料、知識、情報はすべてWebから取ってくる。上で述べたように新しい図書館が扱うコンテンツはもうそこにあるのだから。

参考文献: 

図書館（福島高専） - いわき百科事典プロジェクト (もう少し正確かつ母数の大きい出典が必要)

世界から頭脳が集う東大のとんがった研究所 - 東洋経済 2011/7/2号

教養とはなにかという話をはじめると、歴史から話始めなければならず、説明も面倒なので、

Wikipediaを参照されたい。それに文章だけで完全に説明できるものでも無いだろう。

Wikipedia - 教養

その末尾でも説明されているように教養という学問はどんどん薄れていき、今の大学では教養という分野や学部は無くなってしまった。もう、インターネットでも何でもある時代なのですべて自分で勉強せよということかもしれない。

いずれにせよ、学生が教養を身に付けようとしないのは事実であろう。

(そもそも教養という言葉自体知らない人がいることには驚いた。大学生位であるが。)

実際の高等教育がどうなっているか少し話をすると、教養を教えると謳っている教養学部は東大にしか現状は残っていないし、外から見たカリキュラムの情報からは内容が本来のそれとはちょっと違う。(実際にいたわけではないので断言は出来ないが。)

日本の就職制度に合わせて新卒という制度が作られ、そもそも理系だとか文系だとかいうよく分からない枠組みも就職制度の中で生まれてきた。元々大学にはそいう区別はなかったし(p4, 2-14)、教養学という分野があったのにも関わらず、いつしか無くなってしまったのである。

例えば、昔の医学部には人間を相手にする学問ゆえ、2〜3年に渡る教養過程があった。(p33, 2-1)

参考文献 「別冊 環 2 大学革命」

現在の大学の形態はほとんど学部学科制。よくも悪くもそれぞれの分野が高度に専門化されて、先のとがったつららのような構造をしている。

そして、大学がそうあるように、それ以前の受験制度、高校、中学のカリキュラムもそれに続く格好となっている。

さて、ここでは今の学生は具体的にどんな勉強をすべきか、クラス階層から見た教養という学問は何を差すのかということについて述べる。(一応本題)

クラス階層はオブジェクト指向のクラス継承そのものである。

教養クラス (ルートクラス)

• (マス)メディア
• 経済
• 歴史
• 政治
• 国際
• 法律
• 算数
• 国語
• 理科
• 芸術
• コンピュータ, Web

(メソッドとしてクラスが持つ)

このくらいは社会を生きるうえで必要な最低限の学問であろう。今の社会で、学生と見られるか社会人と見られるかは、これらがあるか無いか(つまりこれらのメソッドが自分に実装されているか)の違いである。 (無い社会人もいるが)

少なくとも学生とクラス分けされたくなければ、学生として見られたくなければ、教養クラスをインプリメント(実装)すればいいだけである。

Web系のデザイナー, エンジニア クラス : 教養クラスを継承

• ビジネス(親クラスの経済をオーバーライド)
• アルゴリズム, 情報数学, デザインパターン(親クラスのコンピュータと算数をオーバーライド)
• デザイン(親クラスの芸術をオーバーライドしてアートでは無くデザイン方面とする)
• データベース
• 運用ノウハウ
• クラウド
• HTML, CSS, JS

例えば、もし自分がWeb系の仕事をするならば、このように教養クラスはすでに実装されているものとして、継承・オーバーライドして、追加のメソッド(学問)を実装(勉強)すればよい。教養クラスをもとにしてどれだけ自分が理解しているか、多くのメソッドを実装しているかがアイデンティティとなるのであろう。

Cocoa(CoreText)にはこんな感じに、日本語と欧文が混同したテキストを表示すると行間が不自然に空く問題がある。

Helveticaなどを使って日本語を含む文字列を描画したときに複合フォント(日本語はヒラギノで表示)が使われるが、そのアセントとディセント、リーディングが違うため起こるものである。

これはたぶん仕様である。

いずれ直そうと思いつつしばらくいじっていたら、解決方法が分かったのでメモ。

単純にスタイルに kCTParagraphStyleSpecifierMax(Min)imumLineSpacing を適用するだけ。4.3から使えるみたい。

サンプルはgithubで。

novi/CoreTextJapanese - GitHub

c.f. Tweetbot：日本語テキストの行間について | E-WA’s Blog

追記: 

ヒラギノフォント指定で日本語だけの文章を表示しようとすると、逆にリーディングが無くなる?ので、同じサイズの欧文フォント指定の時よりも行間がつまる。

んー、どうしよ。

しばらくbrewやらportsやらで格闘していたが、インストールできたのでメモ。

説明はgistに。

ちなみに、PDFWalkerはRubyで書かれたPDFパーサーOrigamiに付いてくるPDF解析ソフトである。

GUIでPDF構造を解析できる。(ただし、X11のGTK)

origami-pdf - Origami is a Ruby framework designed to parse, analyze, and forge PDF documents.

APIは一覧チートシートはここ。

ソースによると、iOS5でもSafariの脆弱性を利用したJailbreak実現の可能性があるそうだ。今度はPDFらしい。(正確にはSafariではなくOSのフレームワークであるが。)

Safariの脆弱性を利用したJailbreakはiOS3対応のJailbreakme.comで実現されていた。

Jailbreakme.comにアクセスしてボタンを押すだけでそのiPhoneがJailbreakされる。

これもPDFの脆弱性を利用している。そうすると今回は10ヶ月ぶり2度目。

実はまだ日本でiPhoneが発売されていない初期のJailbreakでも、同じような脆弱性を利用していた時期があった。

それは日本でiPod touchが発売された最初のバージョン、OS 1.1.4の頃である。

(バージョンもこれであっていたと思うが記憶が... ちなみにOSの名前もiPhoneOSやiOSではなかった。)

これはSafariから特定のTIFFファイルを見ることによってJailbreakすることができた。いわゆるTIFF Exploitである。

New Safari Exploit = jailbreakme.com for 1.1.4 - iFans - iPad, iPhone, and iPod touch Fans forums

ちなみにPSPでもTIFFの脆弱性を利用している。
PSPやらアニメやら PSP-3000 TIFF Expoit v2 Hello World 起動成功！

さて、これらPDFやTIFFに共通する点といえば、バイナリファイルフォーマットであるということである。

今のWebで利用されるファイルフォーマットのほとんどはテキスト(XML)ベースである。

構造化されているか or いないか は除いても少なくともテキスト(UTF8)ベースである。

HTML, JS, CSS, JSON, XML、Epub はもちろんテキストであるが、画像、PDF、フォントはバイナリである。

基本的にこれらバイナリフォーマットを解析するためのパーサーはOSライブラリレベルでは、C言語で記述される。

極端な例を言えば、メモリ上に展開したバイトデータのサイズを超えてアクセスすればプログラムはクラッシュする。

特にどのデータが何バイト目にあるかを示すオフセット値を極端に大きな数字にすればバイトデータのサイズを超えてアクセスすることになるので、ファイルを中身を間違える or 意図的に書き換えるだけでプログラムはクラッシュする。

もちろん、そういうことが無いように、サイズが正しいか、データが正しいか毎回毎回チェックしているのだが。そこにも抜けがある訳で、それがそのままOSライブラリの脆弱性となるのである。

PDFは特に仕様が複雑で汎用的なフォーマットなので脆弱性を生みやすいのではないかと思う。

PDFフォーマットというのは制定されたのが1993年。(WWWが初めて出たのが1991年。)

なぜここまでデファクトスタンダードになったのか分からない、Adobeもびっくりなフォーマットである。

当時はもちろんメモリが少なかったので、ほとんどのファイルフォーマットはバイナリフォーマット(だからレガシーフォーマットと言いたい)で、すべてをメモリに読み込まなくても処理できた。

テキストフォーマットだったのはHTMLあたり位だろうか。(この辺の話は長くなるのでいつか...というかまだ調べていない。)

また、バイナリフォーマットはコンピュータ主導、テキストフォーマットは人間主導だとも言えるだろう。

さて、どうするかという話だがSafariでTIFFなんか見れなくても十分である。

PDFはさすがに無理があると思うが。なるべくフォーマットはテキストベースにして低レベル言語での脆弱性を作りにくくすることだろうか。

テキストベースであれば、問題は小さくなり、開発やテストも楽になる。

それに現代にバイナリフォーマットは古いだろう。

まあ結局のところライブラリを作る開発者の腕によるのだが。

この前のWWDCでiOS5と共に様々なアプリ的な機能が発表・追加された。

よく言われている通り、サードパーティ潰しである。

しかし、これは本当にサードパーティ潰しなのだろうか。

ここで潰れるアプリと潰れないアプリが出てくると思う。

それは「これがあるから良い」という姿勢で取り組んでいる、デザインしているアプリ。これは残れると思う。

逆に「これが無いとダメ」「あれが無いとダメ」というアプリは残れないと思う。
これがあるから というアプリは概して、そのアプリに出来てアップルを含む他のアプリが簡単には真似できないような技術や機能、アルゴリズム、ユーザーインターフェースがあるはずである。

そしてそれを常に考えて、良くなるように突き詰めているからこそ、それがそのアプリのアイデンティティとなっているアプリ。特別なユーザー体験や空間を作っているアプリ。

こういうのにはユーザーが「すきになる理由」があるはずである。

逆にとりあえず考えられる機能をひたすら入れて、超高機能(に見える)。

いくら高機能でも、そのアプリが「持っているもの」が無いと、真のユーザーエクスペリエンスは標準アプリかそれ以下になってしまうだろう。

まあ実際のところ、こういうアプリが売れているのも確かであるが。(日本だけかもしれないけど)

今回Appleは確かにサードパーティアプリの機能を取り込んだ。

しかしながら、どれもごく普通の機能をごく普通のインターフェースで普遍的に実装しただけである。

そこには高度なアルゴリズムや技術、特殊なAPI、素晴らしいユーザーインターフェースなんて無いはずである。

(TwitterなどがOSに統合されている点、サードにはそれが出来ない点ではAppleは有利である。)

そして、今回CoreImageを含め多くのAPIが追加された。今までプライベートなAPIでAppleしか使えないものだった。

これらAPIの公開に引き換え、サードパーティ潰しと言われる機能を追加してきた感じがする。

きっと、このAPIを使って、ぜひ純正のアプリを超えるイノベーションを作って欲しいというAppleからのメッセージなのかもしれない。

c.f. ここでも同じようなことを書いていた。

【アプリ開発者名鑑62】代表アプリ『TweetParakeet』 @novi_ さん♪ #devunq62 - begejstring for DANMARK

気に入っているアプリ=「持っているもの」があるアプリ

Webブラウザでアドレスバーを無くすようにする動きがあるようだ。ネタに上がっているのはFirefox系のブラウザ。今のブラウザはどうなっているのかというと、無論アドレスバーの無いブラウザはまだ無い。ただ、曖昧な存在であることは確かである。Chromeには非表示にするモードがあったり、アドレスバーがGoogle検索欄を兼ねていたり、MobileSafariはアドレスバーが隠れるようになっていたりする。(これはデザインの問題でもあるが。)

アドレスバーはWWWが走り出したときからあった。

そもそも、その頃は検索エンジンというものは無く、アドレスがWebにあるリソース(HTMLや画像)を見るための唯一の方法であったし、インターネットというのはHTTPプロトコルを介してやり取りされるもの(=Webページ)がすべてでは無く、IRC, メール, NetNews, FTPなどのサービス全体であった。プロトコル=サービスでだったのである。

今のインターネットというものはGoogle(=検索エンジン)をルートとする階層構造を成していてそこからWebページを探していくというパラダイムである。アドレスを直接入力するより検索したほうが早いだろうし、ラジオやテレビの宣伝でもアドレスを言うということはもう無くなった。

また、Webにあるコンテンツも情報からアプリへと変化している。BlogやTwitter, FacebookなどはもはやWebコンテンツではなくアプリである。実装という意味でもブラウザ側でMVCモデルを作るようになってきた。

アプリでアドレスを使うのは主にRESTのAPIだけであり、ユーザーが直接入力したり、見ることさえない。(TwitterなどはアプリのURLに意味があるが)

そういうわけで、アドレスというものは一部のユーザーがWebサイトが正しいかどうか見るための欄となった訳である。

ここからは個人の意見であるが、アドレスバーはもう要らないと思う。オプションで必要なら表示すれば良い。セキュリティ云々の話もあるが、結局のところアドレスの意味を知らないユーザーがそれを正しいかどうかチェックできる訳も無く、意識だってしていないだろう。TwitterでXSSを使ったスパムが出てきたことがあったが、あっという間に広がった。

アドレスを見るのは開発者かイノベーター、研究者だけで十分である。

アドレスバーが無くなった時代にはいったいどんなすばらしいWebサービスがあるのだろうか。

昨日に続いてCGRect絡みの話。

CGRectを使ってViewやLayerのframeをいじる時はstandardizeされているか注意したほうがよい。

standardizeとはsizeが正の値で表現されているかどうか。例えば、{x, y}, {w, h} = {0, 0}, {10, 10} と{10, 10} , {-10, -10} は同じ矩形を表す。

あまり詳しくは調べていないが、standardizeされていない場合は正しくレイアウトや描画が行われない場合がある。

CGRectMakeを使って矩形を作ったり、構造体のフィールドを自分で操作したりした場合にはCGRectStandardizeを使ってstandardizeできる。

それ以外のCGRectを引数にとるCGRect関係の関数は暗黙的にstandardizeされるらしい。

All functions described in this reference that take CGRect data structures as inputs implicitly standardize those rectangles before calculating their results.

UIViewの座標のいずれかのフィールドが整数値と等しくないときは、Viewのコンテンツがボケることがある。c.f. 座標の指定が整数値でない場合 UIKit の描画（ビュー、画像、ボタン、その他いろいろ）がぼやける - 24/7 twenty-four seven

いつもはfloorfとceilf関数を使っていたのだけど、前にCGGeometryに良さげな関数があるという話で使ってみたが、これにハマった。CGRectIntegralという関数。

名前からして普通にoriginをfloorして、sizeをceilするのかと思いきや全く違うのである。そもそも何に使うための関数なのか。

こんな感じにテストを書いてみると、(1, 1)で指定したサイズが(2, 2)になっているではないか。もちろんテストもFailure。どうしてこうなった!! 

GNUStepのソースを見てみると変なコードになっているが、ドキュメントを見てみると、どうも正しいようである。

“A rectangle with the smallest integer values for its origin and size that contains the source rectangle. That is, given a rectangle with fractional origin or size values, CGRectIntegral rounds the rectangle’s origin downward and its size upward to the nearest whole integers, such that the result contains the original rectangle.”

単純に渡された矩形のoriginとsizeを丸めるだけではなくて、“元の矩形が必ず入る” ような矩形が返されるようである。だからsizeが大きくなる時がある。

次からはframeの値を整数と等しくするときは自分で書こうと思う。

floorでもceilでもどっちでもいいが、originはfloorして、sizeはceilするようにしている。

CGRectMake(floorf(r.origin.x), floorf(r.origin.y), ceilf(r.size.width), ceilf(r.size.height));

(ちなみに上の岸川さんの記事では整数型に代入しているので問題無い。)

この前「星を追う子ども」を見てきたので印象など。

• PVが結構ジブリっぽいがそうでもない
• 大人のアニメ
• 劇場はフィルムなのでデジタルとはまた違った印象(制作はフルデジタルなはず)
• 飯を食べる表現はジブリを研究していると思った
• 明日菜の家と学校の舞台は長野県だろうか(監督の地元である上田か)
• 脚本(あるのか分からないが)上の矛盾が多い(いつものことであるw) 例えば、モリサキは何人なのか分からないし日本語ペラペラである
• 音づくりは普通か微妙

公開前のPVを見る感じだと今回は・・・だったが、実際に見てみると結構面白かった。

監督はしばらくの間、世界中を旅していたようだが、そこで見たもの、感じたもの、聴いたものから様々なものを取り入れた、いわば彼自身の今までの集大成のような作品だと思う。

最近思うのは高専生や大学生(特に理系学生)に国語力が絶対的に足りないのではないかと思う。もちろん古典や文学よりは単純に文章を書く能力、何か物事をテキストというフォーマットで伝える能力の話である。

高専や大学にはTOEICやその他の英語資格試験で単位が認定される制度があるだろう。認定のレベルに関してもそこまで高くないため、具体的には450〜600 TOEICスコアがあれば何かしらの単位が認められるようになっている。

そのため英語に関してはある程度勉強しようとか、積極的に意識することになっている人が多いだろうと思う。(ただ、TOEICの英語が実際*使えるか*と言う問題もあるが、また別の話なので触れないでおく。)

国語はどうか。文章を読む能力というか、日ごろから長い文章、ある程度体裁の整った文章を読むことはあるのだろうか。

前にも書いたようにここ最近Webを取り巻く情報のフォーマットが変化してきた。掲示板やメールに続いて、TwitterやSNS、ショートメッセージ。ここ10年の話。

上に挙げたような人が、よく目にする順序で言うと、今まではWebサイト, 小説, 技術書, 論文などだろう。それが、Twitter, RSS, ライトノベル, 携帯小説, 小説, Webサイト, 技術書, 論文などに変化してきたように思う。もちろん人によって順番が違うが、新しいメディアによって体裁の整った文章の比率が低くなっている傾向にあるのは間違っていないだろう。

例えば、新聞や小説に出てくる熟語やことわざ、言い回し、ほとんど理解できますか? 今までは覚えたはずのそれを上手に(ちょうどよい場所とタイミングで)使うことができますか?

自分の学生時代の体験からすると、そもそも長い文章を書くことはほとんど無かった。(小)論文を書くというクラスがあるが、これは選択制だったので全員が取っていた訳では無いし、授業の中(つまり半期)で1つのテーマに関してしか書かなかった。

それに、ある意味日課でもあったような授業の課題(レポート)での文章を書くということも、実験などの結果に関しての事実を文字に起こすだけで体裁の整った文章とはほど遠いものだろう。

本来なら教養の中で存在し得るはずのこの能力が無いのである。

さあ、どうするか。それは英語を意識して勉強するように、意識して積極的に読む、書くということである。それしかない。他にもっといい方法があれば教えてもらいたいのだが。言語は日本語でも英語でもいい。出来れば両方がいい。プログラミング言語っていうのはダメである。

国語力が良くなれば会話やプレゼンテーション、発表も良くなる。Google力(検索能力)も上がる。今やこれからの自分にすばらしいアイディアやすばらしい視点があったとしてもうまく正確に伝えられられなければ意味が無いだろう。

外から見れば、それを伝えないことは考えていないことに等しいのだから。

QuartzComposerとはMacのXCodeに付属の開発ツールである。これはビジュアルフロープログラミング言語と言われるマウス操作によってプログラムを作るためのツールだ。

検索するかQuartzComposerを立ち上げてもらうと手っ取り早いが、パッチと呼ばれる部品を線で接続してプログラムを作っていく。ただし、入力はキーボードやファイル、ネットワークなどさまざまなデバイスに対応しているが、出力は主に画面に限定される。

実際にはiMovieやPhotoboothなどの画像動画処理ソフト、各種ソフトの副次的なライブラリとして使われている。

UnixコマンドもといUnixの考え方は機能ごとに小さなコマンド群をそれぞれをパイプ ( | )やリダイレクト ( >, >> )でつないで、作業を行っていく。

一つ一つは低機能で単一のことしかできない小さく分離されたコマンドもパイプを使って組み合わせることによって、複雑で大きな作業もできる訳だ。逆にいえば、コマンドは独立していて汎用性がある。

そう、まさにQuartzComposer(QC)の部品は“Unixコマンド”、パイプは“線”である。QCも部品一つ一つの機能は単一であり、シンプルで他の部品からは独立しているし、線で複数の部品を組み合わせることで一つの大きな部品になる。

違うところと言えば、QCは部品に対して入力と出力が複数あるというところか。

QCはUnixという考え方に基づいた、面白い言語であるように思う。

もっと具体的に実際の言語で、コードで、説明しよう。手続き型の言語Cで書くプログラムをオブジェクト指向的に書き直すとどうなるのか。という話である。完全に理解するにはC言語の話が分かる必要があるので注意。Cは時代遅れだって? Appleプラットフォームはアプリレベルで普通に使っているし、まあいいじゃないか。確かにCはメモリ管理も無いし、ポインタは脆い。だけど昔も今も使われている。ちゃんと使えば安定した言語だよ。

Cの話は別の機会にするとして、今回はCで文字列のためのオブジェクト(String)を作ってみる。こんな感じのインターフェース(.h)を定義してみた。若干見やすい版。

typedef void* StringRef;

StringRef StringCreateWithCString(const char* cstr); // Stringを作成

StringRef StringCreateFromFile(const char* path); // ファイルから作成

int StringGetLength(StringRef str); // 文字列の長さを取得

float StringGetFloat(StringRef str); // 文字列から数値に変換

int StringGetInt(StringRef str);

char StringGetCharAtIndex(StringRef str, int index); // index番目の文字を取得

StringRef StringSubString(StringRef str, int start, int end); // 範囲をしていて文字列を取り出す

StringRef StringGetLowercaseString(StringRef str); // 小文字に変換

StringRef StringConcat(StringRef str1, StringRef str2); // 2つの文字列を連結

void StringWriteToFile(StringRef str, const char* filepath); // ファイルに書き込む

インターフェースとしてはだいたい、CFStringと同じである。

これを使うには次のようにすればよい。

StringRef mystr = StringCreateFromFile("test.txt"); // これでStringオブジェクトができた

printf("len=%d\n", StringGetLength(mystr)); // 長さを表示

StringRef str2 = StringCreateWithCString("Hello"); // 文字列からStringオブジェクトを作る

StringRef newstr = StringConcat(mystr, str2); // 2つのStringを連結

StringWriteToFile(newstr, "out.txt"); // ファイルに書き込む

前に説明したように一体化とカプセル化が実現されている。

文字列に対して手続き(処理, GetLengthなど)を行うにはその変数(mystrなど)を使わなければならない。また、文字列を連結するのにも書き込むのにも必ずメソッド(関数)を経由している。そもそも、typedefで最初に定義したように、Stringオブジェクトの中がどうなっているかはこちらからでは分からないのだが。

何か。Wikipediaを参照されたい。

何が言いたいのかと言うと、オブジェクト指向について本質的なところを理解するとき、売られているだいたいのオブジェクト指向と名の付いた本やプログラミング言語の本は良くないかもしれない。

どう解説しているかというと、たぶん大体オブジェクトをモノに例えているであろう。オブジェクトなんて現実に存在しないのに。

そこで、オブジェクト指向を理解するために違う説明の仕方をしてみようと思う。

そもそもオブジェクト指向というのは言語ではない。パラダイムである。

JavaとかC++とかはオブジェクト指向言語といわれることがあるが、これはオブジェクト指向のパラダイムを実装しやすいようになっているか、オブジェクト指向のパラダイムを実装したものである。Cでももちろんオブジェクト指向のパラダイムは実現できる。

オブジェクト指向のパラダイムとはなにか。

データと手続きの一体化とカプセル化

である。

データと手続きについては前の記事を参照。

ではこの一体化とカプセル化は何なのか。

一体化    データと手続きを1つのオブジェクト(or変数orポインタと呼んでもいい)にまとめる(保持するor定義する)ことである。データへアクセスするには必ずこのオブジェクトをたどらなければならない。1つのオブジェクト、この例ではvalとする。例えばJavascriptであれば、

val.count = 1;  // これはデータ

val.increment() // これは手続き(メソッド)

となるだろう。valにはcountというデータが定義されて、increment()をすることでcountが1増える(手続き)。valには1つのデータ(count)が定義されているが、これに加えてこの変数valに1つの手続き(increment)を定義するのである。そうすると、valに対してデータと手続きがまとめられた。定義された。(データと手続きは2つ以上でもいい。)

言語によってはデータはインスタンス変数と言われ、手続きはメソッドと言われる。

カプセル化    オブジェクトに定義されたデータを操作したりアクセスしたりするときは必ず、オブジェクトに定義された手続き(メソッド)を使うようにすること(させること)である。

実は上の例ではvalに定義されたcountはカプセル化されていない。直接アクセス(参照)しているからである。

なのでこのように変えてみよう。

val.getCount() // 戻り値でcountを値を取得

val.setCount(c) // 引き数cでcountの値を設定

val.increment() // これは手続き(メソッド)

これでcountにアクセスするのはすべてメソッドということになった。

ちなみに元々あったval.increment()はカプセル化されているといえる。countを1増やすことに関してはincrement()メソッドそれ自身を使っているからである。自分はcountを直接操作(1増やす)していないからである。

つづく。