#symfonyadvent2012

Symfony Advent Calendar JP 2012 - Day 7

Symfonyでアプリケーションを開発する際に利用できる、Eclipse PDTとSymfony Plug-inを導入した環境での入力補完（特にSymfony統合の部分）について紹介します。

使用したEclipse、PDT、Symfony Plug-in等のバージョンは以下になります。p2-nightlyリポジトリから開発最新版をインストールしています。現時点では安定版ではありませんのでご注意ください。

Eclipse Version: 4.3.0 Build id: I20121031-2000

PDT Core Plug-in Version 3.1.1.201209101312

PDT Extensions Core Plug-in Version 0.0.13.201212042111

Symfony Core Plug-in Version 1.0.88.201212041906

Symfony Twig Plug-in Version 1.0.88.201212041906

PDT Extensions groupが提供するupdate-siteのp2-nightlyには、上記を含めたPHP向けの最新のプラグイン一式が登録されています。

Symfony Plug-inを導入したEclipseでプロジェクトのSymfony natureを有効にすると、様々な入力補完が利用できます。

テンプレートリソースの論理名補完

Symfonyではテンプレートを「バンドルクラス名:リソースディレクトリ名:ファイル名」のようにコロンで区切った3つのパートから成る論理名で指定します（例：AcmeDemoBundle:Demo:hello.html.twig）。

コントローラクラスのrender()メソッドの第1引数のように、テンプレート論理名を要求する箇所にて文字列の引用符内で補完を起動すると、テンプレート論理名が補完されます。論理名の最初のパートはバンドルクラス名なので、バンドルクラス名の一覧が表示され、インクリメンタルに絞り込むなどして補完入力が可能です。候補一覧では名前の左にバンドルであることを示す「B」アイコンが表示されます。

バンドルクラス名を決定し2つ目のパートに入ると、選択したバンドル内のリソースディレクトリの一覧が表示されます。（※現時点ではコントローラクラス名と対応しているものしかリストアップされないようです。）候補一覧では、名前の左にコントローラであることを示す「C」アイコンが表示されます。

3つ目のパートでは、選択したバンドルのリソースディレクトリにあるテンプレートファイルの一覧が表示されます。候補一覧では、名前の左にテンプレートファイルであることを示す「T」アイコンが表示されます。

このようにリソースの名前が長くなっても、補完を使ってポンポンと素早く正確に入力できます。

ルート名の補完

テンプレート名の補完と同様に、ルート名も補完で入力できます。コントローラクラスのgenerateUrl()メソッドの第1引数のように、ルート名を要求する箇所にて文字列の引用符内で補完を起動すると、ルート名が補完されます。候補一覧では、名前の左にルート名であることを示す「R」アイコンが表示されます。

この補完候補一覧ウィンドウから候補を選ぶ（決定ではなく）と、そのルートの情報がホバーウィンドウに表示されます。ルートのURLパターンやパラメータのリスト、バインドされるアクションメソッド等をその場で確認できます。

サービス名の補完

DIコンテナに登録されているサービス名も補完で入力できます。コントローラクラスのget()メソッドの第1引数のように、サービス名を要求する箇所にて文字列の引用符内で補完を起動すると、サービス名が補完されます。候補一覧では、名前の左にサービスであることを示す「S」アイコンが表示されます。

Twigテンプレート上での補完

Symfony Plug-inとTwig Plug-inを合わせて導入しておくと、Twigテンプレート上でもSymfonyインテグレーションが有効になります。例えばTwigテンプレートでextendsにより継承元テンプレートリソースを指定する場合、コントローラでのrender()メソッドと同様に論理名を補完入力できます。

さらにextends先テンプレートでは、blockの補完も行えます。継承元で定義されているblock名を補完入力できます。

まとめ

暗黙の規約がほとんどゼロであるSymfonyでは、リソースの指定などにおいて明示性が重視されているため、すべて手入力していると手間になります。同時に誤入力の可能性も高まります。IDEの機能をフル活用すれば、入力の手間と誤入力の防止を同時に実現できます。Symfonyとの高次なインテグレーションを実現するEclipse + PDT + Symfony Plug-inは、SymfonyでWebアプリケーションを開発する上で必須ともいえるツールになっていくでしょう。

