PHPのクラスを使わないでWebアプリを作るときの注意点とコードを綺麗に保つルール

PHPでWebアプリケーションを構築する際、必ずしもクラスを使う必要はありません。
特に小規模なプロジェクトや試作段階では、手続き型のコードのほうがシンプルで理解しやすい場合があります。
しかし、設計の自由度が高い反面、適切なルールを設けないとコードの複雑性が急速に増大し、保守性が著しく低下する点には注意が必要です。

クラスを使わない設計では、関数とファイル構成がそのままアーキテクチャの骨格になります。
そのため、責務の分離を意識せずにコードを書き進めると、ロジックが肥大化しやすく、変更の影響範囲が読みにくくなります。
特に重要なのは「1ファイル1責務」の原則を徹底することです。
これにより、処理単位の独立性を保ち、後からの修正やテストが容易になります。

また、グローバル変数の多用は避けるべきです。
状態がどこで変更されているのか追跡困難になり、バグの温床となります。
代わりに、関数の引数と戻り値でデータの流れを明確にすることが望ましいです。

さらに、ディレクトリ構造を論理的に整理することも重要です。
例えば、ルーティング、ビジネスロジック、データアクセスを明確に分離することで、クラスを使わなくても一定の設計品質を維持できます。

クラスを使わない開発は自由度が高い一方で、規律がなければ破綻しやすい手法です。
そのため、意識的に設計ルールを定め、コードの一貫性と可読性を維持することが成功の鍵となります。

PHPでクラスを使わないWebアプリ開発とは何か
クラスなしPHP開発のメリットとSEO的な適用シーン
1. 小規模Webアプリにおける開発速度の向上
2. 学習コスト削減と初心者向けの利点
クラスを使わないPHP設計のリスクと保守性の問題
1. グローバル変数依存によるバグの増加
2. 責務分離不足によるスパゲッティコード化
関数ベースPHPアーキテクチャの設計原則
1. 1ファイル1責務の原則を徹底する
2. ビジネスロジックとデータ処理の分離
ディレクトリ構成で保つPHPコードの可読性
1. ルーティングとロジックの分離設計
2. データアクセス層の明確化
クラスを使わない場合のコーディングルール
1. 関数の責務を明確に定義する
2. 引数と戻り値によるデータフロー管理
よくあるアンチパターンと避けるべき設計
1. 巨大な関数へのロジック集約
2. ファイル間依存の過剰な増加
PHPでクラスを使わない開発のまとめと実践指針

PHPでクラスを使わないWebアプリ開発とは何か

PHPでクラスを使わずにWebアプリケーションを構築するとは、オブジェクト指向の設計に依存せず、主に関数とファイル構成を中心にシステムを組み立てる開発手法を指します。
この方法は手続き型プログラミングに分類され、処理の流れを上から順に記述していくスタイルが基本となります。

このアプローチでは、アプリケーション全体の構造はクラスではなく「関数の集合」と「ディレクトリ設計」によって決まります。
そのため、設計の自由度は高い一方で、統一されたルールが存在しない場合にはコードの一貫性が崩れやすくなる特徴があります。
特にWebアプリケーションのようにリクエスト・レスポンスが中心となるシステムでは、処理の流れを明確に整理することが重要になります。

具体的には、以下のような構造が一般的です。

レイヤー	役割	例
ルーティング	URLと処理の紐付け	index.php
ビジネスロジック	主要処理	user_create.php
データアクセス	DB操作	db_query.php

このように役割ごとにファイルを分割し、それぞれを関数単位で構成することで、クラスを使わなくても一定の構造化を実現できます。

例えば、ユーザー登録処理を関数ベースで記述すると以下のようになります。

function createUser($name, $email) {
    if (empty($name) || empty($email)) {
        return false;
    }
    $pdo = connectDatabase();
    $stmt = $pdo->prepare("INSERT INTO users (name, email) VALUES (?, ?)");
    return $stmt->execute([$name, $email]);
}

このように、状態を持たず関数の入力と出力のみで処理を完結させる設計が基本思想となります。
これは関数型プログラミングに近い性質を持ち、予測可能性が高くなるという利点があります。

