PHPにおける例外クラスの設計考察
この記事はPHP Advent Calendar 2017の2日目です。 ここ最近、本業のほうが死ぬほど忙しく、すっかりブログを書いていなかった@Hirakuです。 だいぶ前のことですが、今年のPHPカンファレンス福岡で例外の話をしてきました。 この時の発表では例外に関する概要が主だったので、例外クラスそのものの設計について補足を書いてみることにします。 例外のある世界観 PHP7ではいくつかのエラーが例外と同じ挙動を示すようになり、エラーではなく例外機構を使う言語に様変わりしました。 例外というのは、かなり侵略性の高い概念であり、例外のある世界では以下の前提に立つことが暗黙のうちに強要されます。 どこでも例外が発生する可能性がある 例外によって中断されても、ソフトウェアが不適切な状態にならないように保証するのは各プログラマの責任(例外安全) たとえば、以下の関数で例外が発生する可能性があ
ドメイン駆動設計という救世主 - PHPでデータベースを扱う(2)
Userテーブルに対してデータをinsertするメソッドを考えます。愚直なこんなインターフェースはどうでしょうか？ class UserMapper { //... function insert( $nickname, $password, $firstname, $lastname, $birthday ) { //... } } …この引数を覚えていられる人はそう多くないと思います。もしプログラムを間違えて、nicknameとfirstnameを逆に指定してしまったら、本名がnicknameとして登録されてしまいます。本名が誤って表示されてしまうという致命的な事故につながります。危なっかしいプログラムですね。 では、順番を考慮しなくていいように連想配列にすればどうでしょうか？ class UserMapper { //... function insert(array $data)
DAOの悪夢 - PHPでデータベースを扱う(1)
最近、昔の自分が書いたコードをメンテしているのですが、何というか、「ええい、誰じゃこのコードを書いたのは！！」と叫んでは「…4年前の俺でした…」とセルフツッコミを繰り返しています。すごく読みにくいコードで、ストレスたまりまくりです。そのため、「今ならどう書くか」をよく考えました。ちょっと長くなるかもしれませんが、アンチパターンとして解説したいと思います。 DAOパターンについて 私が鬱々としてメンテしているコードですが、データベースとのやり取りを行うためのクラスです。当時意識していませんでしたが、改めて見ているとDAOパターンを再現しているものでした。 DAO(Data Access Object)とはデザインパターンの一種で、データベースへのアクセスロジックを集約したクラスのことです。有名なGang of Fourによる23種の基本デザインパターンには直接含まれていませんが、Facade
PHPの名前空間の効果的な使い方を考える
PHPは5.3から名前空間が導入され、名前の衝突を避けるため長いクラス名をつけることから解放されました。しかしながら、名前空間を使ったコードは、名前空間を使っていないものに比べて本当に読みやすくなっているのでしょうか？ ここで例を挙げます。PHPの良質なソースコードと言えば、私はZend Framework(ZF)やSymfonyを思い浮かべるのですが、ZFのとあるクラスの冒頭を見てみましょう。 https://github.com/zendframework/zf2/blob/master/library/Zend/Mvc/View/Console/RouteNotFoundStrategy.php <?php /** * Zend Framework (http://framework.zend.com/) * * @link http://github.com/zendframewo
PHPのDIで動的にオブジェクトを確保する考察
Dependency InjectionがPHPでも流行っているそうです。が、未だによくわからないので、わからないところを自分なりに考察してみます。 ※DIコンテナではなくデザインパターンとしてのDIを考えます。 Dependency Injectionとは Dependency Injectionはデザインパターンの一種です。日本語なら依存性の注入と訳されます。「Inversion of Control コンテナと Dependency Injection パターン」が原典でしょうか。 ざっくり要約すると「クラスの中でnewしてはいけない。必要なインスタンスは外から突っ込むべし」というところかな。 class Y { private $x; function __construct() { $this->x = new X; } //...$xを使ったコード色々... } 上記のYクラス
PHPのinterfaceとは何か
久しぶりの更新です。最近、修行だと思って色々な本を読み漁っているのですが、やっとこさPHPのinterfaceが分かるようになってきた感じがあるので、まとめてみます。 インターフェースは、クラスから"ユーザー定義型"の能力のみを分離した言語機構です。PHPのそれはJavaのinterfaceのパクリです。 "ユーザー定義型"という単語を使いました。動的型付き言語のことを「型のない言語」と言う人がたまにいるんですが、とんでもねー間違いです。PHPにだって型はあります。変数が型を持たず、値が型を持っているというだけの話です。 interfaceを宣言する文法はクラスとよく似ていますが、キーワードclassの代わりにキーワードinterfaceを使います。中身は定義のないメソッドの宣言を書きます。なお、定数も含めることが可能です。 <?php interface FooInterface { c
composer searchが非常に遅い件
PHP界で流行っているパッケージ依存管理ツールComposerですが、使っているでしょうか。似たようなツールはだんだん淘汰されてComposerに一本化され、PEARより盛り上がっている感じです。 がしかし。個人的に使った感触では、表題の通り、検索が遅くてたまらんです。（前からそうだったと思うんですが、一向に改善されないばかりか悪化しているのでは？） 実行するマシンのスペックに依存しますが、手元にあるVMPlayer上で動かしているしょぼいFreeBSDだと、composer search phpunitするだけで2分ほど動きが止まります。PackagistのWeb UI上で検索すると一瞬で結果が返ってくるのに。。 Composerにはcomposer initという、composer.jsonを対話的に作るコマンドがありますが、使いたいライブラリを一つ検索するたびに数分待たされるので、非
protectedを乱用してパッケージメンバを作る
PHPではprivateと宣言したプロパティ、メソッドは、同じクラスのインスタンスであれば相互にアクセスできます。あまり意識することはないですが、たまにぎょっとすることになります。 <?php class Klass { private $data; function __construct($init) { $this->data = $init; } function get(self $o) { return $o->data; } } $a = new Klass('a instance'); $b = new Klass('b instance'); //echo $a->data; //これはエラーになる echo $b->get($a); //a instance //$bが$aのprivateメンバを読めた これはprotectedの場合でも同様であり、しかも継承したクラス
それでもPHPにfinallyが必要な理由
PHP Conference 2012で知ったのですが、PHP5.5にはfinallyが搭載される見込みだそうです。 搭載されるのはいいのですが、昔、「PHPにfinallyはないけどデストラクタがあるよ」と題してfinally不要説を書いたことがあるので、もう少し考察を行ってみたいと思います。自分で自分に反論を書いてるのもアレなんですけど。 ※RFCは追いかけてなかったので、本記事は想像で書いています。ツッコミください。 finally不要説 私が主張した内容を要約するとこんな感じです。 finallyの主な用途はファイルのクローズやDBの接続断などの「後始末処理」である。 後始末はデストラクタで行うこともできる。 PHPではデストラクタの動作が保障されている。（参照カウントによるGC） ゆえにデストラクタを正しく使えばfinallyは不要。 具体例を出すと、finallyのRFCでは例
PSR-0はなぜ0（≒最重要）なのか
Symfony勉強会で酔った勢いでPSRのステマをLT枠でしてきたのですが、参加者の半数以上がPSRを知っているというSymfony勉強会のレベルの高さに完全にやる気を失い、気のない話しかできなかったことをまずはお詫び申し上げます。 アレだとちょっと何が言いたかったのか意味不明ですので、改めて解説したいと思います。スライドはもう上げなくていいか。。 PSRとは PSRとはPHP-FIGっていう、色々なフレームワーク原作者同士の集まりみたいなところで策定されている「コーディング規約」です。標準だの何だの書いてありますが、要はコーディング規約ですよ。 ずっと公式サイトが無くてググラビリティが低いなクソッと思っていたら、いつの間にか公式サイトができていたようです。これで安心して「PSR公式サイトはここだよ！」と案内できますね PHP-FIG レベル分けがあって、今はPSR-0, PSR-1, P
PDOの真の力を開放する - PHPでデータベースを扱う(3)
ちょっと遅れましたが、シリーズの第３回です。前回までに論じた内容をふまえて、簡単な実装を示します。↓前回までの内容はこちら。 DAOの悪夢 - PHPでデータベースを扱う(1) - 泥のように ドメイン駆動設計という救世主 - PHPでデータベースを扱う(2) - 泥のように 題材 「記事にタグを設定できるブログ」みたいなシステムを考えてみます。ブログ記事を示すEntryテーブル、タグを表すTagテーブルの二つを用意しました。MySQL WorkbenchによるER図(鳥足記法)は以下になります。 1つのEntryに対して複数のTagがある、１対多の関係です。同じTagが複数のEntryに関連するため、多対多の関係と見なすこともできそうですが、タグ程度だとあまり意味がないので、これ以上のテーブル分割はやめておきます。 Entryテーブルの主キーがentryIdと冗長な名前をしているのは、自
PHPでXMLを生成するためのライブラリを公開しました
XMLを生成するためのライブラリ「XML_Builder」をOpenpearにて公開しています。1月ごろにはもう公開していたのですが、ブログに書いていなかったので、簡単な紹介を書いてみたいと思います。(4/1ですがエイプリルフール関係ない記事です） github pagesに簡単なドキュメントも置いています。 php-XML_Builder document https://github.com/hirak/php-XML_Builder インストール PHP PEAR形式のライブラリです。OpenpearなのでPEARコマンドで簡単です。 % pear channel-discover openpear.org % pear install openpear/XML_Builder 肝心のXMLを出力するにはDOMやXMLWriterが必要ですが、arrayを生成するだけのモードもあるた
PHP5.4時代のprivateメソッドテスト手法 #php5_4
PHP5.4 Advent Calendar 2011の7日目です。昨日は@madapajaさんの「PHP5.4+ で開発が行われている BEAR.Sunday フレームワークを動かしてみる」でした。 さてさて皆さん、ユニットテストしてますか？ PHPもテストのライブラリが充実してきており、カバレッジ100%に情熱を燃やしている方も多いことでしょう。 ユニットテストで困るのが、private/protectedメソッドです。外から呼べないので、普通の方法ではテストできません。(protectedは適当なダミーのサブクラスを作ってそこからテストできますが、ちょっと面倒です。) まあ当然です。外から呼べないようにprivateにしているので、簡単に呼べたら逆に困るわけです。しかしながら、privateメソッドも外から呼んでテストできた方が開発ははかどるでしょう。この記事ではPHPでprivat
規模別PHPUnitでのテストの書き方いろいろ - Architect Note
最近になってPHPUnitをちゃんと使ってユニットテストを書くようになってきたのですが、まだまだTipsが足りないと感じます。個人的に実践している書き方をいくつか並べてみます。 追記：最初、シェバングと書いていましたが、オプションを渡せる数が決まっていたりOSによっては動かなかったりとあまり便利でないことがわかりました。。phpunit.xmlを書いた方がいいかも。 ちょっとしたテスト → シェルスクリプト化する PHPUnitは高機能なのですが、いかんせん最初の障壁が高いと思います。とにかく気軽に書きたいなら、シェルスクリプトを作って単独ファイルで実行できるようにするといいです。 #!/bin/sh phpunit --colors *Test.php # ↑オプションを書き並べておく <?php class SampleTest extends PHPUnit_Framework_Te
extensionだけで書かれたPHPフレームワーク・Yafを試してみた
Yaf(Yet Another Framework)はextensionだけで書かれたPHPのWeb Application Frameworkです。peclをなんとなく眺めていて見つけました。フルスタックというわけではなく、コントローラーやディスパッチャの部分が主に提供されています。 Zend Frameworkの高速化記事でも書きましたが、フレームワークはライブラリをロードする部分にもっともコストがかかります。extensionで書かれている場合、このロードの時間が無視できるようになりますから、かなりの性能向上が期待できそうです。(もちろん処理自体が速くなることも期待できます) Yafのドキュメントはまだまだ充実していないようですが、MVCかつFrontController Patternを採用したアーキテクチャで、非常にZend Frameworkとよく似た構成になっています。なので
DOM APIとinnerHTMLは等価ではない
最近、徳丸本をじわじわ読んでいるのですが、DOM based XSSの話が書いてあったので、少し言及しておこうと思います。 徳丸本から引用 DOM based XSSと呼ばれるXSSがあります。これは、JavaScriptによりクライアント側で表示処理する箇所があり、そこに脆弱性がある場合のXSSです。 サンプル書いてみました。 <script> document.write(unescape(location.href)); </script> こいつを適当なファイル名で保存して、domxss.html#<script>alert("hello")<script>などのURLでアクセスするとalertが表示されるはずです。任意のスクリプトが実行可能な状態ってことですね。任意のスクリプトが実行可能ってことは、セッションクッキー盗み放題で、他人に成り済まして買い物できちゃったりするレベルです
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
