カテゴリー: lifehack

PHP4 での Singleton

error_reporting(E_ALL);
class Foo {
    function &getInstance(){
        static $_singleton;
        if(empty($_singleton)){
            $_singleton = new Foo();
        }
        return $_singleton;
    }
    var $_n;
    function add(){
        echo (++$_n).”\n”;
    }
}
$o1 =& Foo::getInstance();
$o1->add(); // 1
$o2 =& Foo::getInstance();
$o1->add(); // 2
$o2->add(); // 3
$o1->add(); // 4

 & と static の使い方が肝です。
static キーワードは、指定したローカル変数のライフサイクルを延長するためのキーワードです(注1)。
 メソッド定義とメソッド呼び出しの両方に & を付けないと、参照でなくコピーになってしまい、個別のインスタンスになるために結果が 1,2,1,3 になってしまいます。
 
PHP5 の場合も上のコードを変更なしで Singleton Pattern として動作させることが可能です。
さらに、メソッドの戻り値が標準で参照になるため、& を外しても singleton を実現することができ、クライアントコードが誤用する可能性がなくなったといえます(注2)。
 
このように PHP4 ではクライアントに特殊なメソッド呼び出し方をしないと意図しない結果になるため、Singleton な動作が必要な箇所については極力非公開にして内部利用にとどめるほうが賢明かも、です。
 
注1:
static キーワードには、スコープ(可用範囲)を広げる効果はありません。
ローカル変数がフィールドになるわけではないため、異なるメソッドで同じ名前の変数を指定しても、別個の変数になります。
注2:
ただし、クライアントコードで

$o1 = clone Foo::getInstance();

のように clone を使って意図的にコピーを行った場合、PHP4 で & を付けなかったときと同様の結果になります。
この場合はクライアント側で結果が予測できるため、問題にはならないでしょう。
 
参考:
– PHP4 でデザインパターン(Do You PHP?)

sfDatabaseManager クラスを使うことで Propel より低いレイヤーでデータベースの情報を得たり、(Creaole による)データベース接続を行うことができます。
この方法を使うと databases.yml の設定を一時的に変更した上でデータベースアクセスができるようになります。

$manager = new sfDatabaseManager();
$manager->initialize(); // インスタンスに database.yml ファイルを読み込んで初期化する。
$db = $manager->getDatabase(“propel”); // “propel:” 以下を参照し、sfDatabase のインスタンスを得る。 引数を省略すると default: を参照する
 
// database.yml の設定を参照する例:
echo $db->getParameter(“phptype”).”\n”; // propel: param: phptype: を参照(“mysql” など)
echo $db->getParameter(“host”).”\n”; // propel: param: host: を参照(localhost など)
echo $db->getParameter(“database”).”\n”; // propel: param: database: を参照
echo $db->getParameter(“username”).”\n”; // propel: param: username: を参照
 
// databases.yml の設定を一時的に上書きする例:
$db->setParameter(“database”, null); // 特定のデータベースに接続しない。
                                     // (データベースが存在しなくてもエラーにならないため
                                     // CREATE DATABASE したい場合やテーブルを一切利用
                                     // しない場合などに有用)
 
// データベース接続の例:
// databases.yml の設定をもとに Creole のデータベース接続インスタンスを得る
// (vendor/creole/Connelction.php で定義される Connection 抽象クラスのインスタンス)
$con = $db->getConnection();
 
$rs = $con->executeQuery(“SELECT CURRENT_TIMESTAMP AS time”); // クエリを発行。
while($rs->next()){ // ポインタを進める(複数レコード対応)
    $row = $rs->getRow(); // レコードを連想配列で取得
    echo $row[“time”];
}

 
参考:
– Class sfDatabaseManager(symfony API)
 sfDatabaseManager のクラス定義。
 
– Class sfDatabase(symfony API)
 sfDatabaseManager::getDatabase() で得られるインスタンスの定義。
 
– SymfonyAPI – Connection Interface Reference(cpr.in-berlin.de による symfony の phpdoc)
 sfDatabase::getConnection() で得られるインスタンスの定義。
 
– SymfonyAPI – ResultSet Interface Reference(同上)
 Connection::executeQuery() で得られるインスタンスの定義。

機能テスト(functional test) やバッチスクリプト(batch)で Propel を使う方法については以前こちらの記事で

sfContext::getInstance();

を最初に実行すれば動作する、と書きました。
 
しかし単体テストで Propel を使う際は、単純に

require_once(dirname(__FILE__).’/../bootstrap/unit.php’);
sfContext::getInstance();

とするだけでは

Fatal error: Class ‘sfContext’ not found in …

のように、sfContext クラスが見付からずエラーになります。
ここで単純に sfContext を include しても、sfCore や myUser などが存在しないと言われたり、様々なエラーがでて動作しません。
前述の記事の参考URLにあるように、次のようなコードが必要になります(注: 参考元の投稿コードから僅かに手を加えています)。

// TODO: 要変更 – テスト対象のアプリケーション名
$app_name = “frontend”;
 
//begin initialise database code
include(dirname(__FILE__).’/../bootstrap/unit.php’);
include(dirname(__FILE__).’/../../config/config.php’);

