BEAR Blog http://www.bear-project.net/blog Because everything is a resource. Fri, 18 May 2012 06:52:49 +0000 ja hourly 1 DIP：Dependency Inversion Principle http://www.bear-project.net/blog/2012/05/dip%ef%bc%9adependency-inversion-principle/ http://www.bear-project.net/blog/2012/05/dip%ef%bc%9adependency-inversion-principle/#comments Fri, 18 May 2012 06:15:30 +0000 admin http://www.bear-project.net/blog/?p=1528 Read more »]]> DIP

Robert C. Martin氏による有名なオブジェクト指向設計（OOD）の原則Principles of OODがあります。そのうちDIP依存逆転原則はクラス同士の結合度をいかに減らすか、またはどちらに依存すべきかを判定する原則です。

  • 上位モジュールは下位モジュールに依存してはならない。両者は抽象に依存すべきである。
  • 抽象は詳細（抽象の実装クラス）に依存してはならない。詳細は抽象に依存すべきである。

以下はオリジナルの論文の結びの言葉です。

依存性逆転の原則は、オブジェクト指向技術で得られると言われる数多くの利益のうち、もっとも根幹にあたる部分に位置付けられます。この原則を適切に適用することは、再利 用可能なフレームワークを構築する上では不可欠なのです。また、変更に際して回復の早い(弾力的な)コードを書く上では決定的な重要性を持ちます。抽象とこまごまとしたものはそれぞれが分離さるので、コードはとてもメンテナンスしやすいものになります。

BEAR.SundayではこのDIPを最大限に重要と考え、コード全域に渡って適用しています。1

実装ではなく抽象に依存する

解説してる文章で最も短く簡潔なのがStrategic Choiceブログの説明です。

DIPを一言で説明すると「抽象に依存せよ」という経験則。
プログラムは具体的なクラスに依存してはいけない。
プログラム内の関係はすべて、抽象クラスかインターフェースで終結すべきである

BEAR.Sundayのクラスでは、以下のように依存は原則全て注入してもらう事を期待します。

    /**
     * @Inject
     */
    public function setPrinter(OutputDevice $printer)
    {
        $this->printer = $printer;
    }

ここで大事なのはタイプヒンティング（この場合OutputDevice）を抽象、つまりインターフェイスかまたは抽象クラスにして具象クラスをタイプヒントにしないことです。タイプヒンティングをエラーチェックのための便利な機構とだけ捉えずDIPに従った設計のための仕組みとして考えます。

アンチパターン考察

前回記事と今回のDIPを合わせて考えてアンチパターンになるのが以下のようなコードです。

$id = $this->container('serviceA')->getB()->getC()->getId();

このコードでは抽象への依存はなくコンテナに入った実装に依存しています(DIP違反）。メソッドチェーンで繋がれた依存の依存が持っている知識を前提としていて(LoD違反）オブジェクトの構成要素は暴露されています。こういったオブジェクトを探しまわるコードを止めて、インターフェイスを通じて依存を受け取るコードに変更します。

BEAR.Resourceでは

DIを用いてDIPを守る事は特にリソースクライアントのBEAR.Resourceを作成するときに有用性を特に実感しました。リソースクライアントのオブジェクトグラフは複雑です。最も簡単なコンストラクトに以下のようなコードが必要です。2

$injector = new Injector(new Container(new Forge(new Config(new Annotation(new Definition)))), new EmptyModule)
$invoker = new Invoker($injector, new Linker, Manager(new HandlerFactory, new ResultFactory, new ResultCollection));
$resource = new Client(
    new Factory(new SchemeCollection),
    $invoker,
    new Request($invoker)
);

全ての依存をコンストラクタで手動で渡してるためにこんなに長くなっていますが、多くの役割をこなすリソースクライアントはそれぞれ関心が分離され別々のオブジェクトとなっています。

構成は複雑なのですが、DIPやLoDに従っていることで、各クラスの責務は適切なスコープをもちメンテナンス性は保たれているコードになっているのではと考えています。これをアンチパターンで示したようにオブジェクトを探し回してその実装に頼るコードにしてたらまた違った事になったかもしれません。

Ray.DiでDIP

昨日の記事をかいたあとにこのDIPの事を触れてなかった事を思い出し3原文調べ直すとに「もっとも根幹にあたる部分に位置付けられます。」という記述を見つけてそうだ、そうだとなったのでこの記事を追加で記しました。BEAR.Sundayの機能をささえる大くの部分がリソース指向やAOPで実現されますが、それらのコードはこのDIPに従うためのRay.Diで構築されています。

アプリケーション構築もまたDIPに従ったものが推奨されます。そしてそれをより容易に実践するためにトレイトによるインジェクション等の取り組みがRay.Diになされています。

  1. 実際にフレームワーク開発の前に着手したのがこの実現のためのDI systemのRay.Diです
  2. これでも何のスキーマも解釈できませんが
  3. 最大限重要と考えてたくせに–;
]]> http://www.bear-project.net/blog/2012/05/dip%ef%bc%9adependency-inversion-principle/feed/ 0 BEAR.Sunday Coding http://www.bear-project.net/blog/2012/05/cleancode/ http://www.bear-project.net/blog/2012/05/cleancode/#comments Thu, 17 May 2012 13:15:27 +0000 admin http://www.bear-project.net/blog/?p=1483 Read more »]]> The new era of PHP web development

BEAR.Sundayの開発をスタートしたときに、web制作の現状や求められるものは？という視点で考察を行いました。その結果をスライドとしてまとめたのがこのThe new era of PHP web development.というスライドです。1約一年前です。

高速開発をセールスポイントにした従来のフレームワーク（もっといえばPHPそのものも）がQualityとAgility、つまり「ソフトウエア品質」に軸足を移している動きがあるのではないか？PHPの言語仕様だけでなく、作り手も求められてるものも変わってきてるのではないか？という考察でした。

一説によるとweb制作の仕事の80%はメンテナンスだそうです。どれだけ楽に早くつくれるか、という視点は人々の目を引きつけ、プロトタイピングの時に力を発揮し、初期の成功もより容易にします。 しかしそれは変更保守やスケーラビリティ、柔軟性、メンテナンス性と両立するか?というソフトウエア品質の視点もそれ以上に重要と考えました。

BEAR.Sunday Code

BEAR.Sundayを完全にリライトすると決めた時、その機能設計と共にClean Codeでの実装にも注力しようと思いました。フレームワークの機能提供は大事ですが、フレームワークがユーザーによって変更拡張可能かという点も同様に重要と考え、更にその柔軟性とメンテナンス性のためフレームワーク自身のコード品質も重要とも考えました。新規プロジェクトでBEAR.Saturdayではできなかったあの機能もこの機能もと実装中心に考えがちですが、むしろそれら新機能の実装の着脱が容易になる優れた設計こそに価値があると考えました。

設計とともにBEAR.SundayをCleanなコードでコーディングをするためにいくつかの原則を最初にたてました。最初にたてた原則にはこれまでにない色々な挑戦もありました。ある程度実装が進んだ今、その原則に従う事が現実的であったか、また有効であったかが明らかになってきました。この記事ではそれらのうちのいくつかを紹介します。23

適切なスコープ

Global ?

どこからでも扱える変数グローバル変数の使用の抑制が一般化されている一方で、同じようにグローバルステートをもつクラスのスタティック変数はやグローバルな関数であるstaticメソッドの利用はそれほどでもないと思います。BEAR.Sundayではこれらの使用を最小限にする方針をたてました。

スタティックコール

スタティックコールはグローバルなメソッドです。インスタンスにせずどこからも呼び出しすることができます。つまりOOPでなく手続き型で、モックへの差し替えが難しくテスタビリティを下げる、等がさけるべき理由としてあげられています。4

BEAR.Sundayのクラスでスタティックコールを使用していのはRay.DiでDependency Injectorをつくるときと、アプリケーションインスタンスをつくるとき、この２つです。どちらもアプリケーションがbootされ、グローバルスコープの状態で最初期のルートオブジェクトを作成するためのメソッドとして実装しています。

これを問題ないと考えたのはブートされたばかりのアプリケーションはまだグローバル空間でグローバルステートのものを扱うのは自然と考えたからです。グローバル変数も同様です。下記の記事はオブジェクトの作成は問題ないとする考察です。

Static Methods will Shock You: When static methods can be good

bootでグローバルなスコープしかなかったものが、様々な関心を取り扱い、それぞれの関心空間が作られていきます。その関心空間（スコープ）でグローバルなものを扱う事が問題なのです。シングルトンも同様です。インスタンスが１つしか無い事が問題ではなく、それがグローバルに適用されるという事が問題です。重要なのはスコープです。

グローバルステートの環境依存も最小に

  • グローバルスコープのシングルトン
  • グローバルdefine
  • include_path

BEAR.Sundayでは同一インスタンスで他のアプリのアプリケーションリソースやページを呼ぶ事を可能にするため、これらのグローバル依存を最小限にする必要があります。原則的にこれらを全て不使用にする方針は前述の例外を除いて守られています。Saturdayで３つしかなかった”define”も０にしました。

デメテルの法則

デメテルの法則とは「自分以外の構造やプロパティに対して持っている仮定を最小限にすべき」という原則です。これはBEAR.Saturdayで守られてない部分がありフレームワークを保守する身として後で反省のある部分となったとこです。以下のようなコードです。

$this->_resource->read($params)->link('entry')->set('user_entry');

このコードではread()メソッドの実行後は「readで取得したオブジェクト」に変わってしまっていて`link()`以降のメソッドでLoD違反になってました。この弊害というのはフレームワークの保守の時に実感しました。

BEAR.Sundayでのこのfluent interfaceによるリクエストにLoD違反はありません。

$this->resource->get->uri('app://self/greetings')->withQuery(['lang' => 'ja'])->eager->request();

最後のrequest()以外は全て$thisを返しています。この原則は設計も実装もずっとシンプルでテスト、保守がしやすいものになりました。

他でもほぼ守られてると思いますが例外はあります。Aura.Diを拡張して実装したRay.Diは元のAura.Diで 

getA()->getB()->getC()

系のコードをそのまま引き継いで違反してます。

