17 July 2014

前回の記事でUNICORNはコールされたクラス名と実体ファイルのクラス名が一致している必要が無いと説明しました。

・package.xmlの中のValidationsクラスの定義

・・・
<Validations> ← コールされるクラス名でXMLNodeを定義
	↓ コールされた時にUNICORNのオートローダーが読み込みを行うクラスファイルの実態
	<link mapfrom="GenericValidations" mapto="Validations">default.implement.Utilities/GenericValidations</link>
	         ↑ 実態の実クラス名              ↑ コールされたクラス名に変換する定義  ↑ 実態のファイルパス
</Validations>
・・・


・Validationsクラスの実装

<?php
class GenericValidations {
・・・
}


・Validationsクラスを利用するコードの実装

<?php

require_once "[貴方の何処かのワークスペース]/UNICORN/src/lib/FrameworkPackage/core/UNICORN"

// メールアドレスかどうかをチェックする
echo Validations::isEmail('saimushi@hoge.hoge');

?>


・実行結果

1

この機能を簡単な言葉に置き換えると
つまりUNICORNは
論理クラス名でクラスをコールする機能
を提供していると言う事です。

この機能を利用する事で、UNICORNではより柔軟で強力な機能拡張を、クラスに施す事が出来るようになっています。

 

GenericValidationsクラスには、実は大したメソッドが用意されて居ません。
なのでGenericValidationsクラスを拡張して 新たにisDomainメソッドを追加しようと思ったとします。

通常であれば

・拡張クラスの新規作成

<?php
class MyValidations extends GenericValidations
{
    public static function isDomain($argment){
    ・・・
    }
}


・実装クラス

// メールアドレスかどうかをチェックする
echo MyValidations::isEmail('saimushi@hoge.hoge');
↑
リファクタリング等で利用クラス名を変更する。

echo MyValidations::isDomain('hoge.hoge');
↑
拡張したクラスメソッドをコールする

このような感じの拡張修正になると思います。

しかしUNICORNならもっと簡単にクラスの拡張修正が行えます。

同じ修正をUNICORNで行った場合は

・拡張クラスの新規作成

<?php
class MyValidations extends GenericValidations
{
    public static function isDomain($argment){
    ・・・
    }
}
?>

・package.xmlの中のValidationsクラスの定義を拡張

・・・
<Validations>
	<link>default.implement.Utilities/GenericValidations</link>
	<link mapfrom="MyValidations" mapto="Validations">default.implement.Utilities/MyValidations</link>
	  ↑ 新たに作成した拡張クラスを実行クラスとして定義を追加する
	         ↑ 実態の実クラス名を作成したクラス名に変更する
</Validations>
・・・

・実装クラス

<?php

require_once "[貴方の何処かのワークスペース]/UNICORN/src/lib/FrameworkPackage/core/UNICORN"

// メールアドレスかどうかをチェックする
echo Validations::isEmail('saimushi@hoge.hoge');
↑
元のコードには何も変更を加える必要は無い

// ドメインかどうかをチェックする
echo Validations::isDomain('hoge.hoge');
↑
拡張したクラスメソッドをコールする

?>


・実行結果

11

このようになります。

見ての通り殆どpackage.xmlの定義変更だけで、クラスの拡張が出来ます。
しかも、実装クラスの利用クラス名に変更を加える必要がありません。

コレが

「論理クラス名でクラスをコールする機能」

の、使い処になります。

 

プロジェクトは時間の経過と人の入れ代わりによって、ポリシーを失って行きます。
どんなにコーディング規約で縛っても、既存クラスの拡張とクラス名の変更はバグリスクに大きくインパクトして行く宿命にあると思います。
そのリスクを軽減しつつ、最大のメンテナンス性を発揮する事に

「論理クラス名でクラスをコールする機能」

は、一役買ってくれると思います。
是非利用してみて下さい。

 



blog comments powered by Disqus