一方で、クラスを使わない設計では以下のような点に注意が必要です。

グローバル変数への依存を避ける必要がある
処理の責務を関数単位で明確に分離する必要がある
ファイル間の依存関係を最小限に抑える必要がある

これらを守らない場合、コードは容易にスパゲッティ化し、変更時の影響範囲が予測できなくなります。
特にWebアプリケーションでは機能追加の頻度が高いため、この問題は顕著になります。

また、この手法は小規模から中規模のプロジェクトに適しており、プロトタイピングやシンプルなAPIサーバーなどでは非常に有効です。
しかし、規模が拡大するにつれて設計の厳密さが求められるため、クラスベースの設計への移行を検討するケースも多くなります。

総じて、PHPでクラスを使わない開発とは「自由度の高い構造を持ちながらも、明確な設計規律を前提とする手法」であり、そのバランス感覚が品質を大きく左右することになります。

クラスなしPHP開発のメリットとSEO的な適用シーン

クラスを使わないPHP開発は、一見すると古典的な手法に見えますが、実務的には今でも十分に価値があります。
特に小規模なWebアプリケーションやSEOを重視したシンプルなサイト構築においては、その軽量さと直感的な構造が大きな利点となります。

この手法の本質は、抽象化レイヤーを最小限に抑え、リクエストからレスポンスまでの流れを直接的に記述する点にあります。
そのため、処理の追跡が容易であり、パフォーマンスの観点でもオーバーヘッドが少ないという特徴があります。
特にSEOの文脈では、ページ生成速度やサーバー負荷の軽減が間接的に評価へ影響するため、この軽量構成は合理的な選択肢となり得ます。

小規模Webアプリにおける開発速度の向上

小規模なWebアプリケーションでは、設計の複雑さよりも実装スピードが優先されることが多くあります。
このような状況においてクラスを省略することは、初期開発コストを大幅に削減する効果があります。

クラスベース設計では、インターフェース設計や依存性注入など、初期段階での設計負荷が増大しがちです。
一方、関数ベースの設計では以下のようなシンプルな構造で即座に実装へ移行できます。

function getArticles() {
    $pdo = connectDb();
    return $pdo->query("SELECT * FROM articles")->fetchAll();
}
function renderArticles($articles) {
    foreach ($articles as $article) {
        echo "<h2>{$article['title']}</h2>";
    }
}

このように、処理単位がそのままコードに対応するため、思考コストが低く、試行錯誤のサイクルを高速化できます。
結果として、MVP（Minimum Viable Product）の構築やSEO向けランディングページの量産などに適しています。

また、検索エンジン最適化の観点では、ページ生成ロジックが単純であるほどキャッシュ戦略や静的化が容易になるため、運用面でもメリットがあります。

学習コスト削減と初心者向けの利点

クラスを使わないPHP開発は、プログラミング初心者にとって理解しやすいという特徴があります。
オブジェクト指向の概念である継承やポリモーフィズムを前提としないため、まずは「入力と出力」「条件分岐」「関数分割」といった基本概念に集中できます。

これは学習段階において非常に重要であり、複雑な抽象概念に早期から触れることによる認知負荷を軽減します。
結果として、コードの挙動を直接的に理解しやすくなり、デバッグ能力の向上にもつながります。

また、関数ベースの構造はWebの基本モデルであるリクエスト・レスポンスと親和性が高く、HTTPリクエストごとに処理が完結する構造を直感的に把握できます。
この点は、サーバーサイドプログラミングの入門として非常に有効です。

さらに、学習初期段階では設計パターンよりも実装経験の蓄積が重要であるため、シンプルな構造の中で多くのコードを書くことが理解の深化につながります。
結果として、後にクラスベース設計へ移行する際にも、基礎概念が明確に整理されている状態を維持できます。

クラスを使わないPHP設計のリスクと保守性の問題

クラスを使わないPHP設計は軽量で直感的である一方、長期的な視点では保守性に関するリスクが顕著に現れます。
特にプロジェクト規模が拡大するにつれて、設計上の統制が弱い構造はコードの可読性と変更容易性を著しく低下させる要因となります。

