PHP の PSR-0 と PSR-4 で autoloader の違いと名前空間の基礎

この 1 年（2019 年）で更新・作成された Qiita 記事を[「php "psr-4" "psr-0" 違い」でググって](https://www.google.com/search?q=site:qiita.com+php+"psr-4"+"psr-0"+違い&tbs=qdr:y)もタイトルから判断できる記事がヒットしなかったので、自分のググラビリティとして。

- PSRとは[^psr]
- オートローダーとは[^autoloader]
- `composer`とは（<a href="https://qiita.com/KEINOS/items/86a16b06af6e936a1841#composer-%E3%81%AE%E5%9F%BA%E7%A4%8E%E7%9F%A5%E8%AD%98" target="_blank">composer の基礎知識</a>）
- [名前空間とは](#%E5%90%8D%E5%89%8D%E7%A9%BA%E9%96%93%E3%81%A8%E3%81%AF)

[^psr]: **PSR とは** `PHP Standards Recommendations` の略で、雑に訳すと「『PHP のスタンダード』のオススメ集」です。詳しく言うと、PHP の有志のコミュニティ「[PHP-FIG](https://www.php-fig.org/)」によって[制定された](https://www.php-fig.org/psr/)、**スタンダードの推奨ガイドライン**です。<br><br>「スタンダード」とは日本語で「標準」「基準」「規格」「定番」などの意味を持ちますが、ここでは「標準」の意味合いで使われます。「標準」とは 2 者以上で何かを行う際に「ベースとなる考え方や方法を取り決めた・定めたもの」です。「標準」から大きく外れないことで足並みを揃える目的があります。<br><br>この時、ゼロから考えて標準を決めるより「あるある」な「標準」をまとめたものがあると便利です。それらをまとめようというのが「PHP-FIG」です。<br><br>「PHP-FIG」は `PHP Framework Interoperation Group` の略で「PHP フレームワークの相互利用支援団体」です。この団体の主な目的は、用途が同じなら異なるフレームワークでも同じ使い方が出来るように[プロトコル](https://qiita.com/KEINOS/items/cb7f629268b90ef6493d)を制定することです。<br><br>日本産業規格の [JIS](https://ja.wikipedia.org/wiki/%E6%97%A5%E6%9C%AC%E7%94%A3%E6%A5%AD%E8%A6%8F%E6%A0%BC)、国際標準化機構の [ISO](https://ja.wikipedia.org/wiki/%E5%9B%BD%E9%9A%9B%E6%A8%99%E6%BA%96%E5%8C%96%E6%A9%9F%E6%A7%8B)、各種インターネット技術の標準化団体の [W3C](https://ja.wikipedia.org/wiki/World_Wide_Web_Consortium)、Python の [PEP](https://www.python.org/dev/peps/)、Java の [JSR](https://ja.wikipedia.org/wiki/Java_Community_Process) などのようなものです。それらが本家の団体が制定しているのに対し、PSR は公認であるものの有志のコミュニティが制定しているため **PSR 規格に準拠するのは「より任意的なもの」になってる**などの違いがあります。そのため、あくまでも「推奨」されたガイドラインとされます。<br><br>このように PSR は PHP を扱う上で必須の規格ではありません。しかし、オープンソースなど、他者と共同開発する際の[プロトコル](https://qiita.com/KEINOS/items/cb7f629268b90ef6493d)として採用されていることが多くあります。<br><br>PSR-0 や PSR-4 は、その規格（`PSR`）のうちオートローダーに関して制定したものになります。[独自にオートローダーを実装する](https://qiita.com/tadsan/items/a78c9160418200e2d47a)ことも問題ありませんが、パッケージ管理に（他者の開発したライブラリを利用するのに）便利な [composer](https://qiita.com/KEINOS/items/86a16b06af6e936a1841#fn1) が PSR に準拠したオートローダーを採用しているため、独自で実装するにしても PSR の仕様に準拠する方が良いとされます。また、`composer` は PSR-0 の採用を廃止したので、現状 PSR-4 がオートローダーの[デファクト・スタンダード](https://ja.wikipedia.org/wiki/%E3%83%87%E3%83%95%E3%82%A1%E3%82%AF%E3%83%88%E3%82%B9%E3%82%BF%E3%83%B3%E3%83%80%E3%83%BC%E3%83%89)と言えると思います。<br><br>● 参考文献：[PHP Standards Recommendations](https://www.php-fig.org/psr/) PHP-FIG 公式<br>● 「[PHP Standard Recommendation](https://en.wikipedia.org/wiki/PHP_Standard_Recommendation)」@ Wikipedia（英語）<br>● あわせて読みたい： [PSRの誤解](https://qiita.com/tadsan/items/942a381e952e12a8fa5a) @ Qiita

[^autoloader]: **PHP のオートローダーとは**、一度読み込んでおくだけで、他の外部ファイルを `include` もしくは `require` する手間を省くための仕組みです。<br><br>例えば、肥大化したスクリプトを複数ファイルに分けた場合、各々を `include` や `require` で追記する必要がありますが、その手間が省けます。特にメンテナンス性を上げるためにファイルをクラスごとに分けた場合などです。具体的には、外部ファイルを `include` `require` する代わりに、オートローダーのスクリプトを 1 度 `require` することで、クラス・ファイルなどの外部ファイルを自動的に読み込みます。<br><br>オートローダーの機能には大きく 2 種類あり、事前に読み込む静的な方法と、クラスなどが呼び出された時に読み込む動的な方法があります。`psr-4` や `psr-0` の代わりに [`files` を使った場合](https://qiita.com/suin/items/b31e3c5bff15c821ccaa#files)は事前に読み込みます。<br><br>オートローダーを採用することによる速度低下ですが、オートローダーの実装方法によるものの**大きな差はない**とされます。もちろん、直接 `include` `require` した方が速いのですが、オートローダーを利用した方がメンテナンス性や開発における利便性が増すことにより、結果的に安定性も増すため**総合してオートローダーを採用した方が良い**という傾向があります。参照ファイルが多くなると、ファイルへのアクセスも増えるためスピード低下が気になりますが、現在の PHP はプリ・コンパイル型言語なため、一度実行すれば 1 ファイル（1つの中間ファイル）にまとめられるので気にする必要はほとんどありません。<br><br>また、PSR-4 で制定されたオートローダーの仕様で実装しておくと、同じく準拠したフレームワークなどで利用できるというメリットがあります。そのため、標準でオートローダーを持っている `composer` を利用するのが[車輪の再発明](https://ja.wikipedia.org/wiki/%E8%BB%8A%E8%BC%AA%E3%81%AE%E5%86%8D%E7%99%BA%E6%98%8E)防止につながるとされます。この場合、`require_once('vendor/autoloader.php');` のオートローダーを読み込むだけで使えるようになります。詳しくは上記の「[あわせて読みたい](#%E5%8F%82%E8%80%83%E6%96%87%E7%8C%AE%E3%81%82%E3%82%8F%E3%81%9B%E3%81%A6%E8%AA%AD%E3%81%BF%E3%81%9F%E3%81%84)」の参考文献をご覧ください。


## TL; DR <sub><sup>（今北産業）</sup></sub>

> PHP において `PSR` の `PSR-0` と `PSR-4` は、どちらもオートロード（外部ファイルの自動読み込み）の仕様を制定したもの。

- `PSR-0` 
  - シンプルだが、[名前空間](#%E5%90%8D%E5%89%8D%E7%A9%BA%E9%96%93%E3%81%A8%E3%81%AF)の利用に限界があり柔軟性に乏しい
  - <font color=darkorange>現在は非推奨</font>（Deprecated）
  - [PSR-0: Autoloading Standard](https://www.php-fig.org/psr/psr-0/) @ PHP-FIG.org
- `PSR-4`
  - 初期設定項目は多いが、名前空間／ファイル／ディレクトリの構成に柔軟性がある
  - [PSR-4: Autoloader](https://www.php-fig.org/psr/psr-4/) @ PHP-FIG.org
- PHP がデフォルトで持っているオートロード機能（[spl_autoload_register](https://www.php.net/manual/ja/function.spl-autoload-register.php) ）を使い「俺様オートローダー」を実装する際に準拠したい仕様。はたまた、オートローダーを使いたい場合に、統一した使い方を知りたい場合に参考にすべき仕様

---

## TS; DR <sub><sup>（kwsk）</sup></sub>

### `PSR-0`

> **名前空間と実在のディレクトリ構成を同じにする**仕様。

名前空間<sup><sup><a href="#%E5%90%8D%E5%89%8D%E7%A9%BA%E9%96%93%E3%81%A8%E3%81%AF">[?]</a></sup></sup>に、実在するディレクトリをルート・ディレクトリとして割り当て、それ以下のディレクトリ名が同じになる仕様です。[2014/10/21 より推奨されていません](https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md)（`Deprecated` になりました）。

- 名前空間の例：`\hoge\fuga`
- 割り当て例： `"hoge\fuga\": "src/"`（名前空間 `\hoge\fuga` に `./src/` を割り当て）
  - ファイルの設置先例：`src/hoge/fuga/myClassPiyo.php`
  - クラス利用時の例：`\hoge\fuga\myClassPiyo`

```json:書き方（composer.json）
{
    "autoload": {
        "psr-0": {
            "hoge\\fuga\\": "src/"
        }
    }
}
```

```php:PSR-0の利用イメージ
<?php
namespace MyVendorName\MyPackageName;

// オートローダーの読み込み
require_once(__DIR__ . '../vendor/autoload.php');

use hoge\fuga\myClassPiyo;   // 設置先: src/hoge/fuga/myClassPiyo.php
use hoge\fuga\myClassMogera; // 設置先: src/hoge/fuga/myClassMogera.php

$obj1 = new myClassPiyo();
$obj2 = new myClassMogera();
```

### `PSR-4`

> **名前空間が実在のディレクトリ構成に依存しない仕様**。

名前空間に検索パスを紐付けしておき、名前空間からパスを、クラス名からファイル名を判断する仕様です。

- 名前空間の例：`\hoge\fuga\`
    - 紐付けられた検索ディレクトリのパスの例
        - `./src/lib/foo/` 
        - `./vendor/someone/some_package/bar/` 
- ファイルの設置先の例：
    - `./src/lib/foo/myClassPiyo.php`
    - `./vendor/someone/some_package/bar/myClassMogera.php`<br><sub><sup>設置先の違いと、後述の利用時（`use`）の呼び出し方に注目。</sup></sub>

```json:書き方（composer.json）
{
    "autoload": {
        "psr-4": {
            "hoge\\fuga\\": [
                "src/lib/foo",
                "vendor/someone/some_package/bar"
            ]
        }
    }
}
```

```php:PSR-4の利用イメージ
<?php
namespace MyVendorName\MyPackageName;

// オートローダーの読み込み
require_once(__DIR__ . '../vendor/autoload.php');

use hoge\fuga\myClassPiyo;   // 設置先（以下のどちらか）:
                             //   src/lib/foo/myClassPiyo.php
                             //   vendor/someone/some_package/bar/myClassPiyo.php
use hoge\fuga\myClassMogera; // 設置先（以下のどちらか）:
                             //   src/lib/foo/myClassMogera.php
                             //   vendor/someone/some_package/bar/myClassMogera.php

$obj1 = new myClassPiyo();
$obj2 = new myClassMogera();
```

## リファレンス

- [PSR-0 公式リファレンス](https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md) | PHP-FIG @ GitHub
- [PSR-4 公式リファレンス](https://www.php-fig.org/psr/psr-4/) @ PHP-FIG.org
    - [PSR-4 の Autoloder の利用サンプル](https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-4-autoloader-examples.md) | PHP-FIG @ GitHub
- [PSR-4 autoloader (日本語訳)](https://qiita.com/inouet/items/0208237629496070bbd4) @ Qiita

## 参考文献／あわせて読みたい

- [PSRは誰が作ってるの？](https://qiita.com/tadsan/items/942a381e952e12a8fa5a#psr%E3%81%AF%E8%AA%B0%E3%81%8C%E4%BD%9C%E3%81%A3%E3%81%A6%E3%82%8B%E3%81%AE) | [PSRの誤解](https://qiita.com/tadsan/items/942a381e952e12a8fa5a) @ Qiita
- [includeって書きたくない僕たちのためのオートローディングとComposer](https://qiita.com/tadsan/items/a78c9160418200e2d47a) @ Qiita
- [【PSR-4 Autoload】第一回 autoloadの概要を理解](https://qiita.com/yanmayanmy/items/e856f5a7f0265a338cb9) @ Qiita
- [Composerのautoloadの書き方早見表](https://qiita.com/suin/items/b31e3c5bff15c821ccaa) @ Qiita
- [逆引き！Composer コマンド・ライン一覧](https://qiita.com/KEINOS/items/86a16b06af6e936a1841) @ Qiita

---

## 名前空間とは

### TL; DR <sub><sup>（今北産業）</sup></sub>

名前空間とは、、、

1. 変数にスコープ<sup><sup><a href="#%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%97%E3%81%A8%E3%81%AF">[?]</a></sup></sup>があるように、スクリプトに俺様スコープを指定して名前を付けること。
1. 名前にカテゴリや階層的な情報を `\`（バックスラッシュ）で持たせた仕様。
1. 名前が長ったらしくなっても、使う際に標準機能で短くすることができる。

関数名にカテゴリを含めた場合と、名前空間付きにした場合の違い：

- `foo_bar_piyo();`
    - → `\foo\bar\piyo();` <sup><sub>（`piyo()` は `\foo\bar` に属する）</sub></sup>
- `hoge_fuga_piyo();`
    - → `\hoge\fuga\piyo();` <sup><sub>（`piyo()` は `\hoge\fuga` に属する）</sub></sup>
- `hoge_fuga_moge();`
    - → `\hoge\fuga\moge();` <sup><sub>（`moge()` も上記と同じ `\hoge\fuga` に属するので、`piyo()` だけでアクセスできる）</sub></sup>

長ったらしい名前を使う時に短くする（エイリアスを張る）例：

- `use function \hoge\fuga\piyo as piyopiyo;`
    - → `\hoge\fuga\piyo()` を `piyopiyo()` として利用可能になる。

つまり、<strong>同名の関数やクラスがある場合でも「名前空間」を使うことでお互いに影響を与えない</strong>ようにすることができます。

---

### TS; DR <sub><sup>〜名前空間を完全に理解した気になるコマケーこと〜</sup></sub>

`autoloader` の恩恵を存分に受けるためには「名前空間」の理解が必要です。使う場合は、`namespace` と宣言するので、直訳で「名前空間」と呼ばれます。

しかし「名前空間」と言われても、ラノベ脳がすぎるので亜空間とか空間転送とか宇宙空間のようなものを想像してしまい、たいそうなものである印象を受けます。

PHP の「名前空間」は、どちらかと言うと公園や施設などにある「なんとかスペース」と言った空間の方の「空間」です。

喫煙所を「タバコ・スペース」と言うようなもので、その場合、喫煙できるスコープは「タバコ・スペース」のみに限定されます。

#### スコープとは

「スコープ」とは「ターゲットを限定するために参照できる範囲を絞ったもの」です。

ゴルゴ（13）さんが、ターゲットに狙いを定める時のスコープのイメージです。スコープ外のものは参照できません。

つまり「変数にスコープがある」とは「変数を参照するには範囲がある」ということです。例えば、**異なる関数内で定義された変数は、「同じ変数名」でも異なるもの**になります。

```php:同じ変数名 $hoge でもスコープが違うと別のもの
function foo(): string
{
    $hoge = 'one';
    $fuga = $hoge; // 上記 $hoge と同じスコープなので 'one' が代入される。

    return $fuga; // Output: one
}

function bar(): string
{
    $hoge = 'uno';
    $fuga = $hoge; // 上記 $hoge と同じスコープなので 'uno' が代入される。

    return $fuga; // Output: uno
}

echo foo() . PHP_EOL; // one
echo bar() . PHP_EOL; // uno

// Note: PHP_EOL は、PHP が動いている OS の改行コードが入っている PHP 定数
```

このように、同じ関数内であれば変数を参照できます。しかし、**違う関数内では同じ変数名でも参照するターゲットが異る**のです。

「... ... まぁ ... そうだよね」と感じると思います。

アホみたいな話しですが、実は、この範囲を業界用語で「スコープ」と呼んでいるだけです。響きが[かっこいい](https://www.google.com/search?q=%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%97%E3%83%89%E3%83%83%E3%82%B0&tbm=isch)し。

#### 空間に閉じ込めてみる

さて「名前空間」を掘り下げる前に、もう 1 つアホみたいに基本的な仕様を再確認する必要があります。

それは、**同じファイル内には同じ関数名は宣言できない**ということです。

```php
<?php

function foo(){ return 'hoge'; }
function foo(){ return 'fuga'; }

echo foo() . PHP_EOL;

// PHP Fatal error:  Cannot redeclare foo() (previously declared in /workspace/Main.php:3) in /workspace/Main.php on line 4
```

このように、`Cannot redeclare` エラーが発生します。

「... ... まぁ ... そうだよね」と感じると思います。

実は、これもスコープが関連しています。

同じスコープ内、つまり同じ空間内に同じ関数名が存在しようとするからです。上記の場合は、「グローバル空間」と呼ばれる汎用でデフォルトの空間に存在しようとしています。

つまり、「ターゲットの男を狙え」と言われてスコープを覗いたら「おっさんが二人映り込んでた」ようなもので、どっちを狙っていいのか分からないのと同じ状態です。

この場合、「ターゲットの<strong><ruby>髭面<rt>ひげづら</rt></ruby>の男</strong>（bearded）を狙え」と限定されると狙いが定まります。

```php:関数名fooを、各々違うnamespace名で閉じ込める
<?php

namespace target\bearded
{
    function foo(){ return 'hoge'; }
}

namespace target\glasses
{
    function foo(){ return 'fuga'; }
}

namespace enemy
{
    function foo(){ return 'piyo'; }
}

namespace golgo13
{
    echo \target\bearded\foo() . PHP_EOL; // hoge
    echo \target\glasses\foo() . PHP_EOL; // fuga
    echo \enemy\foo() . PHP_EOL;          // piyo
}

```

- [オンラインで動作をみる](https://paiza.io/projects/0Nm73M6O6NdMRci2bKOkzA) @ paiza.IO

ネームスペースがディレクトリ構成のように見えて来たのではないでしょうか。実際、似たようなものです。

#### 名前空間は仮想ディレクトリのようなもの

ここで<strong>注意すべき点は「名前空間の区切りは "&#92;"（`＼`, バックスラッシュ）であること」</strong>です。

名前空間を見聞きするも遠慮してしまう理由に "&#92;"（`＼`, バックスラッシュ）があります。普段使わないだけでなく、Windows ユーザの場合 "&yen;" （`￥`, 円マーク）と表示されることが多いためです。

古い Windows ユーザーで、海外の人とのやりとりの FAX や、英語の本を読むとディレクトリの指定に円マークが使われていないことに違和感を持った人も多いのではないでしょうか。受けとったデータでは円マークで表示されるのに。

macOS ユーザでも、日本語キーボードの場合、バックスラッシュと円マークは同じキー（バックスラッシュは `alt`＋円マーク）であるため探しづらいなどあります。これらの理由は、**シフト JIS にはバックスラッシュが存在しなかった**ので円マークで代用していた名残りです。

時代は変わり、UTF-8 がデファクト・スタンダードになりました。UTF-8 では、バックスラッシュと円マークは明確に別物となり、各々文字コードを持っています。そのため、フォントによっては同じ円マークに見えても違うコードだったりするので Windows ユーザーは特に注意しましょう。

次に<strong>注意すべき点は「名前にバックスラッシュが含まれると、名前空間を持っていると判断される」こと</strong>です。

例えば、以下のように別の名前空間の関数を利用する場合、行頭の `\`（バックスラッシュ）に注意します。記載を省略すると、現在の名前空間に属すると判断されて動きません。

```php
<?php

namespace target\bearded
{
    function foo(){ return 'hoge'; }
}

namespace golgo13
{
    echo \target\bearded\foo() . PHP_EOL; // \target\bearded の空間にある foo() を探すので動く。
    echo target\bearded\foo() . PHP_EOL;  // \golgo13\target\bearded の空間にある foo() を探す。
                                          // 存在しない空間なのでエラーになる。
}

// PHP Fatal error:  Uncaught Error: Call to undefined function golgo13\target\bearded\foo() in /workspace/Main.php:11
```

- [オンラインで動作をみる](https://paiza.io/projects/RM9z-kzSSfjtAnCv75w-0w) @ paiza.IO

イメージとして `file_get_contents('hoge.txt');` だと現在のディレクトリ、`file_get_contents('/fuga/piyo/hoge.txt');` とした場合は `/fuga/piyo/` のディレクトリを覗きにいくようなものに近いと思います（Win ユーザの場合 `c:¥¥` がないのでピンと来ないかもしれませんが）。

名前空間が「仮想的なディレクトリのようなもの」として、以下のシンプルな例をご覧ください。

```php
<?php

namespace target\bearded
{
    function foo(){ return 'hoge'; }
}

namespace target\glasses
{
    function foo(){ return 'fuga'; }
}

namespace target
{
    function foo()
    {
       // 各々、頭に \ がないので、この階層（target）より下の階層の
       // 空間の foo() を使う
       $result = bearded\foo() . ' ' . glasses\foo();

       return $result;
    }
}

namespace golgo13
{
    echo \target\foo() . PHP_EOL;   // hoge fuga
}
```

- [オンラインで動作を見る](https://paiza.io/projects/hjZZmr5atZohxmHB5zRROg) @ paiza.IO

`\target` 名前空間と言う「なんちゃって仮想ディレクトリ」直下に `foo()` を定義して、その下の階層 `bearded` と `glasses` にある各々の `foo()` を関数内で使っているのがわかりますでしょうか。

#### 1 ファイル 1 空間がベスト

```php
<?php

namespace target\bearded
{
    function foo(){ return 'hoge'; }
}

namespace target\glasses
{
    function foo(){ return 'fuga'; }
}
```

上記は、1 つのファイルに複数の名前空間を定義しています。しかし、このような **1 つのファイルに複数の名前空間を持たせることは推奨されていません**。<sub><sup>動いちゃうけど</sup></sub>

おそらく理由は単純で以下の 2 つが主にあると思います。

1. 同じファイルなら関数名の方を変えた方が**可読性**は高い。
2. 1 ファイル 1 名前空間で定義した方が**メンテナンス性**が高い。

先の例をファイルに分けると以下のようになります。`namespace ... { ... }` と <font color=darkorange>**`{}` で括らなくても `namespace ...;`（セミコロン付き）にするとファイル全体が対象になります**</font>。

この時、`namespace \target\bearded;` ではなく、`namespace target\bearded;` と頭に `\` が付かないことに注意します。

```php:bearded.php
<?php

namespace target\bearded; // ファイル全体が同じ名前空間になる。 \target\bearded; ではないことに注意。

function foo(){ return 'hoge'; }
```

```php:glasses.php
<?php

namespace target\glasses; // ファイル全体が同じ名前空間になる

function foo(){ return 'fuga'; }
```

```php:enemy.php
<?php

namespace enemy; // ファイル全体が同じ名前空間になる

function foo(){ return 'piyo'; }
```

各々を別ファイルにしたら、メインのスクリプトで `include` して利用します。

```php:main.php
<?php

namespace MyName\MyApp;

include('bearded.php'); // namespace -> \target\bearded 
include('glasses.php'); // namespace -> \target\glasses
include('enemy.php');   // namespace -> \enemy

echo \target\bearded\foo() . PHP_EOL; // hoge
echo \target\glasses\foo() . PHP_EOL; // fuga
echo \enemy\foo() . PHP_EOL;          // piyo
```

`include` が増えると目が遊ぶので、1 つにまとめる。（`composer` は、この機能を標準で持っています。）

```php:include.php
<?php

include('bearded.php');
include('glasses.php');
include('enemy.php');
```

そして、最終的には以下のようになります。

```php:main.php
<?php

namespace MyName\MyApp; // このファイルの名前空間を MyName\MyApp にする

include('include.php');

echo \target\bearded\foo() . PHP_EOL; // hoge
echo \target\glasses\foo() . PHP_EOL; // fuga
echo \enemy\foo() . PHP_EOL;          // piyo
```

- [オンラインで動作をみる](https://paiza.io/projects/n-RZfqVn8tufrJahowvb9w) @ paiza.IO

このように、恐れずに言えば**名前空間付きであれば同じ関数名・クラス名であっても気がねなく `include`/`require` できる**と言うことです。

ここまでなら、「えっ？ `target_bearded_foo()` を `\target\bearded\foo()` と名前を変えているのと一緒じゃん」と思われるかもしれません。

<font color=darkorange>正解です</font>。

`target_bearded_foo()` を「検索した時に同じ名前が並ぶと確認する箇所が増えるので、名前を見ただけでわかるようにする**一元管理的な手法**」だとすると、`\target\bearded\foo()` は「名前は短く保ち、仮想ディレクトリでカテゴライズして整理する手法が**名前空間を使った方法**」と言えます。

しかし、`target_bearded_foo()` のように、ファイル名に全てを含める手法は長い目で見ると問題を孕んでいます。

例えば、アプリや俺様ライブラリ（短編コード集）が肥大・増えてくると関数名が長くなるのでエイリアス（ショートカット）を作りたくなるなど、です。

#### 名前空間のエイリアス

少し冗長ですが、先ほどの例にエイリアスを貼って見たいと思います。`\target\beard\foo()` と `\target\glasses\foo()` が長いので短くする例です。

そこから、よくあると思われる流れを追って、問題を見たいと思います。

```php:main.php
<?php

namespace MyName\MyApp;

include('include.php'); // include 集をインポート

// エイリアス作成
function louisYamadaLIII()
{
    return \target\bearded\foo();
}

// エイリアス作成
function higuchiKun()
{
    return \target\glasses\foo();
}

echo louisYamadaLIII() . PHP_EOL; // hoge
echo higuchiKun() . PHP_EOL;      // fuga
```

さらに、`function` の定義が邪魔なので `hige_danshaku.php` にまとめます。ここでのポイントは `main.php` と同じ名前空間にしていることです。

```php:hige_danshaku.php
<?php

namespace MyName\MyApp; // main.php と同じ名前空間

function louisYamadaLIII()
{
    return \target\bearded\foo();
}

function higuchiKun()
{
    return \target\glasses\foo();
}
```

`include.php` に新規作成した `hige_danshaku.php` を追加します。

```php:include.php
<?php

include('bearded.php');
include('glasses.php');
include('enemy.php');
include('hige_danshaku.php');
```

すると、メインのコードは以下のようにスッキリします。


```php:main.php
<?php

namespace MyName\MyApp;

include('include.php');

echo louisYamadaLIII() . PHP_EOL; // hoge
echo higuchiKun() . PHP_EOL;      // fuga
```

しかし、スッキリはしたものの、**`\target\...\foo()` を前提とした別の人**がこのコードを読んだ場合、`louisYamadaLIII()` や `higuchiKun()` の動きを知るために `include.php` をほじくって行かないと行けません。

実は [PHP の名前空間にはエイリアスを貼る機能があります](https://www.php.net/manual/ja/language.namespaces.importing.php)。

```php
use function <オリジナル> as <エイリアス>
```

これを利用すると `hige_danshaku.php`（俺様エイリアス・ファイル）は必要ない、かつ他のユーザーはエイリアスの元が何であったか知ることができます。

```php:main.php
<?php

namespace MyName\MyApp;

include('include.php'); // 'hige_danshaku.php' はこの中にいらない

// エイリアスを貼る
use function \target\beard\foo as louisYamadaLIII;
use function \target\glasses\foo as higuchiKun;

echo louisYamadaLIII() . PHP_EOL;   // hoge
echo higuchiKun() . PHP_EOL;        // fuga
```

名前空間を短くするだけでなく、別名で使いたい場合にもエイリアス（`use function`）を使うメリットが出てきます。特に、一般的なパッケージを使う場合など、「このスクリプト内では別名を割り当てている」ということが一見して他の人に伝わるからです。

#### 名前空間を使うシチュエーション

おそらく「クラス」を普段から活用している人は名前空間の感覚は掴みやすいかもしれません。

関数名がぶつかる場合は、クラスのメソッド（クラス関数）にしてしまえば良いからです。つまり、関数をクラスと言うスコープに閉じ込めてしまうことができるので、その感覚に近いからです。

しかし、むしろ「名前空間」は、オブジェク糖嗜好の甘いものが苦手な<ruby>漢<rt>おとこ</rt></ruby>の中の漢の[関羽](https://ja.wikipedia.org/wiki/%E9%96%A2%E7%BE%BD)のような人に向いているかもしれません。つまり「名前空間」は関数好きのための情報整理術の 1 つと言えるかもしれません。

基本的に、アプリがシンプルな場合は**無理して名前空間を使う必要はない**と思います。つまり、今まで通り（デフォルトのグローバル空間に設置するタイプ）で良いと思います。

外部ライブラリを使うにしても、ライブラリが名前空間を持っていれば、インポートして名前空間をフルパスで指定すれば良いだけの話しです。

では、「自分のアプリに名前空間を持たせる必要があるか」の判断ポイントとして、いくつか挙げてみたいと思います。

1. 名前がカテゴリ情報を持ち始めた。
2. `composer` などで使える俺様ライブラリに昇格させたくなった。
3. 名前を見ただけで機能が把握できる名前にしたものの、似たものが増えちゃったので微妙に変えないといけなくなった。

**名前空間を前提として設計しないと、後々面倒なことになるケース**もあります。最近でいえば、よく使われそうなユーザー関数名が本家で採用されちゃった `function fn(){}` です。

PHP 7.4 から使えるようになった[アロー関数](https://www.php.net/manual/ja/functions.arrow.php)を定義するのが `fn()` になったため、意外に多くの老舗のライブラリが使えなくなっています。

名前空間を付ければ良いだけかと思いきや、グローバル空間で使うことを前提としていたため、ライブラリを利用しているアプリは下位互換性を保たせるために奮闘しているのです。

とりあえず、<font color=darkorange>**これからアプリを作るのであれば名前空間を付けておく**のが得策</font>だと思います。

```php
<?php
namespace MyName/MySeries/MyApp;

function foo(): string
{
   return 'bar' . PHP_EOL;
}

echo foo();

```