プログラミング道場生kumamidoriです。
PHPフレームワークの１つに、「BEAR.Sunday」があるのをご存知でしょうか。
リソース指向のOSSフレームワークで、郡山さん（@koriym）によって開発されています。
去年イギリスで行われたカンファレンス、「PHPNW2013」では、BEAR.Sundayのアーキテクチャを紹介するセッションがありました。
私は以前、旧バージョンにあたる「BEAR.Saturday」の方を仕事で使っていました。新しいBEAR.Sundayついては、初学者の状態で、さわる機会もあまりなかったのですが、気になっていました。2013年7月には、BEAR.Sunday meetup #2の主催をさせて頂いたこともありました。
そのようないきさつがあり、4月7日、BEAR.Sunday meetup #3 in Osakaを開催することになりました。 郡山さんに、PHPNW2013でのセッションをアップデートした内容で再演して頂きました。
参加者を引き込む素敵なセッションをして下さり、ありがとうございました。
また、会場提供を引き受けて下さった1x1株式会社の新原さん（@shin1x1）に、お礼申し上げます。
この記事では、セッション内容の抜粋と、個人的感想を書きます。
1. セッション内容の抜粋
1-1. なぜ新しいフレームワークを作るのか
- Quality と Agility の時代
Webアプリケーションは、長期的に改善し続けていく必要のあるものである。Quality と Agility の時代と言える。 Agilityとは、「すぐに変更することが可能である」ということ。
PHP5.3以降のPHPフレームワークには、単に「動くものを速く作る」のとは、少し違った流れがあった。 多くのPHPフレームワークが揃ってDIを採用したことは、その一例と言える。
- フレームワーク、アーキテクチャ
大事なのは、あなたは何をしたいのか？ということ。 「自分たちのドメインの問題」を解決するためのフレームワークを持つことに意味がある。
PHPNW2013の来場者が興味を持っていたのは、「次のアーキテクチャは何か？」ということだった。 たとえば、Symfony1 から 2 へ、Zend1 から 2 へ、成功したフレームワークはどれも、ユーザが「バージョンアップのための、大幅な書き直し」を経験してきた。 Symfony2 から 3 で、またあれをやらなければならないのか？！という問題がある。そういった問題を、どのような技術で解決できるのかという視点、アーキテクチャの選定、という意味で、新しいものを探そうという動機から、BEARのセッションを聞きに来てくれた。
1-2. PHPNW2013「A resource orientated framework using the DI /AOP/REST Triangle」再演
（※NW2013当時の、作者ご本人のプレゼンテーション内容紹介エントリーを見て頂く方がエッセンスが伝わると思うので、そちらをご参照頂ければと思います。 私の記事では、背景、前提となる知識の部分に話題を絞ってメモします）。
BEARはアプリケーションフレームワークだけれども、ライブラリを持たない。良いライブラリは既存でたくさんあるから、再発明の必要が無い。
そもそも、フレームワークとは何か？
広義の意味：
imposes a set of design constraints on end-user code.
エンドユーザのコードに対して、設計上の全体的な制約を与える。 (by Nate Abele)
狭義の意味：
「呼ぶ」側-「呼ばれる」側の関係が逆転して、「呼ぶ」側をフレームワークが最初からお膳立てし、「呼ばれる」側だけをユーザが書く。
BEARの場合は？：呼ぶ側もユーザが書く。
BEAR.Sundayは、3つのオブジェクトフレームワークを持つ。
(1) DI Framework
前提知識となる Dependency Inversion Principle （依存関係逆転の原則、DIP）についての話があったのですが、文末の参考リンクに詳しい解説があるので、ここでは省きます。
(2) AOP
- たとえばあらゆるモジュールに散在してしまうロギングのような、 横断的関心事（Cross-Cutting Concerns）を分離することで、 モジュール間を疎結合とするプログラミングパラダイムのこと。
- アプリケーションロジック（ログ、キャッシュ、etc…）とドメインロジック（コアの関心事）を分離する。
(3) REST（Hypermedia Framework）
オブジェクトをWebサービスのように扱う。
RESTとは：クライアントとサーバにWebは分かれている。決まったメソッドしか使えない。リクエストは1回だけで、ステートレスである。
このアーキテクチャを、OOPアプリケーションの内部に適用している。リソースとリソースをハイパーリンクによってつなぐことができる。
情報に真の意味での価値を与えるのはそのつながりである。
実装を直接書くのではなく、まず、抽象化された意図を記述する。次に、その意図に役割を与えて動かす（実装を結合する）。
セッション内容については以上となります。
2. 個人的感想
下記が分からなかったので、今後調べていきたいと思いました。
- 他の言語、たとえばRubyでは、変更の安全性（ある1箇所を直したら、あちこちに影響が出たり、予想もしないところに作用が出たり、といったことを防ぐ）を、どう担保しようとしているのか？
- 複雑なロジックでも、DIのランタイムとコンパイルの分離で表現できるのか？
- セッションの中で出てきた、「staticコールだとAOPはうまくいかない。インターフェイスでないとうまくいかない。」という話のくだりのところが理解できなかった。自動生成の仕組みを調べておきたい。
やはり、熟練者でないと、実際に使ってみないとよくわからないので、小さなモノを作ってみるところから始めてみたいと思います。
（今回一緒に主催をしてくれた @atakig さんが直立不動の写真を載せておきます）。
関連リンク
過去に開催されたイベント
参考
BEAR.Sundayの紹介記事です。
Dependency Inversion Principle （依存関係逆転の原則）、DIに関するリンクです。