Symfony Advent Calendar JP 2012 - Day 6

今回はStagehand_TestRunner、Piece_Flow等、Piece Frameworkのいくつかのプロダクトで使われているConfigコンポーネントについて解説します。

Symfony Configコンポーネント

Configコンポーネントはソフトウェアの可変部分を表現する言語を定義し、処理するためのフレームワークです。Symfonyフレームワークにおいてはバンドルおよびその背後にあるコンポーネントの可変部分をユーザーが構成するために使われています。

Configコンポーネントが取り扱うのは一般的に設定や構成と呼ばれるものです。

設定はDSLである

ドメイン固有言語 (DSL) は特定用途向けの言語です。ドメイン固有言語は、システムファミリの具体的なメンバを「発注」するのに使い、ゆえにジェネレーティブプログラミングにおいて重要な役割を果たします。

— ジェネレーティブプログラミング (IT Architects’Archive CLASSIC MODER)

設定はソフトウェアの可変部分（可変点）に対する具体的な値であり、最終的にオブジェクトのような実装コンポーネントの構成に変換されます。別の言い方をすると、設定によって具体的なソフトウェアが構成されます。

設定はドメイン固有の言語の体裁を持っているため、ドメイン特化言語（DSL: Domain Specific Language）であるといえます。

パーサージェネレーター？

設定言語が存在する以上そのパーサーは必須となりますが、PHPの世界ではこれまでは手書きのもので済ませてきた事例が大部分を占めるのではないでしょうか。手軽に使えるパーサージェネレーターが存在しないことが大きな理由かもしれませんが、それだけでしょうか？

Symfonyフレームワークでは設定の記述にINI、PHP、XML、YAML、その他任意のフォーマットを使うことができます。通常のパーサージェネレーターが単一のテキストフォーマットに対する文法を定義することでパーサーを生成するものだとしたら、フォーマット毎に文法定義が必要となり現実的ではありません。

抽象構文を定義する

まず、抽象構文を定義します。これは抽象形の「スキーマ」です。

次に「エディタ」を定義し、抽象形を投影を通じて操作可能にします。

それから「ジェネレータ」を定義します。これは抽象形をどのように実行可能形に変換するかを定義しています。実際には、ジェネレータはDSLのセマンティクスを定義します。

— Martin Fowler's Bliki in Japanese - LanguageWorkbench 新しいDSLの定義

Configコンポーネントでは特定のフォーマットについてではなく、設定の抽象形（抽象構文木）について文法を定義します。これによって単一の文法で複数のフォーマットをサポートすることが可能になります。

DSLの観点から見れば、Configコンポーネントはグラマー言語による設定言語の文法定義を核とするDSL構築フレームワークといえるでしょう。

Configコンポーネントを単体で利用する

Configコンポーネントを単体で利用するのはそれほど難しくはありません。まずは設定言語定義と設定の処理の関係を図でみてみましょう。

グラマー言語による設定言語の定義

Configコンポーネントを利用する場合の主な活動はグラマー言語によって設定の抽象構文を定義することです。以下は現在開発中のPiece_Flow v2におけるページフロー定義の文法を記述したものです。

Piece\Flow\PageFlow\Definition17Configuration:

<?php ... namespace Piece\Flow\PageFlow; ... use Symfony\Component\Config\Definition\Builder\TreeBuilder; use Symfony\Component\Config\Definition\ConfigurationInterface; ... class Definition17Configuration implements ConfigurationInterface { public function getConfigTreeBuilder() { $treeBuilder = new TreeBuilder(); $treeBuilder->root('definition17') ->children() ->scalarNode('firstState')->isRequired()->cannotBeEmpty()->end() ->arrayNode('viewState') ->isRequired() ->requiresAtLeastOneElement() ->prototype('array') ->children() ->scalarNode('name')->isRequired()->cannotBeEmpty()->end() ->scalarNode('view')->isRequired()->cannotBeEmpty()->end() ->arrayNode('transition') ->prototype('array') ->children() ->scalarNode('event')->isRequired()->cannotBeEmpty()->end() ->scalarNode('nextState')->isRequired()->cannotBeEmpty()->end() ->arrayNode('action') ->children() ->scalarNode('class')->defaultNull()->cannotBeEmpty()->end() ->scalarNode('method')->isRequired()->cannotBeEmpty()->end() ->end() ->end() ->arrayNode('guard') ->children() ->scalarNode('class')->defaultNull()->cannotBeEmpty()->end() ->scalarNode('method')->isRequired()->cannotBeEmpty()->end() ->end() ->end() ->end() ->end() ->end() ->arrayNode('entry') ->children() ->scalarNode('class')->defaultNull()->cannotBeEmpty()->end() ->scalarNode('method')->isRequired()->cannotBeEmpty()->end() ->end() ->end() ->arrayNode('exit') ->children() ->scalarNode('class')->defaultNull()->cannotBeEmpty()->end() ->scalarNode('method')->isRequired()->cannotBeEmpty()->end() ->end() ->end() ->arrayNode('activity') ->children() ->scalarNode('class')->defaultNull()->cannotBeEmpty()->end() ->scalarNode('method')->isRequired()->cannotBeEmpty()->end() ->end() ->end() ->end() ->end() ->end() ->arrayNode('actionState') ->prototype('array') ->children() ->scalarNode('name')->isRequired()->cannotBeEmpty()->end() ->arrayNode('transition') ->isRequired() ->requiresAtLeastOneElement() ->prototype('array') ->children() ->scalarNode('event')->isRequired()->cannotBeEmpty()->end() ->scalarNode('nextState')->isRequired()->cannotBeEmpty()->end() ->arrayNode('action') ->children() ->scalarNode('class')->defaultNull()->cannotBeEmpty()->end() ->scalarNode('method')->isRequired()->cannotBeEmpty()->end() ->end() ->end() ->arrayNode('guard') ->children() ->scalarNode('class')->defaultNull()->cannotBeEmpty()->end() ->scalarNode('method')->isRequired()->cannotBeEmpty()->end() ->end() ->end() ->end() ->end() ->end() ->arrayNode('entry') ->children() ->scalarNode('class')->defaultNull()->cannotBeEmpty()->end() ->scalarNode('method')->isRequired()->cannotBeEmpty()->end() ->end() ->end() ->arrayNode('exit') ->children() ->scalarNode('class')->defaultNull()->cannotBeEmpty()->end() ->scalarNode('method')->isRequired()->cannotBeEmpty()->end() ->end() ->end() ->arrayNode('activity') ->children() ->scalarNode('class')->defaultNull()->cannotBeEmpty()->end() ->scalarNode('method')->isRequired()->cannotBeEmpty()->end() ->end() ->end() ->end() ->end() ->end() ->arrayNode('lastState') ->addDefaultsIfNotSet() ->children() ->scalarNode('name')->isRequired()->cannotBeEmpty()->end() ->scalarNode('view')->isRequired()->cannotBeEmpty()->end() ->arrayNode('entry') ->children() ->scalarNode('class')->defaultNull()->cannotBeEmpty()->end() ->scalarNode('method')->isRequired()->cannotBeEmpty()->end() ->end() ->end() ->arrayNode('exit') ->children() ->scalarNode('class')->defaultNull()->cannotBeEmpty()->end() ->scalarNode('method')->isRequired()->cannotBeEmpty()->end() ->end() ->end() ->arrayNode('activity') ->children() ->scalarNode('class')->defaultNull()->cannotBeEmpty()->end() ->scalarNode('method')->isRequired()->cannotBeEmpty()->end() ->end() ->end() ->end() ->end() ->arrayNode('initial') ->children() ->scalarNode('class')->defaultNull()->cannotBeEmpty()->end() ->scalarNode('method')->isRequired()->cannotBeEmpty()->end() ->end() ->end() ->arrayNode('final') ->children() ->scalarNode('class')->defaultNull()->cannotBeEmpty()->end() ->scalarNode('method')->isRequired()->cannotBeEmpty()->end() ->end() ->end() ->end() ; return $treeBuilder; } ...

この設定言語に対応する設定例は以下のようになります。

Warning この例にはルートノードdefinition17の記述がありませんが、通常はルートノードを記述する必要があります。

firstState: Input lastState: name: Finish view: Finish activity: method: onFinish viewState: - name: Input view: Input activity: method: onInput transition: - event: next nextState: Validation - name: Confirmation view: Confirmation activity: method: onConfirmation transition: - event: next nextState: Registration - event: prev nextState: Input actionState: - name: Validation activity: method: onValidation transition: - event: invalid nextState: Input - event: valid nextState: Confirmation - name: Registration activity: method: onRegistration transition: - event: done nextState: Finish

DSLはそのソフトウェアのユーザーのための高レベルなAPIであり、ドメインの言語を使ってユーザーの要求に適合した抽象度で書けることが望まれます。

設定の読み込み、結合、バリデーション、デフォルト値入力

設定の読み込みは任意の方法で行います。基本的にはYamlコンポーネント（YAML）やDependency Injectionコンポーネント（INI、PHP、XML、YAML）が提供するものを使うと良いでしょう。前述のConfigurationInterfaceオブジェクトと読み込まれた設定をSymfony\Component\Config\Definition\Processor::processConfiguration()メソッドに渡すことで、複数の設定の結合、バリデーション、デフォルト値入力が行われ、最終的な設定が返されます。

Piece\Flow\PageFlow\PageFlowGenerator:

<?php ... namespace Piece\Flow\PageFlow; ... use Symfony\Component\Config\Definition\Processor; use Symfony\Component\Yaml\Yaml; ... class PageFlowGenerator { ... protected function readDefinition() { $processor = new Processor(); return $processor->processConfiguration( new Definition17Configuration(), array('definition17' => Yaml::parse($this->pageFlowRegistry->getFileName($this->pageFlow->getID()))) ); } ...

設定の利用

最終的な設定は抽象構文木を表現する配列になっているため、簡単に利用することができます。以下のコードでは、前述のreadDefinition()メソッドの呼び出しによって得られた設定にアクセスし、その値を使ってPiece\Flow\PageFlow\PageFlowオブジェクトを構成しています。

Piece\Flow\PageFlow\PageFlowGenerator:

<?php ... namespace Piece\Flow\PageFlow; ... class PageFlowGenerator { ... public function generate() { $definition = $this->readDefinition(); if (State::isProtectedState($definition['firstState'])) { throw new ProtectedStateException("The state [ {$definition['firstState']} ] cannot be used in flow definitions."); } $this->fsmBuilder->setStartState($definition['firstState']); if (!empty($definition['lastState'])) { if (State::isProtectedState($definition['lastState']['name'])) { throw new ProtectedStateException("The state [ {$definition['lastState']['name']} ] cannot be used in flow definitions."); } $this->fsmBuilder->addTransition($definition['lastState']['name'], Event::EVENT_END, State::STATE_FINAL); $this->configureViewState($definition['lastState']); $this->pageFlow->addEndState($definition['lastState']['name']); $this->pageFlow->addView($definition['lastState']['name'], $definition['lastState']['view']); } $this->configureViewStates($definition['viewState']); $this->configureActionStates($definition['actionState']); if (!empty($definition['initial'])) { $this->fsmBuilder->setExitAction(State::STATE_INITIAL, $this->wrapAction($definition['initial'])); } if (!empty($definition['final'])) { $this->fsmBuilder->setEntryAction(State::STATE_FINAL, $this->wrapAction($definition['final'])); } $this->pageFlow->setFSM($this->fsmBuilder->getFSM()); return $this->pageFlow; } ...

ConfigコンポーネントをSymfonyバンドルで利用する

ConfigコンポーネントをSymfonyバンドルで利用するのはとても簡単です。FooBarBundle\DependencyInjection\Configurationクラスで設定言語を定義し、FooBarBundle\DependencyInjection\FooBarExtensionクラスで設定の結合、バリデーション、デフォルト値自動入力を行い、最終的な設定をDIコンテナのパラメーターやサービス定義に変換します。以下のコードはSymfony\Bundle\FrameworkBundle\DependencyInjection\FrameworkExtensionクラスの例です。

Symfony\Bundle\FrameworkBundle\DependencyInjection\FrameworkExtension:

<?php ... namespace Symfony\Bundle\FrameworkBundle\DependencyInjection; ... class FrameworkExtension extends Extension { ... public function load(array $configs, ContainerBuilder $container) { $loader = new XmlFileLoader($container, new FileLocator(__DIR__.'/../Resources/config')); $loader->load('web.xml'); $loader->load('services.xml'); ... $configuration = $this->getConfiguration($configs, $container); $config = $this->processConfiguration($configuration, $configs); $container->setParameter('kernel.secret', $config['secret']); ...

おわりに

ジェネレーティブプログラミングを標榜する私にとって、ConfigコンポーネントはSymfonyコンポーネントの中でもとりわけ重要な位置付けにあります。今後も様々な場面で積極的に使うことになるでしょう。

参考

Config (current) - Symfony

Symfony Advent Calendar JP 2012 - Day 3

ドメイン駆動設計にしたがってドメインモデルをソフトウェアとして表現するのにエンティティが使われます。エンティティは、ドメイン駆動設計におけるモデル駆動設計パターンの1つに分類されます。

賢すぎるエンティティはアンチパターン

Ruby on Rails由来のアクティブレコードと直結したMVCフレームワークでは、本来エンティティとして扱われるべきクラスを「モデルクラス」と呼び、そこにビジネスロジック等を実装することが推奨されていました。これらのフレームワークでは、自らモデルレイヤー部分もカバーしておきながら、すべてをエンティティとして実装することを強いるため、ドメインモデルの実装にはほとんど自由度がありませんでした。

このスタイルに慣れてしまうと、ピュアなクラスでドメインレイヤーを実装できる状況においても、誤った設計に陥ってしまいます。

問題

責務が多すぎることにより、依存関係が複雑になる

レイヤーの境界があいまいになりやすい

実装時の明確な指針がないため、知識の分散が生じやすい

解決

ドメインモデルを分析・設計する時に使える手法として「責務駆動設計」があります。責務駆動設計とは、「オブジェクトデザイン（Object Design: Roles, Responsibilities, and Collaborations)」等で紹介されているオブジェクト指向による分析・モデリング手法です。オブジェクトデザインでは、分析によって現れたクラスを責務に分割していく時に6つの「ロールステレオタイプ」を用います。

情報保持役(Information Holder)

構造化役(Structurer)

サービス提供役(Service Provider)

制御役(Controller)

調整役(Coordinator)

インターフェース役(Interfacer)

エンティティは本来「情報保持役」であり、オブジェクト指向のクラス設計原則（SOLID）に従えば、これ以外の責務を持つべきではありません。（注意深く設計する場合、1つのオブジェクトに複数の責務を割り当てることもできます。） 明らかなことは、何でもかんでもエンティティに詰め込んで賢くするのではなく、責務を見分けて適度に分割すべきということです。

ドメイン駆動設計のパターン（エンティティ、値オブジェクト、リポジトリ、サービス、ファクトリ）やオブジェクトデザインの6つのロールステレオタイプなどを設計の型として用いることで、「良い設計、良いソフトウェア」を実現しやすくなるといえるでしょう。

最後に、オブジェクト広場にて2008年に掲載されたオブジェクトデザインの著者Rebecca Wirfs-Brockさんへのインタビューで「良い設計」について話された部分を引用します。

「良い設計」とは何なのでしょうか？たとえば、質であったり、構造の美しさであったりするのでしょうか？

これは面白いところですね。「良い設計」は「十分に良い設計」と異なります。Scott Ambler さんなどは、 just barely good enough modeling (*5) を提唱していますが、私は「十分良い設計」は実のところ十分ではないと思っています。 シンプルなものの中には、シンプル「過ぎる」ものもあります。問題が複雑である場合、その解決策も複雑になりがちです。その際は、コードも分かりやすいものになるとは限りません。複雑であり、シンプルにできないためです。理解できるものである必要はありますね。

「良い設計」とは、将来起こりえると思うことや、減らしたいリスクを考慮しているものです。また、結果としての実装が、安心して使えるものであり、メンテナンスしやすいものである必要もあります。

また、設計は変更に耐えるものでなければなりません。設計に何一つ追加できないのは良くないですよね。 将来起こりえると思うことを考慮した、分かりやすさに関する適切なバランスが必要ですね。また、2 年前には良かったものでも、5 年後にはよくないものになる場合もあります。その場合は、新しく作り直したり、考え直したりする必要があります。

参考

オブジェクトの広場： Rebecca Wirfs-Brockさんインタビュー( 前編 )

Amazon.co.jp ウィジェット