この問題の本質は、抽象化の欠如と状態管理の曖昧さにあります。
クラスベース設計であれば、状態と振る舞いをひとつの単位にまとめることで責務を明確化できますが、関数ベースではその境界が開発者の裁量に委ねられます。
その結果、設計ルールが曖昧なまま実装が進行しやすくなります。

グローバル変数依存によるバグの増加

クラスを使用しない設計において最も典型的な問題の一つが、グローバル変数への依存です。
状態を共有するために安易にグローバル領域を利用すると、どの関数がどのタイミングで値を変更しているのか追跡が困難になります。

特にWebアプリケーションではリクエスト単位で状態が変化するため、意図しない副作用が発生しやすくなります。
例えば以下のような構造は典型的な危険例です。

$config = [];
function setConfig($key, $value) {
    global $config;
    $config[$key] = $value;
}
function getConfig($key) {
    global $config;
    return $config[$key] ?? null;
}

このような設計では、どの関数が状態を変更したのかが明示されず、依存関係が暗黙的になります。
その結果、バグの再現性が低くなり、デバッグコストが指数関数的に増加する傾向があります。

さらに、テスト容易性も著しく低下します。
状態が外部に依存しているため、単体テスト時に初期状態を保証することが難しくなり、テストの信頼性が損なわれます。

責務分離不足によるスパゲッティコード化

もう一つの重大な問題は、責務分離が不十分なままコードが拡張されることによるスパゲッティコード化です。
関数ベースの設計では自由度が高いため、明確な設計規約が存在しない場合、複数の責務が単一の関数に混在しやすくなります。

例えば、データ取得、バリデーション、HTML生成といった異なる役割が1つの関数に集約されると、コードの再利用性は著しく低下します。
また、変更時の影響範囲が予測できなくなり、軽微な修正がシステム全体の不具合につながる可能性もあります。

この状態を防ぐためには、以下のような設計意識が不可欠です。

関数は単一の責務のみを持たせる
入力と出力を明確に分離する
副作用を極力排除する

しかし、これらを開発チーム全体で徹底することは容易ではありません。
特にプロジェクトが成長するにつれて、個々の開発者の判断に依存する構造は統制が難しくなります。

結果として、コードベース全体が複雑化し、修正コストが増大するだけでなく、新規参画者の学習コストも上昇します。
これは長期運用において大きな技術的負債となります。

したがって、クラスを使わない設計を採用する場合でも、明確な規約と構造設計を持たなければ、保守性の観点では大きなリスクを抱えることになります。

関数ベースPHPアーキテクチャの設計原則

関数ベースでPHPアプリケーションを設計する場合、クラスによる構造化が存在しない分、設計原則の明確化が極めて重要になります。
特にアプリケーションの規模が拡大するにつれて、無秩序な関数の追加は即座に複雑性の増大につながるため、初期段階から一定のルールを敷くことが合理的です。

このアーキテクチャの核心は、抽象化ではなく「明示的な分離」にあります。
各関数の役割を限定し、ファイル単位で構造を整理することで、クラスが存在しなくても可読性と保守性を維持することが可能になります。

1ファイル1責務の原則を徹底する

関数ベース設計において最も重要な原則の一つが「1ファイル1責務」です。
これは、1つのファイルが持つ役割を極力限定し、他の責務を混在させないという設計思想です。

この原則が守られていない場合、例えば認証処理・データ取得・HTMLレンダリングが同一ファイルに混在し、コードの見通しが急速に悪化します。
その結果、変更時の影響範囲が広がり、修正コストが増大します。

実務的には、以下のような分割が基本となります。

ファイル種別	役割	例
controller	処理の起点	user.php
service	ビジネスロジック	user_service.php
repository	データ操作	user_repository.php

このように責務を明確化することで、クラスを用いずとも擬似的なレイヤードアーキテクチャを構築できます。
特に重要なのは、ファイル間の依存関係を一方向に保つことです。
これにより循環依存を防ぎ、コードの予測可能性を維持できます。

また、1ファイル1責務の原則はテスト容易性にも寄与します。
対象が明確であるため、単体での検証が容易になり、デバッグ範囲を限定できます。