require_once($sf_symfony_lib_dir.’/util/sfCore.class.php’);
sfCore::initSimpleAutoload(array(SF_ROOT_DIR.’/lib/model’ // DB model classes
                                ,$sf_symfony_lib_dir // Symfony itself
                                ,dirname(__FILE__).’/../../apps/stageselect/lib’ // Location app lib
                                ,SF_ROOT_DIR.’/plugins’)); // Location plugins
set_include_path($sf_symfony_lib_dir . ‘/vendor’ . PATH_SEPARATOR . SF_ROOT_DIR . PATH_SEPARATOR . get_include_path());
 
define(‘SF_ENVIRONMENT’, ‘test’);
define(‘SF_APP’, $app_name);
define(‘SF_DEBUG’, true);
 
sfCore::bootstrap($sf_symfony_lib_dir, $sf_symfony_data_dir);
sfContext::getInstance();
Propel::setConfiguration(sfPropelDatabase::getConfiguration());
Propel::initialize();
// end initialise database code
 
// 初期化終わり、以下テストコードが続く…
 
$lime = new lime_test();
 
// :

 
原因についてはエラーや対策のコードを見れば想像がつくと思いますが、単体テストでは機能テストと違い bootstrap (unit.php, functional.php)を include するだけで symfony プロジェクトをまるごと読み込んだり初期化しないようになっているためです。

schema.yml:

Author:
  name: varchar(255)
Article:
  title: varchar(255)
  author_id:

のように、カラム名に <主テーブル名>_id という名前を付けると、参照テーブル(Article) には,主テーブル名(Author)への foreign key が作られ、 propel のモデルクラスでそれぞれのリレーションに対する専用のメソッドが提供されて簡単にリレーションができるようになります。
 
前述の Author, Article ならばモデル生成時に次のようなメソッドが自動生成されます。

class BaseAuthor {
    public function getArticles();
    public function addArticle($article);
}
class BaseArticle{
    public funtcion getAuthor();
    public function setAuthor($author);
}

この場合, addArticle() という名前のメソッドを呼び出すと、外部キーが適切に設定されるだけでなく、メソッドを呼んだオブジェクトが save() された場合に、このメソッドで引数にしてあるオブジェクト全てに対して save() を要求してくれます。複数指定可能なので set でなく add になっているわけです。
また、getArticles() メソッドを使うと、実行インスタンス(の元になるレコード)を参照している、 Article テーブルの全てのレコードの Article クラスインスタンスを取得できます。
 
逆に、参照元のテーブルである Article クラスのインスタンスから getAuthor() を呼ぶことで、そのインスタンスが参照している Author クラスのインスタンスを得ることができます。
 
add メソッドの利用例:

// 著者登録
$author = new Author();
$author->setName(“Ernest Miller Hemingway”);
 
// $author への作品登録
$article = new Article();
$article->setTitle(“The Old Man and the Sea”);
$author->addArticle($article);
 
// $autho への作品登録その２
$article = new Article();
$article->setTitle(“For Whom the Bell Tolls”);
$author->addArticle($article);
 
// 全て書き込み
$author->save();

結果:

Author:
id | name
1 | Ernest Miller Hemingway
Article:
id | name | author_id
1 | The Old Man and the Sea | 1
2 | For Whom the Bell Tolls | 1

参照例:

 
参照時には
参考:
-Relationships(propel.phpdb.org)

■ フォワード(forward()) のテスト

object isForwardedTo(string $moduleName, string $actionName [, string $position])

モジュール $ModuleName のアクション $actionName に遷移したかをテストします
例: foo/index が boo/index にフォワードしたかを確認する

$t->get(“foo/index”)->isForwardedTo(“boo”, “index”);

 
■ リダイレクト(redirect()) のテスト

object isRedirected([boolean $boolean])

リダイレクトの要求があったかどうかをテストする。$boolean に false が指定された場合、失敗を期待する。

object followRedirect()

要求するリダイレクト先に遷移する。リダイレクト要求がないのに行った場合、例外が投げられる。
 
例: foo/index が boo/index にリダイレクト要求するかを確認する

$browser->get(“foo/index”)->
  isRedirected()->followRedirect()->
  isRequestParameter(‘module’, ‘boo’)->
  isRequestParameter(‘action’, ‘index’);

 
間違ったリダイレクトテスト方法:

object isResponseHeader($key, $value)

を使って

$browser->isResponseHeader(“Location”, “/module/action”)

とするのは間違いです。Location ヘッダは http://frontend-test/index.php/module/action のような絶対 URL になっている上、action が index の場合 action の指定が省略されるため、完全一致チェックの isResponseHeader() メソッドは不適です。

Xcache は pecl に登録されているのですが, windows だと

pecl install xdebug

としてもビルドできませんし、PHP 公式サイトの pecl モジュールのバイナリ版パッケージダウンロードにも含まれていません。
 
配布サイトを探したところ、Xdebug 公式サイトにはちゃんと Windows 版バイナリが配布されていました。
 
参考:
– Xdebug Instration(xdebug.org)
– Re: xdebug install error(xdebug-general ML)