ワークショップで理解した #BEARSunday の基礎まとめ

48JIGEN Reloaded

ワークショップで理解した #BEARSunday の基礎まとめ

2012/12/22

傍から見ていると訳が分からないムーブメントかもしれません。クマ顔のアイコンでお馴染みの@koriymさんだけでなく、PHP界隈（特にSymfony界隈）の方々も参加されているBEAR.Sundayの開発は、僕にとって2012年に最も注目度の高いプロジェクトの一つでした。

幸運にも合計2回の@koriymのワークショップ（PHPMatsuri 2012＠福岡と先週の#symfony_jaの勉強会）に参加する機会に恵まれて、少しずつ理解しきれてなかった部分が自分で消化できるようになってきました。

今日はBEAR.Sundayを見たことがない人や、これまで遠巻きに見てきて馴染みが薄い人を対象に、年明けに向けて着々と完成に近づきつつあるBEAR.Sundayの概要を独断と偏見でまとめます（本稿では現在の最新版ver0.5.5を使用）。なお、このブログは #phpmatsuri のLTで約束したBEAR.Sundayへのコミットです。

（１）ソースコードの入手

BEAR.Sundayを利用するためには、実際には以下の2つのリポジトリを参照することになります。

パッケージ名	説明	Github	プロジェクトページ
BEAR.Sunday	フレームワークの中核機能群	本家	wikiへ
BEAR.Package	アプリケーションとフレームワークの中間に存在する機能群。ライブラリの選定とその設定のための抽象レイヤー。	本家	wikiへ

この先を読み進めてもらえるなら、BEAR.Packageのソースコードをダウンロードして参照しながら読むと良いかも。ちなみにインストールもcomposerで数コマンドで完結するから、ベストはインストールまでできると学習効果が抜群に高くなります。

なお、BEAR.Packageは初心者の僕には高機能すぎて使いこなせない予感がしたので、フレームワークの学習のためにBEAR.Packageから最小限の機能だけを抽出したオレオレSandboxアプリを作りました。デバッグ関係の機能（DevModule周り）とか使わないファイルとかをカットすることで、基本的なフレームワークの骨組みの理解に集中しやすいように構成しています。賞味期限がありそうだけど、うまくいけば来月（2013年1月）くらいまでは使えるかも。
※インストールしたい人はBEAR.Packageをこのブログに従ってインストールした後で、apps/Sandboxフォルダだけ僕のブランチのapps/Sandboxフォルダに差し替えれば使えるはず。@mention飛ばしてくれれば分かる範囲で相談に乗ります。

（２）アプリケーションの骨組み

まずはサンプルアプリケーションの構造を見ていきます。ふつうのMVCアプリケーションとどう違うか、という観点で見ていくとわかりやすいかもしれません。以下はBEAR.Packageのapps/Sandboxフォルダ以下の構造の説明です。(Githubでソースをブラウズできます)

　・data : ログデータや一時的なデータ保存場所
　・http : 40x, 50x系のレスポンスコードを返す時のコードを置く
　・Interceptor : AOP用
　・Module : 依存の注入や、Interceptorを織り込む処理を記述する
　・public : 外部からアクセスされるファイル
　・Resource : リソースオブジェクト
　・scripts : publicフォルダとtestsフォルダから呼ばれる共通の初期化処理等を格納
　・tests : テストコード

このフォルダ階層では、ModelもControllerもViewも登場しません。その代わりに、BEAR.SundayではResource(リソースオブジェクト)が登場します。Viewに相当するのは、、Resourceやpublicを足したものって感じでしょうか。

InterceptorやModuleという言葉の説明は一旦置いておいて、まずはModelやViewがどう動いてるかを見てみます。

（３）リソース指向のフレームワーク

ふつうのフレームワークでいうところのいわゆるModelのコードをBEAR.Sundayではアプリケーションリソースと呼び、Controllerのコードをページリソースと呼びます。ここでは例として、Sandbox中のあるアプリケーションリソース（apps\Sandbox\Resource\App\Blog\Posts.php）からクラス名とメソッド名のみを抜粋したものを取り上げます。

class Posts extends ResourceObject
{
    public function onGet($id = null)
    public function onPost($title, $body)
    public function onPut($id, $title, $body)
    public function onDelete($id)
}

読みやすいでしょうか。勘が良い人は、このオブジェクトがCRUD全ての機能を持つことがわかると思います。メソッドがRESTfulなインターフェースっぽく見えます。

BEAR - Because Everything is A Resource

BEAR.SundayではふつうのMVCフレームワークでいうところのModelとControllerの両方をリソースという包括的な概念で再定義します。ModelもControllerもリソースである、と考えるわけです。これがBEARがBecause Everything is A Resource（訳："全てはリソースである"）の略で表される由縁です。ModelやController以外のリソースもユーザが定義することができます。