ビジネスロジックとデータ処理の分離

もう一つの重要な設計原則は、ビジネスロジックとデータ処理の分離です。
これはアプリケーションの核心部分であり、関数ベース設計において特に意識すべきポイントです。

ビジネスロジックとは、アプリケーション固有のルールや計算処理を指し、データ処理とはDBアクセスや外部APIとの通信などを指します。
これらが混在すると、変更時に副作用が発生しやすくなり、保守性が著しく低下します。

例えば、ユーザー登録処理において「バリデーション」と「DB保存」が同一関数内に存在すると、DB仕様変更時にビジネスルールまで影響を受ける可能性があります。

この問題を回避するためには、責務を明確に分離した関数構造を採用します。

ビジネスロジック層：入力検証・ルール適用・状態計算
データアクセス層：SQL実行・外部API通信・永続化処理

この分離により、各層は独立して変更可能となり、システム全体の柔軟性が向上します。
また、再利用性の観点でも有利であり、同一ロジックを異なるデータソースで活用することが容易になります。

さらに、この構造はテスト戦略にも影響を与えます。
ビジネスロジックはモック不要で純粋関数としてテスト可能になり、データアクセス層は統合テストとして切り分けることができます。

結果として、関数ベースであっても設計原則を明確に定義することで、クラスベースに近い品質のアーキテクチャを実現することが可能になります。

ディレクトリ構成で保つPHPコードの可読性

クラスを使わないPHPアプリケーションにおいて、可読性と保守性を維持するための最も重要な要素の一つがディレクトリ構成です。
関数ベース設計では、クラスのような明確な構造単位が存在しないため、フォルダ構造そのものがアーキテクチャの骨格になります。
そのため、初期設計の段階で責務を意識したディレクトリ分割を行うことが極めて重要です。

特にWebアプリケーションでは、リクエストの入口からデータ処理、レスポンス生成までの流れが複数の処理層に分かれます。
この流れをディレクトリ単位で整理することで、コードの見通しが大幅に改善されます。
また、チーム開発においても、どの領域にどの処理を追加すべきかが明確になり、実装の衝突を減らす効果があります。

ルーティングとロジックの分離設計

関数ベースのPHP設計において最初に確立すべきなのが、ルーティングとビジネスロジックの分離です。
ルーティングとはHTTPリクエストを適切な処理へ振り分ける役割であり、ビジネスロジックとは実際の処理内容そのものを指します。
この2つが混在すると、コードの責務が曖昧になり、変更時の影響範囲が予測困難になります。

典型的な構成としては以下のように分割されます。

ディレクトリ	役割	内容例
routes	リクエスト制御	URLマッピング
controllers	処理の起点	入力受け取り
services	ビジネスロジック	計算・判定処理

このように分離することで、HTTP層とアプリケーションロジック層の依存関係を明確に切り離すことができます。
特に重要なのは、ルーティング層にビジネスロジックを含めないことです。
これにより、将来的にAPI化やCLI化を行う際にも再利用性が確保されます。

また、この構造はテスト容易性にも直結します。
ルーティング層は単なる振り分けに限定されるため、サービス層のみを独立してテストすることが可能になります。

データアクセス層の明確化

次に重要なのがデータアクセス層の明確化です。
データベース操作や外部APIとの通信をビジネスロジックから分離することで、システム全体の柔軟性と保守性が向上します。

この層が適切に分離されていない場合、SQLクエリやAPI呼び出しがビジネスロジックに散在し、変更時に複数箇所を修正する必要が生じます。
これは長期運用において典型的な技術的負債の原因となります。

関数ベース設計では、データアクセス専用のディレクトリを設けることが一般的です。
例えば以下のような構成になります。

repository：DB操作関数群
gateway：外部API通信処理
query：SQL生成ロジック

この分離により、データソースの変更が発生した場合でも影響範囲を局所化できます。
例えば、MySQLからPostgreSQLへ移行する場合でも、repository層のみの修正で対応可能となります。

さらに、この構造はセキュリティ面でも利点があります。
SQLインジェクション対策や外部通信の制御を一箇所に集約できるため、コードレビューの効率も向上します。

