Skip to content
KITO, takayuki edited this page Aug 13, 2026 · 2 revisions

Welcome to the Woof Wiki!

Woof (Well Object-Oriented Framework) の公式ドキュメントへようこそ。

Woof は、「Web アプリケーションを、HTTP リクエストを入力・HTTP レスポンスを出力とする『純粋関数』として表現する」 という設計ポリシーを極限まで追求した、非常に軽量で堅牢な PHP 用 Web フレームワークです。

この Wiki では、Woof のユニークな設計思想の解説から、実際のアプリケーション開発におけるベストプラクティス、そして最大の強みである高いテスタビリティ (テスト容易性) の活かし方までを体系的に解説します。


ドキュメント目次

Woof の世界へ一歩を踏み出しましょう。

  • Woof の設計目的: なぜ「純粋関数」にこだわるのか、そのアーキテクチャ的なメリットを解説します。
  • クイックスタート: 最初の Hello, Woof! を動かすための最小限のフロントコントローラー構築手順。

Woof の美しく安全なデータフローを支える核心的な仕組み。

  • 副作用の隔離と Environment: 時間、乱数、外部ストレージなどの外的要因を閉じ込めるサンドボックス。
  • 状態の不変性 (Immutable): 予期せぬ書き換えを防ぎ、ロジックの見通しを良くする Builder パターン。
  • 開発を加速する Operator クラス: 複雑なレスポンス構築や Cookie・セッション操作をスマートなメソッドチェーンで記述する手法。

HTTP の入出力をオブジェクトとしてエレガントに扱う方法。

  • ルーティングと Controller: 単純なクロージャから始めるルーティングと、美しい 404 (Not Found) ハンドリング。
  • 高度な HTTP ヘッダー解析: q値を解釈する QualityValues や、日付を扱う HttpDate による堅牢なヘッダー処理。
  • Response と View: TextBodyJsonBodyFileBody などの使い分けと、描画処理の抽象化。

動的なデータを、安全かつ予測可能な形でコントロールする。

  • 明示的なセッション永続化: 「変更は明示的に saveSession() を呼ばない限り保存されない」安全なロールバック設計。
  • ビューキャッシュと HTTP キャッシュ (VariantStorage): デフォルト無効の安全設計と、 ETag / Last-Modified を用いた 304 Not Modified の自動化。

テストを困難にするシステム関数や設定値をフレームワークから切り離す。

  • 時間 (Clock) と乱数 (Random): time()mt_rand() を使わず、プログラムの再現性を担保する手法。
  • 設定ファイルの管理 (Config): JSON や INI ファイルからの型安全な読み込みと、内部コンポーネントのデフォルト値。

ビジネスロジックを汚さない、エレガントな多言語化対応。

  • ロケール解析 (Locale): HTTP ヘッダーから Config までの優先順位に基づく自動フォールバックチェーン。
  • リソースの自動探索 (LocalizedResources): JSON 設定や HTML テンプレートを言語ごとに自動で出し分ける実践パターンと、推奨ディレクトリ構成。

Woof が最も得意とする、外部モックライブラリを必要としない単体テストの極意。

  • 時間と乱数のモック化: FixedClockArrayRandom を用いた、決定論的 (確実) なテストコードの書き方。
  • View の純粋な単体テスト: 外部状態に依存せず「入力と想定結果が 1:1」になる、網羅的でシンプルなテスト。
  • Controller のテスト: HTML のパースは不要。 ViewBody から View を取り出して内部状態を直接検証するスマートな手法。

実装のゴールデンルール (迷ったらここをチェック!)

Woof を使った開発で最も重要なのは 「View と Controller の明確な境界線」 です。

  1. View には「純粋な値 (不変な状態)」だけを渡す
    View の中に、背後でデータベース通信が発生するオブジェクト (一般的な ORM クラスなど) を持ち込んで参照してはいけません。現在時刻の文字列、乱数の結果、ユーザー名や画像のパス、あるいはそれらをまとめた完全に不変な専用クラスのインスタンスといった「純粋なデータ」のみを渡します。これにより、キャッシュが 100% 安全に働き、テストの入力と出力も 1:1 で美しく定義できるようになります。
  2. Controller のテストで画面 (DOM) を解析しない
    Controller の役割は「適切な View と状態をレスポンスにセットすること」です。テストコードでは、出力された HTML 文字列を解析するのではなく、レスポンスの ViewBody から View オブジェクトを取り出して、その中に正しい状態 (メンバ変数など) がセットされているかを検証してください。UI の変更に引っ張られない、頑丈なテストになります。

主要なインターフェース・クラス早見表

役割 インターフェース / 基底クラス デフォルトの実装クラス 目的
副作用の集約 Environment WebEnvironment / DefaultEnvironment アプリケーションのすべての実行コンテキスト (Config / Resources / DataStorage) を保持
時間の取得 Clock DefaultClock (テスト用: FixedClock) システム時刻 time() の抽象化
乱数の生成 Random DefaultRandom (テスト用: ArrayRandom) 組み込み乱数関数の抽象化
静的リソースの取得 Resources FileResources (多言語対応: LocalizedResources) HTML テンプレートや JSON 設定ファイルなどの読み込み専用データアクセス
動的データの保存 DataStorage FileDataStorage ログや一時ファイル、キャッシュファイルなど、実行中に変化するデータの入出力

Clone this wiki locally