MVCの様な大きな機能分類ではなく、関数レベル?のデザインパターンについて。
PHPのフレームワークであるLaravelにて、FormFacadeやHtmlFacade等のFacadeがあるが、C++でも使われる事があり、Laravelではどのような時に使われるか？ (->ChatGPT)
### LaravelのFacadeとは？
Laravelにおける**Facade（ファサード）**は、アプリケーションのサービスコンテナに登録されているサービス（クラス）への簡単なインターフェースを提供するための仕組みです。
具体的には、静的メソッドのように見えますが、背後ではサービスコンテナを介してインスタンスが管理されています。
#### 例: FormFacade
\“`php
\{!! Form::open([‘url’ => ‘/submit’]) !!}
\ {!! Form::text(‘name’) !!}
\ {!! Form::submit(‘Send’) !!}
\{!! Form::close() !!}
このコードは`FormFacade`を使用しており、静的な呼び出しのように見えますが、実際には`FormBuilder`クラスを介しています。
### LaravelでFacadeが使われる目的
1. **シンプルで直感的なインターフェース**
\ – 複雑なクラスやインスタンス化を気にせず、簡潔なコードが書けます。
\ – 例：`Form::text(‘name’)`は`app(‘form’)->text(‘name’)`を簡略化した形。
2. **依存性注入を隠蔽**
\ – サービスコンテナがインスタンスを管理するため、明示的な依存性注入が不要。
\ – 例：コントローラやクラスで直接`FormBuilder`を注入する必要がなくなります。
3. **静的メソッド風の記述**
\ – 見た目が静的呼び出しのように簡潔で、実際には動的なインスタンスを利用しているため、テストや拡張が容易。
4. **可読性の向上**
\ – 特にビューやテンプレートで利用する場合、より直感的で読みやすいコードになります。
### C++におけるFacadeとの関連性
C++にも**Facadeパターン**というデザインパターンがありますが、LaravelのFacadeとは少し異なります。
#### **C++のFacadeパターンの特徴**
\- システムの複雑な内部構造を隠し、簡単なインターフェースを提供するデザインパターン。
\- 主に**オブジェクト指向の設計パターン**として利用され、複数のクラスや機能を1つのインターフェースにまとめる。
#### **LaravelのFacadeとの違い**
\- **LaravelのFacade**は「サービスコンテナからインスタンスを取得して簡潔に使う仕組み」に重点を置いています。
\- **C++のFacade**は「複雑な処理やライブラリを隠蔽し、統一されたシンプルなインターフェースを提供する」ことが主目的。
### LaravelでFacadeを使うべき場面
LaravelのFacadeは便利ですが、すべての場面で使うべきではありません。以下のような場合に適しています：
1. **簡単な操作を頻繁に行う場合**
\ – 例：フォーム生成やHTMLヘルパー（`FormFacade`や`HtmlFacade`）をビューで使用する場合。
2. **静的風のシンプルなコードが求められる場合**
\ – 複雑なインスタンス化や依存性注入が不要で、可読性が重要な場合。
3. **複数の場所で繰り返し同じサービスを使用する場合**
\ – 例：キャッシュ操作（`Cache`）、ログ操作（`Log`）など。
4. **サービスの動的な切り替えが不要な場合**
\ – Facadeはサービスコンテナを介して特定のサービスを利用するため、動的な挙動が少ないコードに適しています。
### Facadeのデメリットと注意点
\- **依存関係が不透明になる**
\ – どのクラスが実際に利用されているかがコードからは分かりにくい。
\ – 解決策：依存性注入（DI）を使用して明示的に管理。
\- **テストが難しくなる**
\ – Facadeを使うとモックを作るのがやや面倒。
\ – 解決策：Facadeの代わりに、サービスを直接依存性注入する方法を採用。
\- **スコープの曖昧さ**
\ – 静的風の記述が、動的なサービスの利用に基づいているため、初心者には理解が難しい場合がある。
### まとめ
\- LaravelのFacadeは、C++のFacadeパターンと目的や実装の詳細が異なりますが、どちらも「複雑さを隠してシンプルなインターフェースを提供する」ことにフォーカスしています。
\- Laravelでは、頻繁に利用する簡単なサービス（例えばフォーム生成、ログ、キャッシュなど）でFacadeを利用するとコードがシンプルになり効果的です。
\- ただし、依存関係やテストの観点から、適材適所で使用を検討することが重要です。
Facade以外にLaravelではどのようなデザインパターンが使われているか？
Laravelはモダンなフレームワークであり、多くの設計原則やデザインパターンを取り入れています。以下はLaravelで利用される主なデザインパターンの一覧とその役割です。
## 1. **シングルトンパターン (Singleton Pattern)**
### 概要
\- Laravelでは、特定のサービスのインスタンスが1回だけ生成され、アプリケーション全体で共有されます。
\- サービスコンテナ（Service Container）を利用したインスタンス管理において使用されています。
### 使用例
\- サービスプロバイダ内で`singleton()`メソッドを使って登録されたクラス：
\“`php
\$this->app->singleton(‘CustomService’, function ($app) {
\ return new CustomService();
\});
## 2. **ストラテジーパターン (Strategy Pattern)**
### 概要
\- 複数のアルゴリズムを動的に切り替える場合に使用されます。
\- Laravelでは、認証や通知の仕組みでよく使われています。
### 使用例
\- **認証ガード**の切り替え：
\“`php
\Auth::guard(‘web’)->attempt($credentials);
\Auth::guard(‘api’)->attempt($credentials);
## 3. **リポジトリパターン (Repository Pattern)**
### 概要
\- データアクセスロジックをビジネスロジックから分離するために使用されます。
\- クエリの詳細を隠蔽し、モジュール性を向上させます。
### 使用例
\- データベースクエリをリポジトリクラスに分離することで、コードの再利用性が向上：
\“`php
\class UserRepository {
\ public function findByEmail($email) {
\ return User::where(‘email’, $email)->first();
\ }
\}
## 4. **デコレータパターン (Decorator Pattern)**
### 概要
\- 基本クラスの機能を拡張するために使用されます。
\- Laravelでは、ミドルウェアがこのパターンに近い動作をします。
### 使用例
\- **HTTPリクエストに対するミドルウェアのチェーン**：
\“`php
\Route::middleware([‘auth’, ‘verified’])->group(function () {
\ Route::get(‘/dashboard’, [DashboardController::class, ‘index’]);
\});
## 5. **プロバイダパターン (Provider Pattern)**
### 概要
\- 必要なリソースを遅延的に初期化するために使用されます。
\- Laravelのサービスプロバイダはこのパターンを実現しています。
### 使用例
\- サービスプロバイダを用いたサービスの登録：
\“`php
\class AppServiceProvider extends ServiceProvider {
\ public function register() {
\ $this->app->bind(‘CustomService’, function ($app) {
\ return new CustomService();
\ });
\ }
\}
## 6. **ファクトリパターン (Factory Pattern)**
### 概要
\- オブジェクト生成を簡略化するために使用されます。
\- LaravelのEloquentモデルで利用されています。
### 使用例
\- **Eloquentモデルファクトリ**：
\“`php
\$users = User::factory()->count(10)->create();
## 7. **オブザーバーパターン (Observer Pattern)**
### 概要
\- 特定のイベントに対して複数のリスナーを登録し、イベントが発生したときに通知を行う。
\- Eloquentモデルで利用されます。
### 使用例
\- **Eloquentモデルのイベント**：
\“`php
\class UserObserver {
\ public function created(User $user) {
\ Log::info(“User created: ” . $user->id);
\ }
\}
\User::observe(UserObserver::class);
## 8. **ビルダーパターン (Builder Pattern)**
### 概要
\- 複雑なオブジェクトを段階的に構築する際に使用されます。
\- Laravelのクエリビルダやフォームビルダで利用されています。
### 使用例
\- **クエリビルダ**：
\“`php
\$users = DB::table(‘users’)
\ ->where(‘active’, 1)
\ ->orderBy(‘created_at’, ‘desc’)
\ ->get();
## 9. **コマンドパターン (Command Pattern)**
### 概要
\- アクションをオブジェクトとしてカプセル化し、アクションをキューイングや実行する方法を提供します。
\- Laravelのキューやコンソールコマンドで利用されています。
### 使用例
\- **Artisanコマンド**：
\“`php
\class SendEmails extends Command {
\ protected $signature = ‘emails:send’;
\ public function handle() {
\ // メール送信ロジック
\ }
\}
## 10. **チェーンオブリスポンシビリティパターン (Chain of Responsibility Pattern)**
### 概要
\- リクエストを処理できる複数のハンドラーが連続して処理を試みる仕組み。
\- Laravelのミドルウェアやパイプラインで実装されています。
### 使用例
\- **HTTPリクエストのミドルウェアチェーン**：
\“`php
\public function handle($request, Closure $next) {
\ if ($request->user()->isBanned()) {
\ return response(‘You are banned.’, 403);
\ }
\ return $next($request);
\}
## まとめ
Laravelは以下のような設計パターンを多用しています：
\- シングルトン、ストラテジー、リポジトリ
\- デコレータ、プロバイダ、ファクトリ
\- オブザーバー、ビルダー、コマンド、チェーンオブリスポンシビリティ
これらのデザインパターンは、コードの再利用性や保守性を高め、開発者が直感的にフレームワークを利用できるよう設計されています。Laravelの利用者は、これらのパターンを理解することで、フレームワークの内部構造や拡張方法について深く学べるでしょう。
上の説明に出てきた、サービスコンテナとは何か？
Laravelの**サービスコンテナ**は、**依存性の解決と管理**を行う中心的な仕組みです。具体的には、クラスやサービス（オブジェクト）のインスタンス化を効率的かつ柔軟に行う仕組みで、**依存性注入 (Dependency Injection)** をサポートするために使用されます。
## **サービスコンテナの役割**
1. **依存関係の管理**
\ – クラスの依存関係（例: クラスが別のクラスや設定値を必要とする場合）を自動的に解決します。
\ – これにより、手動でオブジェクトをインスタンス化する手間が省けます。
2. **結合度の低減**
\ – クラス同士が直接依存しないように設計できます。
\ – コンストラクタやメソッドに必要な依存オブジェクトを動的に注入できます。
3. **柔軟な設定**
\ – サービスコンテナを使ってインスタンスやクラスの解決方法をカスタマイズできます。
\ – シングルトンや動的な依存注入なども簡単に実現可能です。
## **仕組みの基本**
サービスコンテナは**クラスとその解決方法（バインディング）**を登録し、必要に応じてそのクラスのインスタンスを生成します。
### **サービスコンテナの利用例**
#### 1. **自動解決**
Laravelはサービスコンテナを介して、自動的にクラスをインスタンス化します。
\“`php
\class Service {
\ public function process() {
\ return “Service processing…”;
\ }
\}
\class Controller {
\ protected $service;
\ // コンストラクタで依存するサービスを受け取る
\ public function __construct(Service $service) {
\ $this->service = $service;
\ }
\ public function handle() {
\ return $this->service->process();
\ }
\}
// コントローラをインスタンス化する際、Laravelは自動的にServiceクラスを注入する
\$controller = app(Controller::class);
\echo $controller->handle(); // “Service processing…”
#### 2. **バインディング**
サービスコンテナにクラスやインスタンスを登録（バインディング）することができます。
##### **基本的なバインディング**
\“`php
\app()->bind(‘example’, function() {
\ return new ExampleService();
\});
// 解決
\$example = app(‘example’);
##### **シングルトンのバインディング**
1回だけインスタンス化し、同じインスタンスを共有する場合に使用します。
\“`php
\app()->singleton(‘singleton_example’, function() {
\ return new SingletonService();
\});
// 常に同じインスタンスが返される
\$instance1 = app(‘singleton_example’);
\$instance2 = app(‘singleton_example’);
\var_dump($instance1 === $instance2); // true
#### 3. **インターフェースの実装クラスを指定**
サービスコンテナは、インターフェースに対してどの具象クラスを利用するかを設定できます。
\“`php
\interface PaymentGateway {
\ public function charge($amount);
\}
\class StripePaymentGateway implements PaymentGateway {
\ public function charge($amount) {
\ return “Charged $amount via Stripe.”;
\ }
\}
// インターフェースと具象クラスをバインディング
\app()->bind(PaymentGateway::class, StripePaymentGateway::class);
// 自動的にStripePaymentGatewayがインジェクトされる
\$payment = app(PaymentGateway::class);
\echo $payment->charge(100); // “Charged 100 via Stripe.”
### **利用箇所**
Laravelのサービスコンテナは、フレームワーク全体で広く利用されています。以下は主な利用箇所です：
1. **コントローラ**
\ – 依存するサービスをコンストラクタで自動的に解決。
2. **ミドルウェア**
\ – 必要なサービスを注入してリクエスト処理をカスタマイズ。
3. **イベント/リスナー**
\ – 登録したイベントリスナーを自動的に解決。
4. **ジョブ/キュー**
\ – 必要なクラスやサービスをジョブ内で注入可能。
5. **カスタムサービス**
\ – 独自のクラスをサービスプロバイダでバインディングして利用。
### **サービスプロバイダとの関係**
\- サービスプロバイダは、サービスコンテナに依存関係やサービスをバインディングするためのクラスです。
\- Laravelでは`AppServiceProvider`などが標準で提供されています。
\- カスタムサービスを登録する場合は、以下のように`register()`メソッドを利用します：
\“`php
\class AppServiceProvider extends ServiceProvider {
\ public function register() {
\ $this->app->bind(‘CustomService’, function ($app) {
\ return new CustomService();
\ });
\ }
\}
### **サービスコンテナのメリット**
1. **テスト容易性**
\ – サービスコンテナを使えば、モック（Mock）を簡単に注入できるため、ユニットテストが容易になります。
2. **柔軟性**
\ – インターフェースと実装を切り替えることが簡単。
3. **コードの簡潔性**
\ – 複雑な依存関係を意識せず、必要なクラスを使える。
Laravelのサービスコンテナはフレームワークの基盤として、アプリケーション全体で非常に重要な役割を果たしています。その柔軟性と強力な機能により、依存関係をシンプルかつ直感的に管理できるのが特徴です。
サービスコンテナとは、C++でいうFactoryクラスの様なものか？
Laravelの**サービスコンテナ**は、C++でいう**Factoryパターン**に似ている部分がありますが、完全に同じではありません。それぞれの目的や役割には違いがあり、LaravelのサービスコンテナはFactoryパターンよりも広範囲で柔軟に機能します。
## **共通点: Factoryクラスとの類似点**
\- **依存関係の隠蔽**
Factoryクラスは、オブジェクトの生成を一元化して依存関係を隠蔽します。サービスコンテナも、オブジェクトを生成して管理するため、依存関係を明示的に扱わなくてもよいという共通点があります。
\- **柔軟性**
Factoryクラスも特定の条件に基づいて異なるオブジェクトを生成できます。Laravelのサービスコンテナも同様に、インターフェースに基づいて実装を解決したり、カスタムのインスタンス生成ロジックを定義できます。
例 (C++のFactoryパターン):
\“`cpp
\class Product {
\public:
\ virtual void use() = 0;
\};
\class ConcreteProductA : public Product {
\public:
\ void use() override {
\ std::cout << “Using Product A” << std::endl;
\ }
\};
\class ConcreteProductB : public Product {
\public:
\ void use() override {
\ std::cout << “Using Product B” << std::endl;
\ }
\};
\class ProductFactory {
\public:
\ static Product* createProduct(const std::string& type) {
\ if (type == “A”) {
\ return new ConcreteProductA();
\ } else if (type == “B”) {
\ return new ConcreteProductB();
\ }
\ return nullptr;
\ }
\};
// 使用例
\Product* product = ProductFactory::createProduct(“A”);
\product->use(); // “Using Product A”
\delete product;
## **違い: サービスコンテナが提供する追加機能**
LaravelのサービスコンテナはFactoryパターンよりも広範囲の機能を提供します。
### **1. 自動依存性注入**
C++のFactoryクラスでは、必要な依存関係（引数など）を明示的に指定する必要がありますが、Laravelのサービスコンテナはクラスの依存関係を自動的に解決します。
#### Laravelの例:
\“`php
\class Database {
\ public function connect() {
\ return “Connected to database.”;
\ }
\}
\class UserService {
\ protected $database;
\ public function __construct(Database $database) {
\ $this->database = $database;
\ }
\ public function fetchUsers() {
\ return $this->database->connect() . ” Fetched users.”;
\ }
\}
\$userService = app(UserService::class);
\echo $userService->fetchUsers();
// “Connected to database. Fetched users.”
C++の場合、自動的に依存を解決する仕組みは標準にはないため、Factoryクラスや他の方法で依存性を注入する必要があります。
### **2. シングルトンの管理**
Laravelのサービスコンテナでは、同じインスタンスを再利用する「シングルトン」の管理が簡単です。C++のFactoryクラスでは、これを実現するには明示的にシングルトンパターンを実装する必要があります。
#### Laravelのシングルトン例:
\“`php
\app()->singleton(‘Logger’, function () {
\ return new LoggerService();
\});
\$logger1 = app(‘Logger’);
\$logger2 = app(‘Logger’);
\var_dump($logger1 === $logger2); // true
#### C++でシングルトンを実現する例:
\“`cpp
\class Logger {
\private:
\ static Logger* instance;
\ Logger() {} // コンストラクタを非公開にする
\public:
\ static Logger* getInstance() {
\ if (!instance) {
\ instance = new Logger();
\ }
\ return instance;
\ }
\};
\Logger* Logger::instance = nullptr;
// 使用例
\Logger* logger1 = Logger::getInstance();
\Logger* logger2 = Logger::getInstance();
\std::cout << (logger1 == logger2); // 1 (true)
### **3. インターフェースと実装の切り替え**
Laravelのサービスコンテナでは、インターフェースと具体的な実装を簡単に切り替えられます。これはFactoryパターンにも似ていますが、サービスコンテナはさらに強力です。
#### Laravelの例:
\“`php
\interface PaymentGateway {
\ public function process($amount);
\}
\class StripePaymentGateway implements PaymentGateway {
\ public function process($amount) {
\ return “Processed $amount via Stripe.”;
\ }
\}
\class PaypalPaymentGateway implements PaymentGateway {
\ public function process($amount) {
\ return “Processed $amount via Paypal.”;
\ }
\}
// サービスコンテナにバインド
\app()->bind(PaymentGateway::class, StripePaymentGateway::class);
// Stripeを使用
\$gateway = app(PaymentGateway::class);
\echo $gateway->process(100); // “Processed 100 via Stripe.”
// 実装を変更する場合
\app()->bind(PaymentGateway::class, PaypalPaymentGateway::class);
// Paypalを使用
\$gateway = app(PaymentGateway::class);
\echo $gateway->process(100); // “Processed 100 via Paypal.”
## **結論**
Laravelのサービスコンテナは、C++のFactoryパターンに似た「オブジェクト生成の一元化」という機能を提供していますが、それに加えて次のような機能を備えています：
1. **自動依存性注入** – C++には標準でない。
2. **シングルトン管理の簡便さ** – 明示的な実装が不要。
3. **インターフェースと実装の柔軟な切り替え**。
C++でFactoryパターンに依存性注入やシングルトンの機能を加えた形で使用したい場合は、Boost DIや他のライブラリを利用することも検討できますが、Laravelのサービスコンテナはこれらの機能をフレームワークの一部としてシームレスに提供しています。
C++のFactoryパターンとLarabelのFactoryパターンは同じか？
C++のFactoryパターンとLaravelのFactoryパターンは名前こそ同じ「Factoryパターン」ですが、その目的や実装の細部、使われる状況に違いがあります。以下で両者を比較しながら解説します。
## **C++のFactoryパターン**
### **目的**
\- **オブジェクト生成を一元化**し、クライアントコードが具体的なクラスに依存しないようにする。
\- オブジェクト生成のロジックを簡潔に保つ。
### **特徴**
\- 典型的には**Factory Methodパターン**や**Abstract Factoryパターン**として使用される。
\- 各オブジェクトの生成が明示的に定義される。
\- 静的な型付けで、オブジェクトの型がコンパイル時に決定する。
### **使用例**
\“`cpp
\class Product {
\public:
\ virtual void use() = 0;
\};
\class ConcreteProductA : public Product {
\public:
\ void use() override {
\ std::cout << “Using Product A” << std::endl;
\ }
\};
\class ConcreteProductB : public Product {
\public:
\ void use() override {
\ std::cout << “Using Product B” << std::endl;
\ }
\};
\class ProductFactory {
\public:
\ static Product* createProduct(const std::string& type) {
\ if (type == “A”) {
\ return new ConcreteProductA();
\ } else if (type == “B”) {
\ return new ConcreteProductB();
\ }
\ return nullptr;
\ }
\};
// 使用例
\Product* product = ProductFactory::createProduct(“A”);
\product->use(); // “Using Product A”
\delete product;
### **用途**
\- ゲーム開発やシステム設計で、複数のオブジェクトタイプを動的に切り替える場合。
\- GUIコンポーネントや、異なる環境で動作するシステムの抽象化。
## **LaravelのFactoryパターン**
### **目的**
\- **データベースのテストデータ生成**を効率化する。
\- テストやシーディングで使用する、オブジェクトのインスタンス（特にデータベースモデル）の作成を簡素化。
### **特徴**
\- データベースのEloquentモデルに対応しており、**仮のデータを簡単に生成**する仕組み。
\- Fakerライブラリを活用して、ランダムなデータを生成する。
\- Laravel特有の**サービスコンテナ**や依存性注入と連携する。
### **使用例**
1. **Factoryの作成**
\“`php
// ターミナルで実行してFactoryファイルを作成
\php artisan make:factory UserFactory
2. **Factoryの定義**
\“`php
// database/factories/UserFactory.php
\use App\Models\User;
\use Illuminate\Database\Eloquent\Factories\Factory;
\class UserFactory extends Factory {
\ protected $model = User::class;
\ public function definition() {
\ return [
\ ‘name’ => $this->faker->name,
\ ‘email’ => $this->faker->unique()->safeEmail,
\ ‘password’ => bcrypt(‘password’),
\ ];
\ }
\}
3. **Factoryの使用**
\“`php
// テストやシーディングで利用
\User::factory()->count(10)->create(); // 10人分の仮データを作成
### **用途**
\- ユニットテストや統合テストで、実際のデータベースを使用せずに仮のデータを挿入。
\- シーディング（初期データ投入）やデモ環境用のデータ作成。
## **比較**
| 項目 | C++のFactoryパターン | LaravelのFactoryパターン |
|——————————–|————————————————————-|————————————————–|
| **目的** | クラスインスタンス生成のロジックを一元化 | テストデータや仮データの簡単な生成 |
| **適用範囲** | 任意のクラス、オブジェクト | Eloquentモデル（データベース） |
| **生成方法** | 静的メソッドやインターフェースを使用したクラス生成 | Laravelのファイル構造とFakerを使用したデータ生成 |
| **柔軟性** | 動的なクラス切り替え、複雑な生成ロジック | データベースモデルのデータ生成に特化 |
| **ランタイム動作** | 静的型付けでコンパイル時に決定 | 動的型付けでランタイムに決定 |
| **代表的な使用例** | ゲームオブジェクトやGUI部品の生成 | テストやシーディング用の仮データ生成 |
## **結論**
C++のFactoryパターンとLaravelのFactoryパターンは、いずれも**オブジェクト生成の効率化**を目的としていますが、適用範囲や生成対象が異なります。
\- **C++のFactoryパターン**は、汎用的なオブジェクト生成を扱い、設計パターンとして幅広く使われます。
\- **LaravelのFactoryパターン**は、データベーステストや仮データ生成に特化した仕組みであり、Eloquentモデルと密接に関連しています。
どちらも「Factory」と名付けられていますが、それぞれのフレームワークや言語に特化した役割を持つため、直接的な比較は難しいですが、目的に応じてそれぞれの利点を活かせるように設計されています。
参考書籍：
PHPフレームワーク Laravel入門 第2版 2019.12
https://www.shuwasystem.co.jp/book/9784798060996.html
(サービスコンテナの事が書いてあった。こういうのは本を読んだ方が分かり易い)
サービスとビューコンポーザ、サービスプロバイダ
テンプレートというものの役割を考えるなら、そこにビジネスロジックを含めるのは感心しません。
といって、コントローラ側でビューのための処理を記述していくのも何か違う気がするかもしれません。
「ビューにビジネスロジックをもたせたい場合は、どこに処理を置くべきなのか？」というのは、MVC
アーキテクチャ登場の当初からある、非常に悩ましい問題です。
(60nouenのLaravel化では特に何も考えずにコントローラに入れとったわ)
PHPフレームワーク Laravel実践開発 2019.07
https://www.shuwasystem.co.jp/book/9784798059075.html
(シングルトンやファサードの事が書いてある)
参考情報：
Webアプリの設計パターンを調べた
https://seesaawiki.jp/lifewithslackzaurus_15_0/d/Web%a5%a2%a5%d7%a5%ea%a4%ce%c0%df%b7%d7%a5%d1%a5%bf%a1%bc%a5%f3%a4%f2%c4%b4%a4%d9%a4%bf
(パターンと言ってもMVCの様な大きな機能分類)