総じて、ディレクトリ構成を適切に設計することは、クラスを使わないPHPアーキテクチャにおける最も重要な設計要素の一つであり、長期的な保守性を大きく左右する要因となります。

クラスを使わない場合のコーディングルール

クラスを使わないPHP開発では、構造的な枠組みが言語機能として提供されないため、コーディングルールの設計が品質を直接左右します。
特に関数ベースの設計では、開発者の裁量が大きくなる分、明確な規律がなければコードの一貫性が崩壊しやすくなります。
そのため、実装ルールを明文化し、チーム全体で共有することが重要です。

このスタイルの本質は「自由度の高さと引き換えに、設計責任が開発者側に完全に委ねられる」という点にあります。
したがって、クラスによる強制的な設計制約がない代わりに、関数設計とデータフロー設計におけるルールが品質の基盤となります。

関数の責務を明確に定義する

関数ベース設計において最も重要なルールは、各関数の責務を明確に定義することです。
責務が曖昧な関数は、時間の経過とともに肥大化し、変更コストの増大やバグの温床となります。

理想的な関数は「単一の目的のみを持つ」状態であり、入力に対して明確な出力を返す構造です。
例えば、バリデーション、データ変換、DB操作などを1つの関数に混在させるべきではありません。
それぞれを独立した関数として切り出すことで、再利用性とテスト容易性が向上します。

関数設計の指針としては以下のような観点が重要です。

1関数1責務を厳守する
副作用を最小限に抑える
関数名から処理内容が明確に推測できるようにする

これらを徹底することで、コードの可読性が向上し、他者による理解コストも低減します。
また、責務が明確であればあるほど、機能追加や修正時の影響範囲を局所化できるため、保守性の観点でも大きな利点があります。

引数と戻り値によるデータフロー管理

クラスを使わない設計では、状態管理の中心が関数の引数と戻り値に移行します。
そのため、データフローの設計がシステム全体の品質を決定づける重要な要素となります。

グローバル変数や外部状態に依存した設計は避け、すべてのデータの流れを関数間の明示的な受け渡しで完結させることが理想です。
これにより、処理の流れがコード上で追跡可能となり、デバッグ性が大幅に向上します。

典型的な設計原則としては以下が挙げられます。

要素	推奨方針	効果
入力	明示的に引数として渡す	依存関係の可視化
出力	戻り値で返す	副作用の排除
状態	ローカルスコープに限定	安全性向上

このようにデータフローを統一することで、関数単位での独立性が高まり、並列的な思考でコードを理解できるようになります。
また、テスト時にも入力と出力のみを考慮すればよいため、モックの必要性を最小限に抑えることが可能です。

さらに重要なのは、関数間の依存関係を明示的にすることです。
ある関数が別の関数に依存する場合、その関係がコード上で明確に表現されている必要があります。
これにより、予期しない副作用や暗黙的な依存を排除できます。

総じて、クラスを使わない設計においては、関数単位の責務設計とデータフロー制御が品質の根幹を形成しており、この2点を適切に管理することが安定したアーキテクチャ構築の前提条件となります。

よくあるアンチパターンと避けるべき設計

クラスを使わないPHP設計は柔軟性が高い一方で、設計ルールを欠いたまま運用すると典型的なアンチパターンに陥りやすいという特徴があります。
特に関数ベースの実装では、制約が少ないことが逆に複雑性の増大を招き、長期的な保守性を著しく損なうケースが多く見られます。

この問題の本質は、構造的な枠組みがない状態で機能追加を繰り返すことにあります。
その結果、コードは局所最適に陥り、全体設計としての整合性が失われていきます。
以下では、特に頻出する2つのアンチパターンについて論理的に整理します。

巨大な関数へのロジック集約

最も典型的なアンチパターンの一つが、複数の責務を持つ巨大な関数の存在です。
関数ベース設計では自由度が高いため、入力処理・ビジネスロジック・データアクセス・出力生成が1つの関数に集約されることが少なくありません。