リソースの設計はRESTの考え方に従います。RESTではオブジェクトは状態を持たないので、リソースオブジェクトのソースコードには例えばstaticキーワードは登場しないでしょう。また、標準的なインターフェース（GET/POST/PUT/DELETEなど）を使います。

先程のPostsオブジェクトがどのように呼び出されるかを見てみましょう。

$this->resource
        ->get
        ->uri('app://self/blog/posts')
        ->request();

例えばdeleteするときも同じ感覚で呼び出します。

    $this->resource
        ->delete
        ->uri('app://self/blog/posts')
        ->withQuery(['id' => $id])
        ->eager
        ->request();

eagerとか一部の不明なメンバを除けば、ざっくりなんとなく何やってるかわかりますね。（eagerはDIのバインディングの話で出てくるのですが、ここでの説明は割愛させてください。詳しく知りたい方は、英語ですがAura.DIのREADME.mdを尋ねるとよくまとまっていてオススメです。）

アプリケーションリソース（Model）へは、コードからだけではなく、例えばコマンドラインからこんな風にもアクセス可能です：

$ cd apps/Sandbox/public
$ php api.php get app://self/blog/posts

Postリソースオブジェクトにソースコード上から'app://self/blog/posts'というURIの形式で書かれた一意の文字列でアクセスできたのとちょうど同じように、コマンドラインからも同様の呼び出しが可能になっていることが分かります。（更に興味を持った人は、BEARのブログを参照してください。）

考えてみる

ModelやControllerをリソースとして捉えてRESTfulに設計することのメリットは何でしょうか。何か課題を解決することにつながるのでしょうか、それとも解決にはあまり結びつかずに、エンジニアの自己満足で終わってしまうでしょうか。

RESTによって提供されるシンプルなインターフェースのおかげで、
・CRUDの在りかが常に明確になりコードが読みやすくなったり
・メソッドの命名で悩む機会が減ったり（例えば登録処理をaddと表現するのか、insertなのかregisterなのか（はたまた"regist"なのか）、など）
・例えばメソッドの粒度が十分に小さくなるように促される効果も考えられるでしょうか

このあたりはまだBEAR.Sundayを利用した経験が浅く想像の域を超えませんが、シンプルな設計を志向することにはつながりそうな感じがします。逆にデメリットは何だろう。自分でもよく考えてみます。

（４）ModuleとInterceptorのはたらき

説明が佳境に入ってきたところで、何なのですが、力尽きてきました。。。かいつまんで説明すると、
・Moduleオブジェクトのconfigure()メソッドで$this->bind()することで依存の注入ができる
・$this->bindInterceptor()することでインセプタを織り込んだりできる
っていうことなんですが。。。けっこう長くなってきてしまったのと、一人で延々と書いていて読み手の理解度も全然つかめないままなので、今日はこの辺までにしておきます。もう少しアプリを書いて経験を積めばもっといい内容を書けそうな気もするし。

これから実際にModuleやInterceptorのソースを触りながらトライアンドエラーする人がいたら、BEARのwikiが良い道しるべとなってくれます。基礎を理解するのであればはじめてのシリーズが、より理解を深めるために本格的な解説のwikiを読み進めると良さそうです。

短いブログですが、BEAR.Sundayを利用する方法の雰囲気が少しでも伝わることを願っています。

（５）あとがき

今年絡んで頂いた皆様、大変お世話になりました。来年も宜しくお願いします。既に準備活動がスタートしてる来年のPHPMatsuri@北海道の青年団のサポートや、BEAR.Sundayを更に深く使っていく過程を通して、また色々な発見や出会いがあることを楽しみにしています。

最後にBEAR.Sundayの七不思議を考えてみたんですが、流行らないですかね・・・どうでしょうか・・

なぜ開発が非常にアクティブなのか？
なぜ日本のSymfony界隈の人がたくさん集まってるのか？
なぜこんなに初期の開発でネイティブの方がドキュメントを英訳してくれてるのか？
なぜ12月に入って中の人がAdvent Calendarを*一人で黙々と*更新してるのか？
"クライアントやサーバーサイドがどんなに複雑に高度になってもHTTPという接続技術のアーキテクチャが基本的に変わらず機能し続けてきた"ことがやっぱり不思議
なぜいま日本発の本格的なOOPフレームワークがPHPで生まれているのか？
そんな興味深いBEAR.Sundayのワークショップが開かれるPHPMatsuriは素晴らしくないか？（ステマ）

エンドロール

（PHP: Dis Is It中のスライドより抜粋）

　
これはどの言語にも起こる事なんだ、
VBがいい例だ。
VBに根本的に悪いところがあった訳ではない。
　
単なるコンピュータ言語だ。
　
しかし、酷い exmaple code が使用例として蔓延してしまった。
　
そしてそれがbad codeだと分からないレベルのプログラマー達によって、いたるところで使われてしまった。
　
そうやって、VBはその酷いcodeでも問題にならない場所で使われて行くようになってしまった。
　