CodeIgniter 4.1の処理の流れ

CodeIgniter 4.1の処理の流れをまとめました。

public/index.php

  1. PHPのバージョンをチェック
  2. 定数FCPATHを定義
  3. Config\Pathsをインスタンス化
  4. system/bootstrap.phpをロードしCodeIgniterをインスタンス化し$appに代入
  5. $app->run()

system/bootstrap.php

  1. パスに関する定数を定義
  2. Config/Constants.phpをロード
  3. Common.phpをロード
  4. オートローダーをロード
  5. サービスロケーターをロード
  6. オートローダーを初期化
  7. Composerオートローダーをロード
  8. DotEnvをインスタンス化し実行
  9. CodeIgniterをインスタンス化して$appに代入
  10. $app->initialize()
  11. $appを返す

CodeIgniter::initialize()

  1. 環境を検出
  2. 環境別のbootファイル(Config/Boot/環境.php)をロード
  3. 例外ハンドラを設定
  4. PHP機能拡張をチェック
  5. デフォルトロケールを設定
  6. デフォルトタイムゾーンを設定
  7. Kintを初期化

CodeIgniter::run()

  1. Requestオブジェクトを取得
  2. Responseオブジェクトを取得
  3. forceGlobalSecureRequestsを処理
  4. リクエストメソッドSpoofingを処理
  5. ページキャッシュをチェック
  6. リクエストを処理(handleRequest())

CodeIgniter::handleRequest()

  1. ルーティングを処理しフィルターを検索
  2. フィルターがあれば有効化
  3. beforeフィルターを実行
  4. コントローラを実行
    • クロージャーコントローラーなら実行
    • コントローラーをインスタンス化
    • コントローラーのメソッドを実行
  5. 出力を収集
  6. afterフィルターを実行
  7. Responseを送信
  8. Responseオブジェクトを返す

Tags: codeigniter, codeigniter4

CodeIgniter 4.0.5と4.1.1がリリースされました

PHP8に対応したCodeIgniter 4.0.5と4.1.0が2021/01/31にリリースされました。

その後、パッケージングにミスが見つかり02/01に4.1.1がリリースされ、4.0.5のパッケージも更新されました。 なお、Composerでインストールしている場合は影響はありません。

PHP 7.3以上の場合は4.1.1へ、PHP 7.2の場合は4.0.5へアップグレードすることを推奨します。

私の CodeIgniter 4 Application Template も4.1に更新しました。

主な変更点

  • PHP8対応
  • 4.0.5はPHP 7.2をサポートする最後のバージョン
  • 4.1.xはPHP 7.3以上から8.xをサポート
  • CLIからコードを生成する Generator が追加
  • 多数のバグ修正

system 以外の更新

4.0.4と4.0.5を比較すると、system/外の以下のファイルに変更が加えられています。 これらは、composer updateでは更新されませんので、必要なものは手動で更新する必要があります。

Liaison Revision を使うと、更新が楽になります。

4.0.5/LICENSE
4.0.5/README.md
4.0.5/app/Config/App.php
4.0.5/app/Config/Autoload.php
4.0.5/app/Config/Boot/development.php
4.0.5/app/Config/Boot/production.php
4.0.5/app/Config/Boot/testing.php
4.0.5/app/Config/Cache.php
4.0.5/app/Config/Constants.php
4.0.5/app/Config/ContentSecurityPolicy.php
4.0.5/app/Config/Database.php
4.0.5/app/Config/DocTypes.php
4.0.5/app/Config/Email.php
4.0.5/app/Config/Encryption.php
4.0.5/app/Config/Events.php
4.0.5/app/Config/Exceptions.php
4.0.5/app/Config/Filters.php
4.0.5/app/Config/ForeignCharacters.php
4.0.5/app/Config/Format.php
4.0.5/app/Config/Generators.php
4.0.5/app/Config/Honeypot.php
4.0.5/app/Config/Images.php
4.0.5/app/Config/Kint.php
4.0.5/app/Config/Logger.php
4.0.5/app/Config/Migrations.php
4.0.5/app/Config/Mimes.php
4.0.5/app/Config/Modules.php
4.0.5/app/Config/Pager.php
4.0.5/app/Config/Paths.php
4.0.5/app/Config/Routes.php
4.0.5/app/Config/Security.php
4.0.5/app/Config/Services.php
4.0.5/app/Config/Toolbar.php
4.0.5/app/Config/UserAgents.php
4.0.5/app/Config/Validation.php
4.0.5/app/Config/View.php
4.0.5/app/Controllers/BaseController.php
4.0.5/app/Controllers/Home.php
4.0.5/app/Views/errors/cli/error_404.php
4.0.5/app/Views/errors/cli/error_exception.php
4.0.5/app/Views/errors/html/debug.css
4.0.5/app/Views/errors/html/debug.js
4.0.5/app/Views/errors/html/error_exception.php
4.0.5/composer.json
4.0.5/env
4.0.5/license.txt
4.0.5/phpunit.xml.dist
4.0.5/public/.htaccess
4.0.5/public/index.php
4.0.5/spark