setter/getterの除去

最初の記事にあるようにダブルディスパッチやInformation Expertで、外部からオブジェクトのプロパティをなるべく利用しないようにし、またsetter/getterを通じてオブジェクトの内部構造を暴露しないようにします。

LoDの場合と同じくRay.Diはsetter/getter使ってますが、他はは大体守れてると思います。リソースも内部構造を曝す事なく情報を結合するリソースリンクがあり、ビューにモデル(appリソース）のプロパティを渡すのではなく、モデルがビューを保持しモデルの構成要素がなるべく曝されない設計になっています。

またcode/bodyといったプロパティを必要とするリソースオブジェクトは、プロパティを公開（public）しています。このようなコードでリソースオブジェクトの構成要素が必要なときでもLoD違反にならないようにしています。6

$resource->get->uri('app://self/user')->eager->request()->body['is_valid'];

Conclusion

他にも沢山あるのですが特に今回の挑戦としてた項目について説明しました。

大事なのはこれらの原則はあくまで原則で絶対守らなければならない鉄則ではないということです。世にある様々なデザインパターンや設計原則は有用で学習すべきものが多くあると思うのですが、多くの場合その有用性、有効性も「場合による」事が少なくないと考えます。議論の別れるものもあるし、例えばここでアンチパターンとした「スタティックコール」が有用な場合はやはりあるでしょう。それを使ってるだけで「駄目」「いけてない」というような判断をする事は正しくありません。

逆に一般に良くないとされてる事でも使い方や場合によってはより正しく機能する事もあります。goto文やpublicプロパティの「いけてない使い方」だけをみて感情的な反応を示す事は、PHPの駄目コードだけをみてPHPそのものを批判する愚に似てるかもしれません。

プログラマの意図（インテンション）を表し簡潔で保守性の高いClean Codeを記述するのはいくらコーディングを重ねても難しいもので、またやりがいのある事でもあります。

BEAR.Sundayではこれまでになく注力したつもりですが、やはり反省も多く今後リファクタリングが必要なところも多くあると思います。そういう意味で少し恥ずかしいところもあるのですが、こういう意図を持って取り組んできたという記録です。

  1. たまたま飛び入りでPHP勉強会で発表となりました
  2. 実際のコードには反省のある箇所もありリファクタリングの必要な箇所も残されています
  3. 原則は他の「機能性」やリーダビリティを犠牲にしてよい鉄則ではなくて基本原則です、ある場所では破ってるとしたらそれは仕方なく、あるいは力足りず..という事もあります
  4. 個人的にはスタティックコールより副作用のない事が保証される名前空間付き関数の方が良いのではと思いますがどうでしょう。
  5. 他にも”static method” evilで検索すると色々記事が出てきます。
  6. SaturdayのgetBody()は違反でした
]]> http://www.bear-project.net/blog/2012/05/cleancode/feed/ 0 v0.2.0alpha http://www.bear-project.net/blog/2012/05/v0-2-0alpha/ http://www.bear-project.net/blog/2012/05/v0-2-0alpha/#comments Tue, 15 May 2012 15:10:30 +0000 admin http://www.bear-project.net/blog/?p=1464 Read more »]]> BEAR.Sunday v.0.2.0alpha

v.0.2.0alphaをリリースしました。

今回のリリースはblogチュートリアルのためのサンプルアプリケーションの実装を中心に、CRUDアプリケーションを通してアプリケーションモジュールの構成や基本実装を中心に行ったものの結果です。

オブジェクトフレームワークとしては当初の設計の完成に近づき、APIフレームワーク、Webフレームワークの部分実装が加わったものが今回のリリースになります。

blogチュートリアルはCakePHPのCakePHPブログチュートリアル日本Symfonyユーザ会の Symfony Blogチュートリアル、Symfony2 Blogチュートリアル、BEAR.Saturday Blogチュートリアルで作成するものと同じもので、比較が容易になるように構成もそれぞれ似せています。同じアプリの制作という制約があり充分ではないですが、なるべくBEAR.Sundayの特徴が分かるようにしました。