このような構造は短期的には実装速度を向上させるように見えますが、長期的には致命的な問題を引き起こします。
まず、関数の可読性が著しく低下し、処理の流れを追跡することが困難になります。
また、修正時の影響範囲が広がるため、軽微な変更でも予期しない副作用が発生するリスクが増大します。

さらに、テストの観点でも問題が顕著です。
責務が混在している関数は単体テストが困難であり、部分的なロジックの検証ができなくなります。
その結果、テスト全体が統合テストに依存し、品質保証コストが増加します。

この問題を避けるためには、関数の粒度を適切に保つことが重要です。
具体的には、処理を段階ごとに分割し、それぞれを独立した関数として実装する必要があります。

ファイル間依存の過剰な増加

もう一つの重大なアンチパターンが、ファイル間依存の過剰な増加です。
クラスベース設計では依存関係が明示的に管理されることが多いですが、関数ベース設計ではインポートやrequireによる依存が自由に拡張されるため、依存構造が複雑化しやすい傾向があります。

特に問題となるのは、複数のファイルが相互に依存し合う「循環依存」の状態です。
この状態に陥ると、どのファイルを修正した際にどこまで影響が波及するのか予測できなくなり、開発効率が著しく低下します。

また、依存関係が増加することで、コードの再利用性も低下します。
ある機能を切り出して再利用しようとしても、関連ファイルをすべて持ち出す必要が生じ、結果としてモジュール性が失われます。

この問題に対処するためには、依存関係を一方向に制御することが重要です。
例えば、以下のような構造が推奨されます。

レイヤー	依存方向	役割
controller	serviceへ依存	入力制御
service	repositoryへ依存	ビジネスロジック
repository	依存なし	データ操作

このように依存の方向を固定することで、コードの構造的安定性を確保できます。
また、依存の流れが明確であるほど、システム全体の理解コストも低減します。

総じて、巨大関数の集約と過剰なファイル依存は、関数ベースPHP設計における最も危険なアンチパターンであり、これらを回避する設計規律の有無がプロジェクトの成否を大きく左右します。

PHPでクラスを使わない開発のまとめと実践指針

PHPにおいてクラスを使わずにWebアプリケーションを構築する手法は、単なる「古い書き方」ではなく、設計思想として明確なメリットと制約を持つアプローチです。
特に小規模から中規模のプロジェクトでは、オーバーエンジニアリングを避けつつ、実装速度と理解容易性を優先できる点が大きな利点になります。

ただし、この手法は自由度が高い分だけ、設計規律が欠如すると即座に品質低下へと直結します。
そのため、クラスを使わない場合には「何を使わないか」ではなく「何を代替として設計ルールにするか」が本質的な論点になります。
関数とディレクトリ構成だけでアーキテクチャを成立させる以上、構造設計の重要性はむしろ増加します。

まず前提として理解すべきは、このスタイルが適している領域です。
一般的には以下のようなケースで有効です。

小規模なWebサイトや管理画面
SEO重視の静的寄りなページ生成
プロトタイプやMVP開発
単純なAPIサーバー

これらの領域では、複雑なドメインモデルや高度な抽象化よりも、シンプルな処理フローと高速な変更対応が重要になります。
そのため、クラスによる設計コストをあえて排除する判断は合理的です。

一方で、長期運用を前提とする場合には、明確な設計ルールが不可欠になります。
特に以下の3点は最低限の指針として機能します。

関数は必ず単一責務に限定する
状態は外部に保持せず引数と戻り値で完結させる
ディレクトリ構造をアーキテクチャとして扱う

これらを守ることで、クラスを使用しなくても一定レベルの保守性と拡張性を確保することが可能になります。
逆にこれらが曖昧な場合、コードは短期間で複雑化し、技術的負債が急速に蓄積します。

また、実務上重要なのは「どこまで抽象化を許容するか」という判断です。
抽象化を排除しすぎるとコードの重複が増加し、逆に抽象化しすぎると理解コストが上昇します。
このバランスを取るためには、以下のような構造的判断が有効です。

観点	推奨方針	理由
関数粒度	小さく保つ	再利用性とテスト容易性
ファイル構造	責務単位で分割	可読性と変更容易性
依存関係	一方向に限定	循環依存の防止