関連

参考

Tags: codeigniter, codeigniter4, release

DRY原則とは1つの知識を1箇所で明確に表現すること

DRY原則とは?

『The Pragmatic Programmer: From Journeyman to Master』(1999年)(翻訳『達人プログラマー』2000年)で最初に言及された原則です。

定義としては以下です。

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. https://en.wikipedia.org/wiki/Don%27t_repeat_yourself

知識のあらゆる部分はそのシステムにおいて単一で、曖昧さのない、信頼できる表現でなくてはならない。 https://www.infoq.com/jp/news/2012/05/DRY-code-duplication-coupling/

要するに、「1つの知識は、システム内で1箇所で明確に表現されないといけない」という原則です。

知識とは何でしょうか?コンセプト、概念と説明されることもあります。

DRY原則のよくある誤解

コードの重複ではない

DRY原則は、コードの重複とは説明されていません。コードの重複はDRY原則に違反している可能性が高いですが、違反していないかも知れません。

コードだけに限らない

コードに限られてたものではありません。

『達人プログラマー』の著者の Dave Thomas も以下のように説明しています。

A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation. https://www.artima.com/intv/dry.html

システムの知識は単なるコードよりずっと大きなものです。データベーススキーマ、テスト計画、ビルドシステム、さらにはドキュメントまでも指しています。 https://www.infoq.com/jp/news/2012/05/DRY-code-duplication-coupling/

コードの重複を取り除く

商品クラス

例えば、商品があるとします。

class 商品
{
    private string $商品名;
    private int $価格;

    public function __construct(string $商品名, int $価格)
    {
        $this->商品名 = $商品名;
        $this->価格 = $価格;
    }

    public function 価格(): int
    {
        return $this->価格;
    }
}

通常値引計算クラス

10%を割り引く通常値引というものがあるとすると、以下のようにクラス化できます。

class 通常値引計算
{
    public function 値引額(商品 $商品): int
    {
        $discount = $商品->価格() * 10 / 100;

        return (int) $discount;
    }
}

消費税計算クラス

また、10%の消費税を課税しないといけないということで、以下のようなクラスも出てきます。 本物の消費税は複数税率とか計算方法もややこしいですが、ここでは単純に全て10%とします。

class 消費税計算
{
    public function 税額(商品 $商品): float
    {
        $tax = $商品->価格() * 10 / 100;

        return $tax;
    }
}

そうすると、以下のコードは重複しています。DRY原則違反でしょうか?

$商品->価格() * 10 / 100;

共通化する

とりあえず、同じ処理なので共通化してみましょう。

class ???
{
    public static function 計算する(商品 $商品): float
    {
        return $商品->価格() * 10 / 100;
    }
}

さて、このクラスは何を表現しているのでしょうか? やっていることは商品価格の10%を計算することです。よって、少しぎこちないですが、 「商品価格の10パーセント計算」とクラス名を付けましょう。

class 商品価格の10パーセント計算
{
    public static function 計算する(商品 $商品): float
    {
        return $商品->価格() * 10 / 100;
    }
}

すると、「通常値引計算」と「消費税計算」は以下のようにリファクタリングされます。