ご感想、お気づきの点などあれば是非お聞かせ下さい。 @BEARSunday

    ]]>     http://www.bear-project.net/blog/2012/05/v0-2-0alpha/feed/ 0     Object Framework – Ray.Aop http://www.bear-project.net/blog/2012/04/object-framework-ray-aop/ http://www.bear-project.net/blog/2012/04/object-framework-ray-aop/#comments Fri, 27 Apr 2012 13:39:05 +0000 admin http://www.bear-project.net/blog/?p=1373 Read more »]]> Apect Oriented Design

    メソッド・インターセプター


    例えばテスト用途にどんな引き数が渡されても特定の同じ値を返さなければならないとします。

    あるいはアジリティを重視した開発で、メソッド内のコードや利用データベースが用意できていない段階でも適当に用意した値を返す必要があるとします。

    このような場合、通常テスティングフレームワークを使いモックオブジェクトを生成して利用します。BEAR.SundayのRay.Diのモジュールでモックオブジェクトを用意して差し替える事もできます。しかしRay.Aopの提供するメソッドインターセプターを使えば更に簡単です。

    メソッドインターセプターはメソッドの実行を乗っ取り代理実行します。モックオブジェクトは対象オブジェクトを入れ替えますが、インターセプターは対象オブジェクトとそれを利用するコンシュマークラスの間に割り込み（インターセプト）します。

    まずは基本になるオリジナルのメソッド実行と同じ動作をするインタセプターのコードです。

    class GreetingInterceptor implements MethodInterceptor
    {
        /**
        * (non-PHPdoc)
        * @see Ray\Aop.MethodInterceptor::invoke()
        */
        public function invoke(MethodInvocation $invocation)
        {
            $result = $invocation->proceed();
            return  $result;
        }
    }

    MethodInterceptorインターフェイスのinvoke（実行）というメソッドにはMethodInvocation（メソッド実行）オブジェクト$invocationが渡されます。

    メソッド実行オブジェクトはメソッドの実行に必要な全ての知識（対象インスタンス、メソッド名、引き数等）を持っています。オリジナルのメソッドを実行するためには$invocation->proceed();を実行します。

    この実行の前後に処理を記述したりすることで元も処理をまたぐ事ができます。引き数を操作したり変更したりすることもできます。1またインターセプターを同じメソッドに複数適用することもできます。

    テスト用に常にここのメソッドが”HelloTest”を返す為には以下のように変更します。

    class GreetingInterceptor implements MethodInterceptor
    {
        /**
        * (non-PHPdoc)
        * @see Ray\Aop.MethodInterceptor::invoke()
        */
        public function invoke(MethodInvocation $invocation)
        {
            // $result = $invocation->proceed();
            return  "HelloTest";
        }
    }

    このGreetingリソースに限らず、何のリソースでも使えるようにコンストラクタでmockを渡せるようにしたインタセプターはこのようになります。

    class MockResourceInterceptor
    {
        private $mock;
        public function __construct($mock)
        {
            $this->mock = $mock;
        }

        public function invoke(MethodInvocation $invocation)
        {
            $return $this->mock;
        }　
    }

    インターセプター・バインディング

    このインターセプターを特定のクラス、特定のメソッドにバインドするのも「モジュール」で行います。このバインドはsandbox\Resource\App\Greetingクラス（およびその継承したクラス）のどのメソッドにもMockInterceptorインターセプターを適用します。

    $this->bindInterceptor(
        $this->matcher->subclassesOf('sandbox\Resource\App\Greeting'),
        $this->matcher->any(),
        [new MockInterceptor]
    );

    バインド対象を指定するためのマッチャーはアノテーションを指定したり、Callableオブジェクトを指定することもできます。

    @Cacheアノテーション

    BEAR.Sundayはいくつかのインターセプターを用意しています。その内、Cacheインターセプターは特に有用でしょう。このアノテーションはメソッド実行の結果を指定の秒数キャッシュします。

        /**
         * @Cache(60)
         */
        public function onGet($lang = 'en')
        {
            ...
        }

    このインターセプターのソースを見てましょう。

        public function __construct(Cache $cache) {
            $this->cache = $cache;
        }

        public function invoke(MethodInvocation $invocation) {
            $class = get_class($invocation->getThis());
            $args = $invocation->getArguments();
            $id = $this->getId($class, $args);
            $saved = $this->cache->fetch($id);
            if ($saved) {
                return unserialize($saved);
            }
            $data = $invocation->proceed();
            $annotation = $invocation->getAnnotation();
            $time = $annotation->time;
            $this->cache->save($id, serialize($data), $time);
            return $data;
        }

    インターセプターはというMethodInvocationインターフェイスを実装します。2 引き数や対象メソッドをキーにキャッシュにを生成していて@Cacheアノテーションで指定された括弧内の秒数だけキャッシュデータを再利用するようになっています。

    @Cacheアノテートされたされたリソースはアノテートがされただけでこれが実際にはどのインターセプターがバインドされるのかはこのクラスからは宣言していません。3 このアノテーションが実際にどのインターセプターが適用されるのか、あるいはそもそもインターセプターが適用されない（開発時など）といった構成知識に関わりがありません。Ray.Diの@Injectアノテーションと同じように構成は利用される側でなく利用する側が持ちます。

    ランタイムインジェクター

    BEAR.Sundayのオブジェクトの実行は最初の１リクエストでオブジェクトフラフのコンストラクションを完了するコンパイルと、以降のランタイムに分けられます。

    コンパイルでリクエストをまたいで再利用可能なオブジェクトをつくるために、リクエスト毎にディペンデンシーを変えてインジェクトをしたりすることはできません。4

    例えばDBオブジェクト5 のmaster / slaveをメソッドに応じて自動で選択するために、GET（読み込み）かそれ以外のメソッドでインジェクトを変えるという事はRay.Diのインジェクターではできません。

    この場合インターセプターを使ってDBオブジェクトをメソッドにセットしてやることができます。

    インターセプターはメソッド実行の情報が渡されるので、実行メソッド名をみてmaster/slaveのDBを選択することができます。master/slaveに限らずユーザーIDに応じたDB選択や、DBに応じた初期化などもインターセプターで記述できます。リソースをリクエストするクライントもそれを受けるappリソースも本来の仕事、つまり本質的関心(core concern)にのみ専念し、DBオブジェクトの準備というリソースをまたいだ横断的関心事(cross cutting concern)から関心を分離することができます。

    Postsリソースクラス

    /**
     * Posts
     *
     * @Db
     */
    class Posts extends ResourceObject implements DbSetter
    {
        /**
         * Table
         *
         * @var string
         */
        private $table = 'posts';

        /**
         * DB
         *
         * @var Doctrine\DBAL\Connection
         */
        private $db;

        /**
         * Set DB
         *
         * @param Connection $db
         *
         * @return void
         */
        public function setDb(Connection $db = null)
        {
            $this->db = $db;
        }

        /**
         * Get
         *
         * @return array
         */
        public function onGet()
        {
            $sql = "SELECT id, title, body, created, modified FROM {$this->table}";
            $stmt = $this->db->query($sql);
            $this->body = $stmt->fetchAll(PDO::FETCH_ASSOC);
            return $this;
        }

        /**
         * Post
         *
         * @param string   $title
         * @param string   $body
         * @param DateTime $created
         * @param DateTime $modified
         *
         * @return \sandbox\Resource\App\Posts
         */
        public function onPost($title, $body, $created = null, $modified = null)
        {
            $this->db->insert($this->table, ['title' => $title, 'body' => $body]);
            $this->code = 204;
            return $this;
        }
    }

    @Dbアノテーションクラス

    /**
     * Db
     *
     * @Annotation
     * @Target("CLASS")
     *
     * @package    BEAR.Framework
     * @subpackage Annotation
     */
    final class Db
    {
    }
    モジュール内でDbインジェクターをバインド
            $this->bindInterceptor(
                $this->matcher->annotatedWith('BEAR\Framework\Annotation\Db'), // クラスに@Dbとアノテートされた全てのクラス
                $this->matcher->any(), // 全てのメソッド
                [$dbInjector] // 複数バインドできます
            );

    Conclusion

    Ray.Diのインジェクションシステムはコンシュマーとディペンデンシーの関係を疎にしアプリケーション構成を柔軟にします。コンパイルされた関係性は再利用されオブジェクトとオブジェクトの結びつき（オブジェクトグラフ）はリクエストをまたいでも変わりません。

    対してRay.Aopのメソッドインターセプターはコンシュマーとメソッドの関係をダイナミックなものにします。メソッドをコールしてもそれが実際にオリジナルなメソッドをコールしたかにコンシュマーは関心を払いません。メソッド内ではDBデータを読み込んでるのに、バインドされたインターセプターはmemcacheからデータを読みその値を返し、オリジナルのメソッドはデータ更新の際の最初の１度しか呼ばれないかもしれません。関係性は外部で構成されます。

    現代的なPHPフレームワークの多くは、アプリケーションコントローラーの役割を様々な関心をアスペクトととらえそれぞれの実装がなされています。例えばフィルターチェーンであったり、シグナルスロット、イベンドディスパッチャー、イベントサブスクライバー実装パターンや呼び方が違っても問題をアスペクトとしてそれぞれの解決をしようとしているのは同じように思えます。

    Ray.AopでのAOPはコンシュマーにもサービスにもAOPフレームワークの依存がなく利用するためのサービスクラスには、イベント通知などイベントハンドリングのための仕事をする必要はありません。Ray.Diで生成されるサービスクラスはプロキシーにラップされ、該当メソッドの適用インターセプター知識をそれぞれが保持していて、イベントハンドリングがそれぞれのサービス6内で行われます。7

    現在のバージョンではRay.Aopを使ったアプリケーションコントローラー8の部分がまだ手つかずでその部分の本格的な実装はこれからです。しかしフレームワークやアプリケーションがコンシュマーとメソッドの関係をダイナミックにし外側から構成できる拡張性、関心の分離の促進によるソフトウエア品質の向上には期待をしています。9

    v0.1.0alphaリリースを機にBEAR.Resource、Ray.Di、Ray.AopとBEAR.Sundayのオブジェクトフレームワークというべきものについて記事を一つ一つかいてきました。Ray.Diはオブジェクトの生成を、Ray.Aopはそのオブジェクトのメソッドの利用にこれまでにない拡張性と機能性を与えます。そうやってできたオブジェクトにRESTという制約を被せ、オブジェクトの関係を（データではなく）DSLによって記述される関係性で結合しようとするのがBEAR.Resourceです。Ray.Diはオブジェクトグラフを、BEAR.Resourceはリソースグラフを構成しようとし、それぞれのリソースクラスは自らを構成しようとします。

    1. BEAR.SaturdayではAroundアドバイスとして実装されていものと同様のものです。
    2. これはJavaのAOPアライアンスのMethodInterceptorを元にしたもので、Google Guice, Spring, SeasorのAOPもこのAOPアラインアンスのインターフェイス群を実装しています。
    3. 前バージョンのBEAR.Saturdayでは実クラスを指定していて、アスペクトという関心の分離と適用はできたのですがそれが固定化されていました。
    4. またPDOなどのPHP標準組み込みオブジェクトもインジェクトできません。
    5. PDOと違って組み込みオブジェクトではないので@Injectでコンパイル時にインジェクトすることは可能です
    6. 詳しくはサービスを含んだプロキシー
    7. この仕組みはBEAR.Resourceでリソースそれぞれがレンダラーを持っているのと似ています。サービス（レンダラー、イベントハンドラー）にデータ（テンプレート、イベントシグナル）を渡すのではなく、オブジェクトがサービスを内包しているのです。
    8. フォームや認証、セキュリティ、ログ
    9. 一方このパターンを採用する事で発生するデメリットにも注意深く対処していかなければなりません。
    ]]>     http://www.bear-project.net/blog/2012/04/object-framework-ray-aop/feed/ 0     Object Framework – Ray.Di http://www.bear-project.net/blog/2012/04/di/ http://www.bear-project.net/blog/2012/04/di/#comments Tue, 24 Apr 2012 18:26:41 +0000 admin http://www.bear-project.net/blog/?p=1296 Read more »]]> Dependency Injection


    BEAR.Sundayではオブジェクトが必要とするインスタンスを、自ら取得しないでインジェクターに代入してもらうことを期待します。

    コンストラクタやセッターメソッド経由で外部から代入されることをインジェクション（注入）、必要とするものをディペンデンシー（依存）と呼びます。ディペンデンシーを利用するクラスはコンシュマーと呼びます。

    特に特定タスクを担当しオブジェクトがツールとして使うオブジェクトをサービスオブジェクトと呼びますが、依存はサービスオブジェクトに限りません。DB接続オブジェクトや、配列やスカラー値などの値も含みます。

    前回記事の挨拶リソースに戻りましょう。このリソースはメッセージを返す為に、$messageデータを必要としています。1

    class Greetings extends AbstractObject
    {
        $message = [
            'en' => 'Hello World',
            'ja' => 'Konichiwa Sekai',
            'es' => 'Hola Mundo'
        ];
       
        public function onGet($lang = 'en')
        {
            $greeting = $this->message[$lang];
            return $greeting;
        }

    $messageデータをクラスに固定で持たないで、外部から代入するように変更してみましょう。
    このようなセッターメソッドが必要です。

    /**
     * @Inject
     * @Name("greeting_message")
     */
    public function setMessage(array $message)
    {
        $this->message = $message;
    }

    固定されていたデータが外部から代入できるようになりました。

    ディペンデンシーをセッターメソッド経由でインジェクションしてるので、これをセッターインジェクションと呼びます。 またコンストラクターにインジェクトするのをコンストラクターインジェクションと呼びます。BEAR.SundayはRai.DiというDIフレームワークを使っていますが、サポートするインジェクションはこの２つのみです。2

    このインジェクションを行うのがディペンデンシーインジェクターです。インジェクターは決められたルールでオブジェクトのコンストラクションを行います。クラスをインスタンス化しディペンデンシーをインジェクトします。コンストラクション後に行われる初期化メソッドの呼び出しや、オブジェクト破棄の直前に呼ばれるメソッドの呼び出し予約など「オブジェクトライフサイクル」に関する設定も行います。BEAR.Sundayでは原則的に全てのオブジェクトの生成はこのディペンデンシー・インジェクターが行い、オブジェクトの中からディペンデンシーを取得することは推奨されません。

    インジェクションポイントと@Inject

    ユーザーがセッターメソッドに@Injectと注記（アノテート）することでRay.Diは『ここに依存の注入が必要だ』ということが分かります。この「外部からの代入を期待する部分」をインジェクションポイントと呼びます。

    ※注）アノテーションはDoctrine.CommonsのAnnotationを使用していて、このアノテーションを使うためのuse文が必要です。

    use Ray\Di\Di\Inject;
    use Ray\Di\Di\Named;

    インジェクションポイントに実際に何をセットするかはモジュールで設定します。モジュールではインジェクションポイントとインスタンスをバインドします。バインドの方法はいくつかありますがここでは特定の名前をつけてインジェクションポイントを指定する方法を使用していています。

    実際のモジュールのコードはこのようになります。

    class AppModule extends AbstractModule
    {
        protected function configure()
        {
            $message = [
                'en' => 'Hello World',
                'ja' => 'Konichiwa Sekai',
                'es' => 'Hola Mundo'
            ];
            $this->bind()->named('greeting_message')->toInsntance($message);
        }
    }

    インジェクターの生成とオブジェクトグラフ生成

    インジェクターを使ってこのクラスにディペンデンシーをインジェクトしてインスタンスを取得します。

    $injector = Injector::create([new AppModule]);
    $injector->getInstance('name\space\Greeting');

    モジュールにはインジェクションポイントに対してどのインスタンスを提供するかという、いわばアプリケーションの構成知識が凝縮されています。その構成知識を使ってインジェクターはオブジェクトのコンストラクション（生成、インジェクト、ライフサイクルのセット）を行いインスタンスを返します。

    インジェクションの連鎖とオブジェクトグラフ

    ディペンデンシーインジェクションは専用のライブラリを使わなくても、手動でも行う事ができます。

    たとえばUserクラスはDbクラスのインスタンスが必要でDbクラスはDB接続情報の文字列が必要だとします。これを手動のインジェクトするためには例えばこのようなコードが必要でしょう。

    $dsn = $_ENV['master_db'];
    $db = new Db($dsn);
    $user = new User($db);

    一行だとこうです

    $user = new User(new Db($_ENV['master_db']););

    このコードで明らかなのは、依存に依存があればその「依存の依存」から先に用意して順番に次の依存に渡さなければならないことです。Userクラスを生成する前に、DBオブジェクトの生成が完了してる必要があります。DBオブジェクトを生成するにはDB接続情報を取得しておく必要があります。これは通常のプログラムではごく当たり前のことです。

    ところがRay.DIはUserクラスを作る前にDbオブジェクトを予め作っておく必要はありません。オブジェクトの構成知識を知っているインジェクターは必要な依存を遡って生成、インジェクトしてオブジェクトグラフをコンストラクションします。

    例をあげます。

    Userクラスを生成するときにRay.DiはそのクラスをつくるためにはDbオブジェクトが必要だと言う事を検知します。Dbオブジェクトを生成しようとしますが、ところがその生成にはDB接続情報が必要とも検知します。インジェクターがもつ構成知識でDB接続情報は得られます。得られた情報を使ってDBオブジェクトを生成します。そうやって依存の依存を順番に辿り依存性の解決（Dependency Resolution)を行い元のインスタンスを生成します。依存がツリー構造になっているこのオブジェクトをオブジェクトグラフと呼びます。

    コンストラクションの再利用

    BEAR.Sundayではプログラムの中でいつでもインジェクターを使い必要なインスタンスをオンデマンドで生成できますが、実際にはほとんどその出番はありません。boot時のルートオブジェクトグラフ（ページリソースやリソースクライアント）が生成される時に必要なオブジェクト、またはファクトリーの生成が全て完了するからです。3

    前バージョンBEAR.Saturday (2008年）ではアプリケーションスクリプトからnew演算子を取り除くことが一つの目標でしたが、BEAR.Sundayではフレームワークサイドでもnewの利用はほとんどありあません。オブジェクトはコンストラクションされるとAPCのストレージに格納され、リクエストをまたいで再利用されます。

    つまり現在のBEAR.Sundayではリクエスト毎に異なった処理をコンストラクタで記述することはできません。この制約はメリットとデメリットがあります。オブジェクトシリアライズ前提のためシリアライズできないクロージャや組み込みオブジェクトをコンストラクション時にプロパティにセットできません。一方、固定化されたオブジェクトグラフとより安定したフロー、強力で容易なキャッシュ機構、アノテーションやDI、AOP等を採用しながらも維持している強力なパフォーマンス等は大きなメリットです。

    再利用はオブジェクトグラフの膨大な取得コスト4 を最小限にします。30,000を超えるindexページのファンクションコールは500以下になり、実行速度は数十倍になっています。

    オブジェクトのコンストラクタは基本的にサービス開始の最初の１リクエストしか通りません。その特徴をv0.1.0alphaインストールの時に用意されるindexページでみてます。

    indexページ画面
    indexページリソーススクリプト
    class Index extends Page
    {
        use ResourceInject;

        public function __construct()
        {
            $this['greeting'] ='Hello, BEAR.Sunday.';
            $this['version'] = [
                'php'  => phpversion(),
                'BEAR' => Framework::VERSION
            ];
            $this['extentions'] = [
                'apc'  => extension_loaded('apc') ? phpversion('apc') : 'n/a',
                'memcache'  => extension_loaded('memcache') ? phpversion('memcache') : 'n/a',
                'mysqlnd'  => extension_loaded('mysqlnd') ? phpversion('mysqlnd') : 'n/a',
                'pdo_sqlite'  => extension_loaded('pdo_sqlite') ? phpversion('pdo_sqlite') : 'n/a',
                'Xdebug'  => extension_loaded('Xdebug') ? phpversion('Xdebug') : 'n/a',
                'xhprof' => extension_loaded('xhprof') ? phpversion('xhprof') : 'n/a'
            ];
        }

        /**
         * Get
         */
        public function onGet()
        {
            $cache = apc_cache_info('user');
            $this['apc'] = [
               'total' => $cache['num_entries'],
               'size' => $cache['mem_size']
            ];
            // page / sec
            $this['performance'] = $this->resource->get->uri('app://self/performance')->request();
            return $this;
        }
    }

    コンストラクタではPHPのバージョンやフレームワークのバージョンやエクステンションの情報を自身のコンテンツとしてセットしています。これらの情報はリクエスト毎に変わる事のないスタティックなものです。

    このコンストラクタはサービス開始時に1度しかリクエストされず、バージョンやエクステンションの情報が入ったコンテンツは再利用されます。5

    一方、GETリクエストに対応するメソッドではリクエスト毎にコールされるので、変化するパフォーマンスやAPC情報はリクエスト毎にセットされます。

    スタティックなリソースコンテンツとダイナミックなリソースコンテンツは分離され適した動作をしています。

    トレイト・インジェクション

    違うクラスでも求める依存が同じなら、同じセッターが利用できます。セッターメソッドはクラスをまたいで横断的に再利用できます。モジュールに新たな設定はありません。
    メソッドの横断的利用、PHP5.4の新機能のtraitにすると便利で表記も簡潔になります。

    use Ray\Di\Di\Inject;
    use Ray\Di\Di\Named;

    trait MessageInject
    {
        private $message;

        /**
         * @Inject
         * @Name("greeting_message")
         */
        public function setMessage(array $message)
        {
            $this->message = $message;
        }
    }

    アノテーションのuse文も入っているので、利用クラスでは簡単にインジェクションが表記できます。まとめるとこうなります。

    class Greetings extends AbstractObject
    {
        use MessageInject;
       
        public function onGet($lang = 'en')
        {
            $greeting = $this->message[$lang];
            return $greeting;
        }
    }

    プロバイダー6

    Day.DiによるDIは次の２つのパートで成り立っています。

    • モジュールでのオブジェクトコンストラクション（Construction）
    • コンシュマーでの利用（Execution）

    コンストラクションはモジュールで完了させ、コンシュマーでは利用だけを行います。

    肝心なのはコンストラクションとエクスキューションを完全に分離して、混ぜないことです。コンシュマーにディペンシーインジェクターやサービスコンテナを渡したりする事は推奨されません。78

    コンシュマー内で新しいインスタンスが都度欲しい時はプロバイダーを使います。プロバイダーは最小のファクトリーで、引き数なしのget()というメソッドだけを持ちます。たとえばテンポラリーファイルのハンドルが都度、複数欲しいなら(Provider)$tmpFilePorviderをインジェクトしてもらって、このように使います。

            $tmpFile1 = $this->tmpFileProvider->get();
            $tmpFile2 = $this->tmpFileProvider->get();

    プロバイダーはどのようにインスタンスを作るかという知識を全て持っています。引き数は渡す事ができず、最小化されたこのファクトリーに伝える事ができるのは生成のタイミングだけです。

    なお、newは絶対に使っていけないというわけではありません。ごく小さなオブジェクトやPHPの組み込みオブジェクトなどは問題ないでしょう。

    Conclusion

    この記事では、BEAR.Sundayアプリケーションの役割と働きをみてきました。Ray.DiはGoogle Guiceのクローンです。9 全ての機能が移植されてるわけではありませんが、ここで紹介した機能以外にも沢山の機能があります。Doctrine.Commons.Annotationライブラリを使い、AuraというPHP5.4フレームワークのAura.Diライブラリを拡張して作成しています。またRay.Diインジェクター自身の依存も手動でインジェクトされ拡張可能です。

    Ray.Di – Guice style annotation-driven dependency injection framework for PHP

    インジェクションポイントとディペンデンシーのバイディングはモジュールで設定し、インジェクターはどのオプジェクとが求められればどのインスタンスを渡すかという知識を持っています。モジュールはクラスをどのようにコンストラクトするかではなく求められた依存に対してどのインスタンスを渡すかという設定が行われています。そのため同じ依存を要求する違うクラスに新たな設定は必要なく、セッターメソッドのtraitを使ってより簡素な記述でディペンデンシーが取得できます。

    Ray.Diの特徴はオブジェクトの生成と利用が完全に分離されていること10、モジュールでのDSLによるバインディング、APCを使ったオブジェクトグラフコンストラクションの再利用等です。11

    Ray.Diは可変点の明確化と最小化というBEAR.Sundayのアーキテクチャ全体を通しての原則を支持します。

    またRay.Diはモジュールで特定メソッドの実行にインターセプターをバインドすることが可能で、アスペクト指向プログラミングが利用できます。BEAR.Sundayではフレームワークやアプリケーションの動作や役割を様々なアスペクトの集合だと考えています。次回の記事ではAOPをサポートすRay.AopのBEAR.Sundayでの役割、アスペクト指向デザイン(AOD)により実装されたアプリケーション機能を紹介します。

    1. つまりこのリソースは$messageデータに依存しています
    2. プロパティにインジェクトするプロパティインジェクションはサポートされません。
    3. 現在のBEAR.Sundayで登場する独立したオブジェクトはアプリケーションはappリソースを除くと基本的には３つしかありません。アプリケーションとリソースクライアントとページリソースです。その他のオブジェクトをそれらの「ルートオブジェクト」を構成するプロパティでしかない場合がほとんどです。
    4. アノテーションが必要とするコメント文のパースだけでなくアノテーションの名前解決のためのPHPスクリプトのパースも行われてます
    5. 例えばYAMLファイルのCSVファイルのパースなどをコンストラクタで行いコンテンツとしてセットすると再利用されるので個別にキャッシュしたりする必要がありません。
    6. このセクションはstackoverflowの記事を元にしています。http://stackoverflow.com/questions/2504798/dependency-injection-in-constructors
    7. コンシュマーがインジェクターを使ってサービスを取得することは、デメテルの法則（最小知識の法則）に違反します。
    8. 例外はそのコンシュマーがファクトリークラスの場合です。BEAR.Sundayで唯一インジェクターを依存として受け取りオブジェクトコンストラクションをしてるのはリソースのnewInstance()メソッドです。
    9. Guiceが使われているGoogleの代表的なプロダクトにAdSenseがあります
    10. 利用クラスでサービスコンテナへの依存がない
    11. コンストラクションは常にキャッシュされ、再利用されることを考慮したコーディングが必要です。
    ]]>     http://www.bear-project.net/blog/2012/04/di/feed/ 0     BEAR.Resource http://www.bear-project.net/blog/2012/04/bear-resource/ http://www.bear-project.net/blog/2012/04/bear-resource/#comments Tue, 24 Apr 2012 17:03:59 +0000 admin http://www.bear-project.net/blog/?p=1178 Read more »]]> BEAR.SundayはDI、AOP、REST、この３つの技術をコアにしたオブジェクトフレームワークをベースにしています。

    このオブジェクトフレームワークがある程度完成したのを機に、今回v0.1.0alphaとして一旦まとめました。1 まだ実用レベルではなくこれからこのオブジェクトフレームワークの上に、APIフレームワーク、webアプリケーションフレームワークと、フレームワークのレイヤーを重ねていく予定です。

    この記事では現在のv0.1.0alpha実装からBEAR.Sundayの特徴を紹介します。

    リソースオブジェクト

    BEAR.Sudayで中心になるのがリソースオブジェクトです。MVCで言うとモデルに近いものですがwebからアクセスされる最初のリソースレイヤーのpageリソースはコントローラーのように振る舞います。

    それぞれのリソースはURIで表すことができ、スキーマに応じて処理の仕組みが変わります。最も標準的なものはリソースURIとPHPクラスがマップされるリソースオブジェクトです。HTTPのリクエストメソッドに準じたインターフェイスメソッドを持ち、リクエスト処理を記述します。役割に応じてpageリソースやappリソースとスキーマや呼び方は代わりますが基本的な仕組みは同じです。

    ウエブページのようなオブジェクトと思ってみてください。

    例えばGETリクエストすればリクエスト用のメソッドがコールされ、結果でもあるリソースオブジェクト自身が帰ってきます。

    まずはHello Worldページです。

    class Hello extends Page
    {
        public function onGet($name)
        {
            $this->body = 'Hello ' . $name;
            return $this;
        }
    }

    $nameを受け取り連結して返すだけのページです。bodyプロパティに代入して自身を返してる事に注目してください。

    このページクラスは以下のように表記しても同じです。2文字列を返しても、クライアントにはbodyプロパティがセットされたオブジェクトが返ります。

    class Hello extends Page
    {
        public function onGet($name)
        {
            return 'Hello ' . $name;
        }
    }

    ４つの公開されたプロパティ

    リソースクラスは以下の４つのpublicプロパティを持ちます。

  • リソースコード
  • リソースメタ情報（ヘッダー）
  • リソースコンテンツ（リソース状態）
  • リソース表現

    • コードはHTTPステータスコードに準じたリソースの状態がはいっています。リソースの本質的な値はリソースコンテンツに入っていますが、クライアントが利用するリソース表現は別のプロパティが用意されています。

    このHelloページリソースではリソーススコンテンツ$bodyプロパティをセットしてクライアントに返しています。

    レイヤード・リソース


    pageリソースはwebクライアウントから最初にコールされるリソースレイヤーです。多くの場合、（更に関心を細分化した）appリソースをページからリクエストします。コントローラーがモデルをリクエストするようなもので、pageリソースはpageコントローラー、appリソースは内部APIとして振る舞うモデルとして機能します。

    最初の例の単純な例のpageリソースはコントローラーとして機能するよりも、リソースコンテンツを変更することで自身を構成しています。自身がレスポンスオブジェクトのようですがこれは不作法なことではありません。リソースは関心に応じてレイヤリングしますが、単純なHelloページではそのページだけで完結する場合もあるでしょう。一方、appリソースでも必要があれば関心にレイヤリングを適用して、適切なネストのレイヤーを持つのが良いでしょう。

    最初にwebブラウザのリクエストURIに応じてルートされたpageリソースがリクエストされます。pageリソースはappリソースやその他のリソースをリクエストしますが、他のpageリソースもリクエストすることができます。階層構造MVCのように振る舞います。

    アプリケーション(app)リソース

    アプリケーションリソースはいわば内部APIです。MVCでの主役がMであるように、BEAR.Sundayでもアプリケーション価値の多くはこのappリソースにあります。3

    appリソースの簡単な例をコードで紹介します。$lang(言語)を引数で渡すと挨拶文字列を返す 「挨拶リソース」です。

    class Greetings extends AbstractObject
    {
        private $message = [
            'en' => 'Hello World',
            'ja' => 'Konichiwa Sekai',
            'es' => 'Hola Mundo'
        ];
       
        public function onGet($lang = 'en')
        {
            $greeting = $this->message[$lang];
            return $greeting;
        }

    これはpageリソースで説明したように、以下のコードと同じものです。

    public function onGet($lang = 'en')
    {
        $this->body = $this->message[$lang];
        return $this;
    }

    挨拶のデータは$messageプロパティに格納されていて、引数$lang（言語）によって指定されたメッセージを返します。このリソースクラスはonGetメソッドがあり、GETリクエストだけを行う事ができます。

    リソースクライアントからはのリクエストはこのようにして作る事ができます。withQuery()メソッドで与えてるのは順番による引数ではなくて、変数名を指定した名前付き引数（named parameter)であることに注意してください。引数の順番は関係ありません。

    リソースリクエスト

    リソースリクエストは以下のように記述します。

    $request = $resource
               ->get
               ->uri('app://self/greeting')
               ->withQuery(['lang'] => 'ja')
               ->request();

    この文で作られたのはリクエストです。このリクエストを実際に行うにはこのリクエストオブジェクトをクロージャのように扱います。

    $result = $request();

    リクエストは再利用することができます。引数を指定して指定した名前付き引数に追加、上書きすることができます。

    $result = $request(['lang' => 'en]);

    イーガーリクエスト

    リクエストの結果をすぐに求めるにはリクエストに eagerをつけます。

    $result = $resource
              ->get
              ->uri('app://self/greeting')
              ->withQuery(['lang'] => 'ja')
              ->eager
              ->request();

    この文ではすぐにリクエストが行われます。

    リソースのレンダリング

    リクエストにより求められたリソースオブジェクトはプロパティにリソースの状態を持っています。プロパティを直接使う事もできますが、それよりオブジェクトとして利用するのがスマートです。オブジェクトはコンテキストに応じて評価されます。

    連想配列として扱うとリソースコンテンツのエレメントが取り出せます。例えばユーザーリソースのID等です。

    echo $result['id']; // $result->body['id'] と同じ

    オブジェクトなのでメソッドを利用することはもちろんできます。

    echo $result->log();

    文字列として扱うと、そのリソースはコンテンツを表現に変えようとします。

    BEAR.Sundayではリソースからデータを受け取ってテンプレートエンジンに渡すのではなく、リソースがテンプレートエンジンを保持し（データを外部に公開することなく）自身がレンダリングを行います。

    図をご覧下さい。

    存在するリソースの１つ１つのオブジェクトがレンダラー（Viewオブジェクト）を保持します。4　

    例えばユーザーリソースのコンテンツは以下のようなものだとします。

    $user->body = ['name' => 'koriym', 'gender' => 'male']

    このJSON表現はこうなります。

    {"name":"koriym","gender":"male"}

    このレンダリングはjson_encode()関数を使うだけの単純なものでしょう。

    また、HTML表現は例えば以下のようなものになります。リソース専用のテンプレートを用意してレンダリングしています。

    <span id="user">ユーザー名:koriym 性別:male </span>

    リソースは自身の構成やコンテンツに関して関心を持ちますが、表現には直接関心をもたず、セットされたリソースレンダラーに自身（$this)を渡してレンダリングを命じます。

    レンダリングはリソースオブジェクトが文字列として評価されたときに行われます。

    echo $user;
    // または
    $userHtml = (string)$user;

    レンダラーの保持はオプションです。もしリソースがレンダラーを持たなくても、コンテンツが文字列として評価可能ならコンテンツを表現にします。リソースコンテンツが文字列表現ができないフォーマット（例えばarray型）で、レンダラーも持たないときに文字列として評価されれば文字列”を返します。

    リソースリクエストのレンダリング

    リソースリクエストが文字列として扱われたときには、リクエストを行い、その結果をレンダリングした結果の文字列が得られます。

    echo $request;
    // または
    $userHtml = (string)$request;

    レイジーリクエストとレイジーレンダリング

    リソースクライアントが生成したリクエストオブジェクトは文字列として評価されるときに初めてリクエストを行います。

    v0.1.0alphaでインストールされるindexデモ画面。これにapp://self/performanceというフレームワーク実行パフォーマンスを測定するappリソースがありindexページではpageのGETリクエストに応じてセットしています。

    $this['performance'] = $this
                           ->resource
                           ->get
                           ->uri('app://self/performance')
                           ->request();

    page / secで表示されている値がそうです。

    これはeagerが使われていないので、bodyのperformanceにapp://self/performanceへのGETリクエストがセットされたことになります。このリソースが実際に行われるのはコンパイル済みのテンプレートでこのリソースが出現するタイミングです。

    smartyのコンパイル済みテンプレートではこの部分です。

    <p>&copy; 2012 <a href="https://twitter.com/#!/bearsunday">@BEARSunday</a> (<?php echo $_smarty_tpl->tpl_vars['performance']->value;?>
    </p>

    ここで初めてリクエストが行われます。パフォーマンスを測定するという目的からすればよページクラスのメソッドで計測するより、テンプレートで表示される直前に計測される値の方がより正確でしょう。またこのパフォーマンスリソースはテンプレートで出現しなければ計測されることもありません。実際に利用されるかされないかを気にしないでページはテンプレートにリクエストをセットすることができます。

    リソースキャッシュ

    パフォーマンスappリソースを使ったページリソースをキャッシュしても、パフォーマンスリソースの値は正しく反映されることに注目してみてください。これはページが保持してるのはリソースリクエストの結果ではなく、リソースリクエストの方法だからです。リクエスト方法はキャッシュされ再利用されても、その値は毎回変わります。

    リソースまとめ

    • リソースリクエストはリクエストの生成と実行というライフスタイルを持ちます。
    • リソースはURIから生成され、リソースリクエストを実行するアダプターはURIのスキーマで決まります。
    • リソースリクエストはURI文字列で表現されます。
    • リソースリクエストの引き数はネームドパラメーターで渡されます
    • 作成されたリソースリクエストはクロージャのように扱えます
    • リソースはレンダラーを個別に保持し自身をリソース状態からリソース表現にレンダリングすることができます。
    • リソース表現は文字列評価することで得られます。
    • レンダラーの使用はオプションです。なければコンテンツが表現にならないか検討します。
    • レンダラーはユーザーが記述することができます。
    • レンダラーはテンプレートエンジンを持ちます。設計上固定化されたものはありませんが、現在のデモではSmarty3が使われています。

    他にもサービスを通じて一度しか行われないオブジェクトコンストラクション、不足している引き数を補充するパラメータープロバイダー、スキーマアダプターを構成するDSL、リソースの関係性を内部で持つリソースリンク、webブラウザでタブを開くようにリンク先を加えていくnewリンク、リソースリンクをクローリングしてリソースのリンク構造を構成するクローラーリンク、リソースリンクを露出することなくアプリケーション状態を変更するHATEOUS（Hypermedia as the Engine of Application State）等様々な機能がありますがまた別の機会に紹介したいと思います。5

    次回はRay.Di

    次回の記事はDIです。BEAR.SundayはRay.Diというディペンデンシーインジェクターを用いてオブジェクトのコンストラションおよびインジェクションを行います。Ray.DiはBEAR.Sundayのために開発したGoogle GuiceクローンのDIフレームワークです。アノテーションを用いつつサービスコンテナにも依存しないよりクリーンなDIが可能です。

    1. HelloWorldしか出ない状態が長く続いたのにも関わらずソースをみたり関心を持ってもらった方がおられました。ありがとうございます
    2. シンタックスシュガー
    3. 一方、pageリソースの役割はリクエストURIに応じて複数のappリソースをアクセスする事がほとんどです。
    4. アプリケーションスコープでシングルトン
    5. きっともうお腹一杯でしょう！
    ]]>     http://www.bear-project.net/blog/2012/04/bear-resource/feed/ 0     PHPでアノテーション http://www.bear-project.net/blog/2012/02/php%e3%81%a7%e3%82%a2%e3%83%8e%e3%83%86%e3%83%bc%e3%82%b7%e3%83%a7%e3%83%b3/ http://www.bear-project.net/blog/2012/02/php%e3%81%a7%e3%82%a2%e3%83%8e%e3%83%86%e3%83%bc%e3%82%b7%e3%83%a7%e3%83%b3/#comments Fri, 17 Feb 2012 16:14:17 +0000 admin http://www.bear-project.net/blog/?p=1148 Read more »]]> アノテーションとは

    プログラミングでは、コード中に登場する要素(クラス、メソッドなど)に対して、それ自体に関する情報(メタデータ)を注記できる仕組みのことをアノテーションという。「このメソッドはテスト用である」「ここでコンパイラは警告を出してはならない」「このメソッドはオーバーライドである」などの情報を付記し、コンパイル時や実行時に参照させることができる。

    IT用語辞典

    このように説明されるアノテーションですが、その源流を調べてると次の文章に出会いました。

    アノテーションとは、JDK 1.5で新たに追加される言語仕様であり、Javaコード上でメタデータ（コードそのものではなくコードに関する付加情報）を記述可能にする。これは、マイクロソフトC#における属性（attribute）に相当するシンタックスで、アノテーションはそれを後追いした仕様といえる。

    2004年の@ITnoの記事です。

    つまりJavaのアノテーションはC#のアトリビュートに強く影響を受けたものみたいです。
    そのことについてC#の作者、アンダース・ヘルスバーグ氏のインタビューが@ITのC#への期待。アンダースからの返答という記事の中で見つかりました。

    ■Java言語の進化（例：Annotationなど）についてどのように考えているか？

    アノテーション（Annotation）に関しては、.NETの属性（Attribute）のJavaバージョンといえると思うが、このように.NETで実装してきていることを、やはりJavaでも行ってきているという印象だ。実際にJavaの最新バージョン5.0に搭載された新機能の中で、（先ほどのアノテーションも含めて）.NETに触発されて導入されたと思われるものがいくつもある。

    その.Netの属性ページではこのように説明されています。

    属性は、プログラムにメタデータを追加します。 メタデータは、プログラム内で定義されている型に関する情報です。 すべての .NET アセンブリに、指定した一連のメタデータが含まれ、そこにはそのアセンブリ内で定義されている型および型のメンバーが記述されています。 カスタム属性を追加すると、必要な任意の追加情報を指定できます。

    アセンブリ全体、モジュール全体、クラスやプロパティなどの小さいプログラム要素に、1 つ以上の属性を適用できます。

    属性は、メソッドやプロパティの場合と同じ方法で引数を受け取ることができます。

    プログラムは、リフレクションを使用することにより、そのプログラム専用のメタデータや他のプログラム内のメタデータを調べることができます。

    Javaの注釈ではこのように説明されています。

    注釈はプログラムのセマンティクスに直接影響しませんが、ツールやライブラリがプログラムを扱う方法に影響します。そのため、実行中のプログラムのセマンティクスに影響する場合があります。注釈はソースファイル、クラスファイル、または実行時にリフレクションとして読み取ることができます。

    PHPでのアノテーション

    PHPはアノテーションはネイティブサポートさていませんが、”Status: Under Discussion”のアノテーション提案があります。

    ※Class Metadataという前の提案は否決されたようです

    アノテーションの定義

    class ReflectionAnnotation
    {
        private $value;
     
        public function __construct(\stdClass $value)
        {
            $this->value = $value;
        }
     
        public function getValue()
        {
            return $this->value;
        }
    }

    アノテーションの表記

    /**
     * Foo class.
     *
     * @Entity {"repositoryClass": "FooRepository"}
     * @Table  {"name": "foos"}
     *
     * @author "Guilherme Blanco"
     */
    class Foo
    {
      // ...
    }

    アノテーションの利用

    $reflClass = new \ReflectionClass('Foo');
    var_dump($reflClass->getAnnotations());

    PHPの言語としてのサポートにが無いのにも関わらず、現在多くのライブラリ・フレームワークでアノテーションがサポートされています。なぜアノテーションを必要と考えるのでしょうか？提案者はこのように説明しています。

    Why do we need Class Metadata?

    Frameworks in general rely on metadata information in order to correctly work. They can use it for many purposes:

    • phpUnit Providing meta functionality for test cases, examples: @dataProvider for test data iteration, @expectedException for catching exceptions, etc.
    • Doctrine For Object-Relational mapping, examples: @Entity, @OneToOne, @Id, etc.
    • Zend Framework Server classes Used to automate mappings for XML-RPC, SOAP, etc.
    • FLOW3 for dependency injection and validation
    • Symfony2 for routing rules
    • Others One clear thing that comes to my mind is Validation, Functional Behavior injection (which could take advantage of Traits), etc. Also, any Framework could take advantage of it somehow.

    So, any meta mapping injection could be easily achieved via the implementation of a centralized Annotations support.

    The .NET framework uses Data Annotation: http://www.asp.net/mvc/tutorials/validation-with-the-data-annotation-validators-cs

    An advantage here is the .net framework will process some annotations and inject behavior into the compiled source code.

    It’s important to note that annotations exist in java and .net but many strong use cases exist in these languages to provide hints to the compiler (@NotNull).

    他に自分が知ってる範囲では、Java Beanの影響を強く受けたDIngやRESTful PHP frameworkのRecess やZend Framwork2のDiでもアノテーションが使われています。

    ネイティブサポートがないという事はPHPでDocCommentの部分1 をPHPでパースしなくてはならなく、速度的にも不利なところがあるのですが、このようにPHPでもフレームワーク・ライブラリを中心に使われるようになってきているようです。デ・ファクトと言えるようなライブラリがないのか、各ライブラリが独自でパースしてるものが多く、GuiceクローンのアノテーションベースのDIコンテナ Ray.Di を実装したときも最初はそうしていました。

    Doctrine\Commons\Annotations

    ORMで有名なDoctrineですが、ORMの他にもプロジェクトがいくつか登録されていてライブラリとしてdoctrine ORM使用しているものを単体使用できるようになっています。2

    Docotrine Commonsというライブラリがあります。

    Common

    The Doctrine Common project is a library that provides extensions to core PHP functionality.

    “PHPの機能を拡張するライブラリです”という説明で、Doctrineが使っているAutoloaderやCacheもあるのですが、注目はDoctrine Annotations3 です。

    RFC提案されてるようにアノテーションを扱います。

    アノテーションの定義

    @Annotation、@Targetは Doctrineが使用するアノテーションのアノテーションです。
    このアノテーションはクラスとメソッドにアノテートすることができます。

    /**
     * Inject
     *
     * @Annotation
     * @Target("CLASS")
     * @Target("METHOD")
     *
     * @package    Ray.Di
     * @subpackage Annotation
     */
    final class Inject implements Annotation
    {
    }

    setDbメソッドを@Injectとアノテートしました。

        /**
         * @Inject
         *
         * @param DbInterface $db
         */
        public function setDb(DbInterface $db)
        {
            $this->db = $db;
        }

    アノテーションの利用

    $reflMethod = new ReflectionMethod('MyCompany\Entity\User', 'setDb');
    $methodAnnotations = $reader->getMethodAnnotations($reflMethod);

    これで全てのアノテーションが取得できます。
    あるいは以下のようにして特定アノテーションの値が取得できます。

    $methodAnnotation = $reader->getMethodAnnotation($reflMethod, $annotation);

    Doctrine\Common\Annotations\AnnotationReader が標準的なアノテーションリーダーです。 (Symfony2では標準でサービスコンテナに登録されてるようです)。
    他にはそのAnnotationReaderを利用するCachedReader、use文による名前解決を行わない、より簡素な SimpleAnnotationReaderがあります。

    またReaderを使わずパースライブラリとして使いたいなら、doc内のアノテーションを行うDoctrine\Common\Annotations\DocParser や PHPスクリプトを解析してのuse文の名前解決を行う Doctrine\Common\Annotations\PhpParser も有用だと思います。use文の名前解決については Symfony2のブログ Symfony2: アノテーションが改善されましたも参考になると思います。4

    ※他にはaddendum , php-annotationsというライブラリもあります。

    Conclusion

    PHPではアノテーションのネイティブサポートはなく、以前は使用はあまり一般的ではありませんでした。しかしPHPUnitでもすっかりおなじみのようにメタプログラミングを実現するためのツールとしてPHP界でも認知されつつあります。自作のライブラリやアプリケーションでも Doctrine Annoattion を用いれば利用の敷居は下がります。速度的な懸念も CachedReaderを使用したり、Configrationに用いたりすることで問題にならない場合も多いでしょう。

    ではどのように使うのが良いのでしょうか？広く使われてる割にはなかなかベストプラクティス系の記事が見つかりませんが、１つ見つけました。興味ある方は一読すれば参考になると思います。

    Annotations Gotchas and Best Practices

    Ray.DiでもこのDoctrine Annotationを採用しリファクタリングを行いました。

    1. リフレクションで取得できます
    2. (Zend Frameworkのように）このようにライブラリ・ファーストとして部分をライブラリとして単体使用できるのが、最新フレームワークの特徴だと思います
    3. このドキュメントは2.1のものです
    4. Fabienさんの記事で、@masakielasticさん翻訳の記事です
    ]]>     http://www.bear-project.net/blog/2012/02/php%e3%81%a7%e3%82%a2%e3%83%8e%e3%83%86%e3%83%bc%e3%82%b7%e3%83%a7%e3%83%b3/feed/ 0     BEAR.Sunday Note http://www.bear-project.net/blog/2011/12/bear-sunday-note/ http://www.bear-project.net/blog/2011/12/bear-sunday-note/#comments Wed, 21 Dec 2011 15:50:40 +0000 admin http://www.bear-project.net/blog/?p=1121 Read more »]]> BEAR.Sunday NoteというBEAR.Sundayのスライドを用意しました。
    アーキテクチャやアイデアを図や付箋紙でノートのように書いてアップデートしていこうと思います。

    BEAR.Sunday Note

    体系的でちゃんととしたものではありませんがが、”アジャイルメモ”のように使って行く事で、
    アイデアや設計がより整理されるかもと考えました。

    ]]>     http://www.bear-project.net/blog/2011/12/bear-sunday-note/feed/ 0     PHP: Dis Is It. http://www.bear-project.net/blog/2011/12/php-dis-is-it/ http://www.bear-project.net/blog/2011/12/php-dis-is-it/#comments Sun, 18 Dec 2011 14:40:56 +0000 admin http://www.bear-project.net/blog/?p=1084 Read more »]]> 昨日2011.12.17にPHP Apocalypse というイベントで”PHP: Dis Is It”と題した発表をしました。
    PHP Disを、そのDisそのものよりDisのありようやDis周辺つまり”Meta Dis”視点で考察を行い、PHPという言語のネイチャーを探ろうとしました。

    PHP: Dis Is It

    PHPに未来を感じる方いますか？

    「PHPに未来を感じる方いますか？」こういう質問をされた発表者の方がいました。僕は勢いよく…と言わないまでも挙手したのですが、周囲を見渡してみると自分一人のようでした。その方の発表では「恐らくPHPは緩やかな下降線を辿っていくと、現在ターミナル医療のような状態だ」というような趣旨の発言で、TL見る限りはそれに同意する方も少なくないようでした。1　

    Inconsistency

    inconsistency（一貫性の欠如）という誰もが認めるPHPの欠点をキーワードにその原因を”混血”にあるという仮説を立てます。そしてそのInconsistencyを「PHP Disそのもの」にも適用し、本当に言語として駄目設計なら、そのPHP批判にもConsistencyがあるはずなのでは？2 そこにConsistencyが無ければどういう理由なのだろうと考察します。

    X Sucks

    ソフトウエアバッシングというのはPHPだけではありません。時代を通じでずっと存在し、あらゆる言語にあり、OSにあり、UNIXにもあります。UNIXはいわば”Mother of Software” 過去から今日にいたってあらゆるソフトウエアのファンデーションなのではないか？それを「時代遅れの異臭のするOS」という批判、歴史的で最大の、しかもUNIX制作者によるUNIX批判を紹介しました。そしてその批判の挫折、失敗の考察を紹介し、ではPHPはどうなのかと繋げます。

    最良の者が生き残るのではない

    最も強いものが生き残るのではなく、最も賢いものが生き延びるわけでもない。
    唯一、生き残るのは変化できるものだけである。

    ダーウィンの名著「種の起源」での一節です。PHPは強いアイデンティティを持ちません。3 過去現在に渡って躊躇なく変化してきました。そしてその変化の度に少なからず批判を受けてきたように思います。4　

    しかし、その変化し続けるという姿勢が、その変化そのものより重要なのであり、5 自分はそこに未来を見る。これが僕の「 This Is It」です。このように「Dis Is It」で始まったプレゼンテーションを「This Is It」で結びました。

    Outlook is Gold.

    伝えたかった事はもう一つあります。

    物事には常に多面性があって自分たちが見ているのは、常にコインのどちらか片方でしかない。

    物事を深く広く知れば知るほど、この単純な真実に敬意を示し、反対の立場や考えの異なる人に対する物言いに慎重さや思慮深さが出てくる..ところが現実はそれとは全く反対の方は少なくありません。

    「環境に適用しようと変化し続けるものには未来がある可能性が高い」コンピュータ言語の生存をダーウィニズムになぞらえたこの自分の主張も、その多面性のある対象の一考察でしかありません。高名な専門家の、驚くほど一面的でチープな批判を目にした時「これも何かその理由があるんだろう、専門性が視野狭窄に繋がってるのか」そうやって常にその考察背景とアウトルックを問いかけ続ける事ができ、「コインの片側だけで語ってないか？」と疑問を持ち続ける事ができる限り、自分の”self-desciprineランプ”はグリーンに点灯できてるんじゃないかと思います。エンジニアとして、あるいは問題解決の多面性に対峙する仕事人として、もう少し長く生存できるんじゃないかと考えてます。

    「アウトルック にこそ価値がある」…これがもう一つ伝えたかった事です。 67

    自分でタイトルを決めてpublicな場で発表するのはこれが初めてでした。聞いて下さった方、主催関係者の方々、みなさんありがとうございました。

    1. つまり自分は少数派だったのですが、同時にだからこそ発表の価値もあるのではと思いました。
    2. 名前空間やクロージャなど誰もが指摘してた欠陥が少なくなってきた現在のPHPなら尚更です
    3. カリスマによる強いグランドデザインがありません
    4. 「だから、PHPにXXXなんか要らないんだって」XXXに色々な言葉がはいってきたように思えます。
    5. マクルーハンの「メディアはメッセージである」とおなじように
    6. 物事の視点、見解
    7. http://lists.sugarlabs.org/archive/iaep/2009-July/006940.html
    ]]>     http://www.bear-project.net/blog/2011/12/php-dis-is-it/feed/ 1     BEAR.Sunday Prototype Preview http://www.bear-project.net/blog/2011/12/bear-sunday-prototype/ http://www.bear-project.net/blog/2011/12/bear-sunday-prototype/#comments Mon, 12 Dec 2011 18:30:20 +0000 admin http://www.bear-project.net/blog/?p=978 Read more »]]> BEAR.Sunday Framework dev2

    先日、BEAR.Sundayの紹介をSymfony勉強会で行いました。トヨタ車の愛好クラブに出向いてマツダ車の魅力を語るようなもので、またSymfony2というPHPのフレームワークの中でも最も成熟したフレームワークを愛好してる方々にHello Worldしか出力できないつくりかけのフレームワークを語るという事でもあり、大変恐縮したのですが成り行きでそういう事になりました。最初は汎用技術だけを話していたのですがこれは面白いかもと思うBEARの一部分も紹介し、一部の方に大変な興味を持ってもらい熱心に聞いていただきました。こちらも刺激とインスピレーションをいただき、整理にもなりました。ここに感謝を持ってそのHello Worldアプリの紹介をしたいと思います。

    https://github.com/koriym/BEAR.Sunday
    https://github.com/koriym/BEAR.Sunday/tree/dev2/apps/00-helloworld-min

    (このプロトタイプ作成の目的は全体構成を確認、評価することと、オブジェクトグラフのキャッシュの可否、メソッドインターセプトを利用したリソースオブジェクトのAOP実装、ラフなパフォーマンス評価、ビューとページの構成評価などです。詳しくはGitHubにあります。)

    Hello World

    BEAR.Sundayでは、MVCフレームワークのC=コントローラーにあたる部分をPageリソースが担当します。
    最小構成に近いページはこのようになります。

    class Hello extends Page
    {
        public $code = 200;

        public function __construct()
        {
        }

        public function onGet($name)
        {
            $this->body = 'Hello ' . $name;
            return $this;
        }
    }

    ページリソースはページコントローラーの役割を持ちます。HTTPをモデルにした、code, headers, bodyの公開されたpublicプロパティを持ちますが、継承元はメソッドを持ちません。またビューオブジェクトも持ちません。代わりにリクエストメソッドに応じたインターフェイスメソッドがあります。ページのGETリクエストに対してonGet()が対応します。

    ページの仕事（関心）はテンプレートに何かをセットする事ではなく、自らを構成する事です。最も大事なのはページの状態(code プロパティ）です。デフォルトは200=OKです。それ以外の場合、例えばこのページリソースは$nameを受け取らないとページが構成できないとします。その場合「リクエストに不正がある」400(=Bad Request)をセットします。

        public function onGet($name)
        {
            if (is_null($name)) {
                $this->code = 400;
                return $this;
            }
        }

    たったことだけの事で400 Bad Requestは大げさでしょうか？それはアプリケーションのビューが決めます。表現と構成は別の関心です。例えばそれは「名前を入力して下さい」という画面かもしれませんし、AJAXアクセスに対して400 Bad RequestというHTTPコードと何が足りないかを示すJSONかもしれません。ページはどう表現されるかは関心を持たずに、自らの状態を構成する事だけに専念します。

    ステータスコード

    基本的には以下のようなHTTPステータスコードに準じたもので決定します。1

                // 103-199   Unassigned
                '200' => 'OK',
                '201' => 'Created',
                '202' => 'Accepted',
                '203' => 'Non-Authoritative Information',
                '204' => 'No Content',
                '205' => 'Reset Content',
                '206' => 'Partial Content',
                '207' => 'Multi-Status',
                '208' => 'Already Reported',
                // 209-225   Unassigned
                '226' => 'IM Used',
                // 227-299   Unassigned
                '300' => 'Multiple Choices',
                '301' => 'Moved Permanently',
                '302' => 'Found',
                '303' => 'See Other',
                '304' => 'Not Modified',
                '305' => 'Use Proxy',
                '307' => 'Temporary Redirect',
                 // 308-399   Unassigned

    繰り返しますがこれがどのようなHTTP出力となるかはビューの仕事（関心）です。そのまま出力されるかもしれませんし、2XXは全て200で出力するかもしれません。出力実装の事は考えず、ページはページの事だけを考え自らを構成します。これはプレゼンテーション（ビュー）はページ状態の反映（プロジェクション）でなければならないという考えに基づきます。どのように表現されるかページは最後まで知りません。

    リクエストメソッドも同様です。GET, POST以外のリクエストが現状のWebサーバーやHTML4では難しい、とは考えません。別のレイヤーがそのリクエストを担い解決します。ページは純粋な動詞を持ったHTTPが普通に使われる世界にいるように記述します。

    この単純な例ではページのコンテンツをbodyプロパティにセットする事で自らを構成しました。code=200でbodyにメッセージの入った単純なページです。

    リソースクライアント

    ページリソースはいわばサービスです。それを利用するクライアント（＝リソースクライアント）がページリソースをアクセスします。このようにサーバーサイドであってもリソースクライアント・リソースサービスは常に区別されます（関心の分離）2

    $response = $resource
    ->get->uri('page://self/hello')->withQuery(['name' => 'Sunday'])->eager->request();

    リソースをアクセスするのにはこのような専用の表記(DSL)をします。これは「リソースクライアント($resource)を使って、page://self/hello というページリソースを?name=queryというクエリー（問い合わせ）でeager（直ぐに）GETリクエストする」という意味になります。

    普通のオブジェクトのメソッドコールと違って、クラス名を使わずURIを使っている点、メソッドコールが名前付引き数（順序でなく変数名で変数を指定している）で行われてる点に注意してみてください。PageリソースはWebサービスを提供しているようにリクエストを受け取とり、自己($this)をレスポンスとして返します。

    $responseをvar_dumpしてみます。

    object(helloWorld\Page\Hello)#51 (4) {
      ["uri"]=>
      string(17) "page://self/hello"
      ["code"]=>
      int(200)
      ["headers"]=>
      array(0) {
      }
      ["body"]=>
      string(12) "Hello Sunday"
    }

    ページリソースが返ってきました。HTTPレスポンスと同じようにcode, header, bodyを持っているのでheader関数とechoで出力するのは容易です。あるいはコンテンツネゴシーエションをして、リクエストヘッダーに応じてJSONやモバイル用コンテンツに出力することもできるでしょう。

    リクエスト

    eagerリクエストは即リクエスト実行です。リクエストの実行結果が取得できます。では、eagerでないリクエストは何が返ってくるのでしょうか？

    $request = $resource->get->uri('page://self/hello')->withQuery(['name' => 'Sunday'])->request();
    echo $request;

    //get page://self/hello?name=Sunday

    リクエストが返ってきます。このリクエストオブジェクトは文字列表現を持っているので、echoすることができます。リクエストオブジェクトは以下のように関数を実行するように記述すればその時にリクエストが実行されます。

    $response =  $request();

    つまり、リソースリクエストはeagerをつけると即実行、つけないといつでも実行可能なリクエストに必要な全ての情報を持っているリクエストオブジェクト、そのどちらかが得られます。 3

    REST = Representational State Transfer

    これまで見た来た様に、ページは自らの状態コードとコンテンツをセットして自分自身を構成します。4 リソースクライアントからのリクエストを受けてページはその構成された状態をreturn $this;と返します。RESTはRepresentational State Transferの略です。直訳すると（リソースの）表現状態の転送 。BEARのリソースもこの原則に従っています。

    この記事での「あいさつページリソース」は「Hello Sunday !」という（リソース）表現状態（Representational State）になってリソースクライアントに転送(Transfer)されます。Representational State Transfer、つまり RESTです。

    テスタビリティ

    リソースはその利用がサーバーサイド内部でもクライアントとサービスに分かれてるので、テストコードではそのクライアントをそのまま記述できます。

    ページの仕事はテンプレートのHTMLを構成することではなく、ページ自身を構成することなので、ページがどのような状態なのかページのHTMLを見るまでもなく、まずコードに入っています。次に（今回説明しませんでしたが）ページのヘッダーにはページのメタ情報が入っています。これもコード同様、どのように出力されるかとヘッダーの内容の実際とは関心が分離されます。5

    これらは全てページコントローラーのテスト可能性に繋がります。

    テスト時には全ての出力とPHPコンテキスト、webコンテキストをDBに保存して、デバックに役立てる事ができるかもしれません。入力と出力、プログラムのスタートアップと出力＆終了はユーザードメイン（領域）にあり可能です。6

    スクリプト

    現在試験的にこの最も上位の層での処理をPHPスクリプト(includeしただけで実行される素のPHPスクリプト）で行っています。クラスベースの通常のPHPコーディングと違い、機能単位でスクリプトを用意して複数includeする事で全体を構成しようとしています。

    例えばページリソースへのリクエストが終わった段階で、リソースリクエストをハンドルするハンドラスクリプトを用意してあれば、内部アプリケーションリソースURIに応じて特定リソースリクエストにACLを適用したり、実行をページ終了後に行う事ができます。（足跡DBの更新を画面表示のあとに行う等）このように、入力、ページリソースリクエスト、リクエスト実行、出力、などの大きな構造をユーザードメインのスクリプトを読み込むことで構成しています。

    またスクリプトをリソースとURIと対応させ、他のフレームワークやCMS等と組み合わせる事を可能にします。
    例えば、商品の残り個数がapp://self/goods/stock/quantity/?id=100というアプリケーションURIで利用可能だとして、WordPressのウィジェットなどから

    残り個数は<?php include '/path/to/goods/stock/quantity/?id=100'; ?>です

    等と呼べたらどうでしょうか。

    リソースは一意につけられるURIというIDを持ち、そのリクエストには状態がありません。自らの表現へのリンクを持つ事ができ、上記のような最小限のリクエストを可能にします。副作用のないGETリクエストは何度でも同じ状態を返すはずでキャッシュも機能するでしょう。上記の最小限のクライアント利用を前提にするので、フロントコントローラーやルーターはBEAR.Sundayではオプションになります。

    あるいはページコントローラーの無い、テンプレートとアプリケーションリソースだけがあるページはどうでしょうか。DrupalやWordPressのようなCMSの多くはコンテンツ・プルで情報が取得されます。コントローラーがテンプレートにコンテンツをpushするのではなくて、ビュートリガーで情報がPullされます。テンプレートを先に読み込み、テンプレートに出現したアプリケーションリソースがPullされます。 (詳しくはWebアプリケーションフレームワークを）

    まとめ

    モデル（アプリケーションリソース）を持たない単純なHelloWorldアプリを見てきました。リソースリクエスト専用問い合わせ言語（DSL)、ページコントローラーのビューへの無関心（ページは出力を構成しようとせず自らを構成しようとする）、ビューはページリソース状態の反映として扱われる、リソースリクエストは記録可能で遅延実行（レイジーエバリュエーション）可能などの特徴がありました。またそれらの実行フローはスクリプトで構成されアプリケーションドメインになっている。入力と出力はフレームワークが行うのではなく、フレームワークのライブラリを使うがユーザードメインで行う、つまり構成は変更できるという事を見てきました。

    今回全然触れなかったものに、アノテーションベースのGuiceスタイルのDIコンテナ、メソッドインターセプターによるアスペクト指向プログラミング、リソースリンク、TraitとDIを使ったテンプレートエンジン選択、マルチアプリケーションリソース、ユーザースキーム、HATEOAS = Hypermedia As The Engine Of Application State（アプリケーション状態のエンジンとしてのハイパーメディア）、オブジェクトグラフキャッシュ等があります。これらは実装がある程度進んで来たもので、現時点でもある程度は紹介可能です。

    HTTPを通信プロトコルとしてでなく、アプリケーションスタックとして内部、外部ともに使おうという試みでもあるのですが、今回の記事では一部コードの話で触れただけでした。これができて便利、あれを実装するのが一瞬でできる…という実装の話でなく、設計やコンセプトに興味を持ってもらったので今回の記事はそれに沿ったミニマムなものにしました。

    再度お礼を言います。あの時、スクリーンの真ん前で熱心に見て、聞いて、質問してくださった皆さん、どうもありがとうございました。また別の機会でお会いできればと思います。

    1. アプリケーション状態を表したいが、このHTTPコードに合わない時はUnassignedのところで自分のコードを決め、アサインします。例えば210はログインしてる、211は有料会員の状態等とアプリケーションコードを決めても良いでしょう。
    2. MVCで言うとMVCの外側にクライアント（エディター）がいて、外側からコントローラーを操作しているようなものかもしれません。
    3. request()以外の全てのメソッドは$thisが帰って来ててデメテルの法則に従っています
    4. ただ代入してるのだけに大げさな言い方に聞こえるかも知れませんが
    5. 現在デバック用にセットされてるメモリ使用量や速度などヘッダー（ページ実行のメタ情報）は実際のprod環境では出力されないでしょう。
    6. 設定ファイルやコードでその処理を担うクラスを指定するのではなく、直接コーディングします。
    ]]>     http://www.bear-project.net/blog/2011/12/bear-sunday-prototype/feed/ 0