RADフレームワークのエンジニアリング内部...NookuのPHP開発者として

誰もが独自のツールセットを持っています。 PHP開発者として、私のお気に入りの1つは、「Nooku」と呼ばれるRapidApplicationDevelopmentフレームワークです。 開発グループの言葉を借りれば、「NookuはフレームワークというよりもWeb開発ツールキットです」。

よくわからない場合は、ご覧ください。 これは、業界で受け入れられているデザインパターンを多用して、簡単に拡張および再利用できる高度にコンポーネント化されたアプリケーションを作成するオープンソースプロジェクトです（最初は主要なJoomla！開発者の1人によって作成されました）。 箱から出してすぐに、Nookuは、プロジェクトをより早く軌道に乗せるのに役立つ大量の迅速なアプリケーション開発ツールを提供します。 小さいが強力なサンプル：

• あなたがする必要があるのはレイアウトを書くことだけであるMVCのデフォルトの実装（これは私を夢中にさせたものです）
• HMVCの可用性はすぐに
• すべてのデータのJSONやXMLなどのさまざまな出力形式のサポート（つまり、APIを数分で公開します）
• デフォルトの管理およびフロントエンドの実装

Nookuの中心にあるのは、「継承を超えた構成」の設計原則です（実際、これはNookuの紹介ページの最初の概念です。1行で：複数のオブジェクトの機能を構成（または合計）して、いくつかを作成することを目指す必要があります。サブクラス化に依存するのではなく、一種の複合オブジェクト。

この原則により、記述するコードが少なくなり、多くの場合、非常に洗練されたソリューションにつながります。 では、どの程度正確に宣伝されているのでしょうか。 コードレベルでは、最良の例はミックスインとリソース/サービス識別子の使用によるものです。 見てみましょう。

Mixin

PHP 5.4より前は、この言語には特性の概念がありませんでした。 これらはクラスのような構造であり、オブジェクトによって「使用」されると、ある種の機能を提供します（多重継承と同様）。 Nookuは、 Mixinを使用してこの問題を何年にもわたって解決してきました（PHP 5.2以降）。