class 通常値引計算
{
    public function 値引額(商品 $商品): int
    {
        $discount = 商品価格の10パーセント計算::計算する($商品);

        return (int) $discount;
    }
}
class 消費税計算
{
    public function 税額(商品 $商品): float
    {
        $tax = 商品価格の10パーセント計算::計算する($商品);

        return $tax;
    }
}

値引率の変更

ここで、通常値引が10%ではなく、20%に変わるとします。 「商品価格の10パーセント計算」クラスを変更しようとする人はいるでしょうか? もし、変更すると以下のようになります。

class 商品価格の10パーセント計算
{
    public static function 計算する(商品 $商品): float
    {
        return $商品->価格() * 20 / 100;
    }
}

「商品価格の10パーセント計算」クラスが20%を返すようになります。 流石にこれをする人はいないでしょう。

通常値引の変更なので「通常値引計算」クラスを以下のように変更します。

class 通常値引計算
{
    public function 値引額(商品 $商品): int
    {
        $discount = $商品->価格() * 20 / 100;

        return $discount;
    }
}

「商品価格の10パーセント計算」クラスが必要だったかどうかは疑問が残りますが、作ったからといって問題は起こりませんでした。

過度な共通化をするには

たまたま同じ10%なので共通化してしまい、その後、片方の率が変更になり、他方にも影響を与えてバグってしまうようにするにはどうすればいいでしょう?

10%という知識を通常値引計算クラス、消費税計算クラスから完全に取り除く必要があります。

「商品価格の10パーセント計算」をもっと抽象的な名前に変更しましょう。 これくらいでどうでしょうか?

class 商品関連計算
{
    public static function 計算する(商品 $商品): float
    {
        return $商品->価格() * 10 / 100;
    }
}

何だかよくわかりませんが、商品に関連した計算をしているクラスができました。

すると、「通常値引計算」と「消費税計算」は以下のようになります。

class 通常値引計算
{
    public function 値引額(商品 $商品): int
    {
        $discount = 商品関連計算::計算する($商品);

        return (int) $discount;
    }
}
class 消費税計算
{
    public function 税額(商品 $商品): float
    {
        $tax = 商品関連計算::計算する($商品);

        return $tax;
    }
}

これで、10%という通常値引計算および消費税計算の知識の一部が両クラスから完全に消えました。

ここで、消費税率が15%に変更になるとすると、何だかよくわからない「商品関連計算」クラスの計算ロジックを15%に変更すると、通常値引も15%になってしまうという状況をやっと作り出せます。

これはDRY原則に従っているか?

さて、「商品関連計算」クラスは 1つの知識を明確に表現しているでしょうか?していませんね。何を表現しているのかよくわからないクラスですから。これはDRY原則違反でしょう。

過度な共通化の要件

「通常値引計算」「消費税計算」という概念(知識)をクラスとして分けている時点で、両者を混同するのはかなり難しいことがわかります。

現実にこれらを混同するためには、違う概念であるということが理解できていない、あるいは、そのようなことを全く考えていない必要があります。

つまり、異なる概念であることを理解できていない場合は、このような過度な共通化をしてしまう可能性があるということです。

1つの知識を1箇所で表現するには

結局、1つの知識を1箇所で表現するには、知識・概念を正しく把握することが必要です。

例えば、色々な種類の値引計算があるとして、それらの関係はどうなのか?ある値引は別の値引に関連・依存するのか?しないのか?それらはビジネスに関するルールであり知識です。

値引Aが値引Bに依存すると思っていれば、値引Aが値引Bに依存するコードを書いてしまいます。本当は両者は完全に独立したものであったとしても。

ビジネスに関する知識が不確かならば、誤って違う概念を混同したり、同じ概念を2箇所以上に書いてしまう可能性が高くなります。

まとめ

  • DRY原則とは「1つの知識は、システム内で1箇所に明確に表現されないといけない」という原則です。
  • コードの重複だけがDRY原則の対象ではありません。
  • 知識が不確かなら、DRY原則を守ることは難しくなるでしょう。

参考

Tags: programming, php