PHPにおける例外クラスの設計考察
この記事はPHP Advent Calendar 2017の2日目です。 ここ最近、本業のほうが死ぬほど忙しく、すっかりブログを書いていなかった@Hirakuです。 だいぶ前のことですが、今年のPHPカンファレンス福岡で例外の話をしてきました。 この時の発表では例外に関する概要が主だったので、例外クラスそのものの設計について補足を書いてみることにします。 例外のある世界観 PHP7ではいくつかのエラーが例外と同じ挙動を示すようになり、エラーではなく例外機構を使う言語に様変わりしました。 例外というのは、かなり侵略性の高い概念であり、例外のある世界では以下の前提に立つことが暗黙のうちに強要されます。 どこでも例外が発生する可能性がある 例外によって中断されても、ソフトウェアが不適切な状態にならないように保証するのは各プログラマの責任(例外安全) たとえば、以下の関数で例外が発生する可能性があ
PDOの真の力を開放する - PHPでデータベースを扱う(3)
ちょっと遅れましたが、シリーズの第３回です。前回までに論じた内容をふまえて、簡単な実装を示します。↓前回までの内容はこちら。 DAOの悪夢 - PHPでデータベースを扱う(1) - 泥のように ドメイン駆動設計という救世主 - PHPでデータベースを扱う(2) - 泥のように 題材 「記事にタグを設定できるブログ」みたいなシステムを考えてみます。ブログ記事を示すEntryテーブル、タグを表すTagテーブルの二つを用意しました。MySQL WorkbenchによるER図(鳥足記法)は以下になります。 1つのEntryに対して複数のTagがある、１対多の関係です。同じTagが複数のEntryに関連するため、多対多の関係と見なすこともできそうですが、タグ程度だとあまり意味がないので、これ以上のテーブル分割はやめておきます。 Entryテーブルの主キーがentryIdと冗長な名前をしているのは、自
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
DCI in PHPについて考えてみる
DCI(Data, Context and Interactions)というキーワードがRuby界で流行っているとか。 DCIアーキテクチャ - Trygve Reenskaug and James O. Coplien - Digital Romanticism DCIアーキテクチャについて語ってみるよ - uehaj's blog まだよく消化できていないのですが(そもそもMVCだって理解できた気がしない)、PHPではどう実装すればいいかを考えてみました。 DCI概略 斜め読みしたところ、MVCのModelが肥大化しがちなところなので、じゃあModelをData、Context、Interactionに3層分割して実装すればすっきりしますよ、という概念だと読めました。実装によってはContextではなくUseCase、InteractionではなくRoleと書いていることもあるみたい。
規模別PHPUnitでのテストの書き方いろいろ - Architect Note
最近になってPHPUnitをちゃんと使ってユニットテストを書くようになってきたのですが、まだまだTipsが足りないと感じます。個人的に実践している書き方をいくつか並べてみます。 追記：最初、シェバングと書いていましたが、オプションを渡せる数が決まっていたりOSによっては動かなかったりとあまり便利でないことがわかりました。。phpunit.xmlを書いた方がいいかも。 ちょっとしたテスト → シェルスクリプト化する PHPUnitは高機能なのですが、いかんせん最初の障壁が高いと思います。とにかく気軽に書きたいなら、シェルスクリプトを作って単独ファイルで実行できるようにするといいです。 #!/bin/sh phpunit --colors *Test.php # ↑オプションを書き並べておく <?php class SampleTest extends PHPUnit_Framework_Te
trait時代のライブラリ設計を予想してみる #php5_4
この記事はPHP5.4 Advent Calendar 2011の23日分です。 trait自体はすでに10日目の@tpyamamotoさんによるTRAITでデザインパターン再考でも取り上げられていますが、目玉機能なのでもう一回ネタにしちゃいます＞＜ おさらい：traitとは 相変わらず公式マニュアルが充実しまくっているのでそちらを見た方がいいのですが、抜粋するとこんな感じ。 PHP5.4の目玉機能 多重継承を安全に行えるよう導入された概念 traitはプロパティ・メソッドを持てる traitは定数を持てない trait自体はインスタンス化できない classを継承してtraitを作ることはできない interfaceを実装してtraitを作ることはできない traitを継承してtraitを作ることが可能 classは複数のtraitを継承して実装を再利用できる traitはclassでは
PHPにfinallyはないけどデストラクタがあるよ
PHP finallyで検索すると、「PHPにはfinallyがない。欠陥言語だ！」という主張の記事がたくさんヒットします。これに対してPHPを擁護している記事があまりなさそうなので、PHPを擁護してみることにします。 finallyとは何か まずはおさらい。 try～catch～finallyは例外処理を行うための構文です。tryで例外が発生するかもしれない処理を書き、catchで例外が発生したときの対処を書き、finallyでは例外が起きても起きなくても実行される処理を書きます。…というのが初歩的な説明ですが、このfinallyの解説は十分ではありません。 finally節は、途中でどんなことが起ころうとも必ず実行されるというかなり特殊な性質を持っています。たとえば以下のJavaScriptのコードはいずれも「try」「finally」と表示します。tryの中でgoto相当の構文を実行
即時関数(function(){ ... })()の別の書き方いろいろ - 泥のように
JavaScriptでよく使われるコード片に即時関数というものがあります。無名関数を宣言して即実行することで、ブロックスコープの存在しないJavaScriptにおいて擬似的にブロックスコープを再現します。 var a = "global"; (function(){ var a = "local"; alert(a); //local })(); alert(a); //global 一番有名なのはこの(function(){ ... })()の形式なのですが、なぜfunctionの外側にカッコが必要なのか不思議に思ったことはないでしょうか？ ためしにfunction(){ ... }()と書いてみると、Syntax Errorが発生します。 なぜfunction(){ ... }()はSyntax Errorなのか JavaScriptにはfunction文とfunction式があって、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PSR-3 Logger Interfaceの話