Mixinを使用すると、オブジェクトを一緒に作成できるだけでなく、各混合オブジェクトのメソッドを複合オブジェクトのインターフェイスに追加することもできます。 ミックスインを使用しているオブジェクトは、ミックスインされたオブジェクトのメソッドを「継承」しているようです。

 /** * Mixin an object * * When using mixin(), the calling object inherits the methods of the mixed * in objects, in a LIFO order. * * @param KMixinInterface $object An object that implements KMinxInterface * @return KObject */ public function mixin(KMixinInterface $object) { $methods = $object->getMixableMethods($this); foreach($methods as $method) { $this->_mixed_methods[$method] = $object; } // Set the mixer $object->setMixer($this); return $this; }

Nookuのほとんどすべてのオブジェクトは、ミックスインメソッドを定義した基本クラスKObjectを拡張するため、この機能を備えています。

Nookuのコントローラーアーキテクチャの主要なクラスもKObjectの子孫です。 抽象コントローラーはKControllerAbstractクラスであり、検査すると、すぐにミキシング機能を利用していることがわかります。 このクラスのインスタンスが構築されるたびに、KMixinCommandおよびKMixinBehavior機能がそのインターフェイスにすぐに追加されます。 したがって、Nookuの各コントローラーは、それぞれのオブジェクトを介したコマンドチェーンおよび動作管理機能で構成されています。

Nookuコントローラーに戻る：KMixinBehaviorクラスは、実行時に特定の動作をロードする機能をKControllerAbstractに提供するためのすべての要素を保持します。 行動戦略は、他のクラス（編集可能、注文可能など）によって分離して使用できるプロセスまたはロジックを記述するクラスです。 KMixinBehaviorは非常に単純で、getBehavior、hasBehavior、addBehavior、getBehaviorsの4つのメソッドしかありません。 そして、オブジェクトにさまざまな動作戦略を処理およびカプセル化する機能を提供するために必要なのはこれだけです。

同様に、KMixinCommandには、getCommandContext、getCommandChain、setCommandChainの3つのメソッドしかありません。 ご想像のとおり、これら3つのメソッドは、KControllerAbstractにコマンドチェーンを実装する機能を提供しますが、実行時に実装できるようにします。

このミキシングは、単純な算術加算と考えることができます。

次のようなインターフェースを提供します：

定義上、抽象クラスは拡張されることを意図しているため、継承の魔法によって、子またはKControllerAbstractのインスタンスであるすべてのオブジェクトは、実行時に動作とコマンドチェーンを追加する機能も取得します。

かっこいいね。 しかし、それは実際にはどういう意味ですか？ つまり、Nookuはコンポーネント化された機能を提供します。 つまり、Nookuを使用すると、実行時に機能をモジュール化し、モジュール間で機能を構成できます。

これらの2つの例は、構成を示すのに役立ちます。 また、NookuRADフレームワークがコアでのさらなる構成をサポートしていることを示すのにも役立ちます。 これは重要な利点です。 上記のKControllerAbstractに追加されたメソッドは、1行のコードが記述される前に変化するものをカプセル化するツールを開発者に提供することにより、「戦略設計パターン」をサポートします。 mixin（）メソッドがKObjectのすべての拡張機能の一部であるという事実は、実行時に他の動作管理インターフェイスを簡単に定義して、ほとんどのオブジェクトに追加できることを意味します。

サービスとリソースの識別子とロケーター：クラス名をオブジェクトから切り離します

Nookuのサービスおよびリソース識別子とロケーターも、関心の分離を強力にサポートします。

ここでも、KObjectだけでなく、KServiceも見てみましょう。 Nookuのほとんどのものをサービスまたはリソースとして扱うことができるため、まったく同じ方法でそれらをインスタンス化して問い合わせることができます。

食料品店に行って商品を購入するときは、その店をサービス、つまりB列に並べることができるアイテムのコレクションと考えてください。 リソースとしての製品、つまり、次のような単一のアイテム/ソリューションロジック。

• 具体的に見た（リード）（例えば、トマトスープの缶を見て）
• 店内を移動（ E dited）（たとえば、スープを農産物の通路に移動）
• ストアの在庫に追加または削除（ A ddおよびDelete ）（たとえば、新しい種類のスープを追加してトマトを取り除く）

この例をさらに取り上げて、食料品店にフランチャイズ部門があり、ビジネスをしたいとします。 そのような状況では、サービスはフランチャイズ部門であり、リソースは購入した食料品店です。 それは非常に文脈上の分類です。 全体として、これはBREADアクションパターンとして知られています（これらはそれぞれ、KControllerServiceとKControllerResourceの間に「_action」が前に付いたもの、つまり_actionRead（）で表されます）。

モデルはサービス、テーブルオブジェクトはサービス、特定のMVCトライアドはリソースまたはサービスとしてインスタンス化され、サービスの問い合わせから得られた特定のレコードはリソースと見なすことができます。

Nookuのすべてのオブジェクトは、オブジェクトの複合体であり、すべてのオブジェクトに、「サービスコンテナ」内のアプリケーション全体のインスタンス化されたサービスへの参照と、getService（）と呼ばれるサービスにアクセスするためのメソッドが含まれています。 KObject :: getService（）メソッドに必要なのは、有効なリソース識別子を渡すことだけです。これにより、すぐに使用できるインスタンス化されたサービスが返されます。

PHPの迅速なアプリケーション開発では、リソース識別子は、オブジェクトのインスタンス化をそのクラス名から切り離し、その識別のエイリアスを提供する強力な方法を提供します。 これは、アプリケーションの保守性に重要な影響を及ぼします。 エイリアシングにより、開発者は、KService :: addAlias（）を使用して1行のコードを追加することにより、特定の識別子でインスタンス化されるすべてのオブジェクトで使用されるクラスを変更できます。

私たちがよく知っているリソース識別子の例は、URIまたはUniformResourceIdentifierです。

これは、KServiceが適切なクラスを見つけてロードするために必要なすべての情報です。 これらの部分は、配置とインスタンス化の予測可能性を提供するNookuのクラスの命名と配置の規則と一致します。 上記の識別子の例（com：//site/user.database.table.user）は、ComUserDatabaseTableUserというクラス名を持つファイル/components/com_user/databases/tables/user.phpを読み込もうとします。 ちなみに、ファイルが存在しない場合、フレームワークはデフォルトのテーブルオブジェクトを提供し、データベースの命名とIDスキーマの規則に基づいてファイルを構築します（これは私をもう少し夢中にさせました）。 前述のように、KServiceでは識別子のエイリアスを設定することもできます。 KService::setAlias('maindbaseadapter','com://admin/default.database.adapter.mysqli')を使用する; KService::getService('maindbaseadapter')を使用してdbオブジェクトをロードします。

これにより、前述のデカップリングが可能になり、アプリケーションの保守と拡張に大きな利点がもたらされます。 必要に応じて、「site」と「admin」以外のアプリケーションを自由に作成できます。ここで説明する識別子を使用すると、他のアプリケーションにあるサービスを簡単に使用して、ソリューションが要件を満たすのに役立ちます。 繰り返しになりますが、これは、NookuがPHPおよびRADの開発者とチームに、単一のクラスオブジェクトだけでなく、サービスとアプリケーション全体の構成を無料でサポートする方法のもう1つの例です。

まとめ

継承をめぐる構成を中心に。 さらなるアマルガムをサポートするために存在する、スマートで既存の構成と構造。 また、ここで説明する識別子を備えた無料のサービス指向アーキテクチャであるNookuは、強力なRADフレームワークを提供し、他のPHP開発ツールよりも大幅に有利なスタートを切ることができます。