PHPでクラスを使わない手続き型プログラミングのメリットとデメリットを徹底比較

PHPでは、クラスを用いない手続き型プログラミングでも十分に実用的なアプリケーションを構築できます。
特にWeb開発の現場では、関数ベースで処理を積み上げていくスタイルは直感的で理解しやすく、コードの流れを上から順に追えるという点で初心者にも親しみやすい特徴があります。
一方で、オブジェクト指向が主流となった現在においては、その設計思想との違いを正しく理解することが重要です。

手続き型は処理の単純さと軽量さが魅力である一方、規模が大きくなるにつれて依存関係が複雑化しやすいという側面も持ちます。
対してクラスを用いる設計では、データと振る舞いをまとめることで保守性や再利用性を高めることが可能ですが、その分抽象化のコストや設計の難易度も上がります。
つまり両者は単純な優劣ではなく、状況に応じた使い分けが求められる関係にあります。

本記事では、PHPにおけるクラスを使わない手続き型プログラミングに焦点を当て、メリットとデメリットを構造的に整理しながら徹底比較していきます。実務での適用シーンや設計判断の基準についても触れ、どのような場面で手続き型が有効に機能するのか、逆にどのような場合に限界が現れるのかを論理的に解説します。“`

PHPの手続き型プログラミングとは？クラスを使わない基本概念
PHPにおける手続き型の基本構造と書き方
手続き型PHPのメリット：シンプルさと開発速度
可読性と保守性：小規模開発での強み
デメリット：スパゲッティコード化とスケーラビリティ問題
実務での活用シーン：小規模Webアプリやスクリプト開発
オブジェクト指向との比較：PHP設計思想の違い
手続き型からOOPへの移行と設計改善のポイント
まとめ：PHPで手続き型を選ぶべきケースとは

PHPの手続き型プログラミングとは？クラスを使わない基本概念

PHPの手続き型プログラミングとは、クラスやオブジェクトを用いずに、関数と処理の流れを中心にシステムを構築するプログラミング手法です。
このスタイルでは、データと処理が明確に分離され、上から下へ順序立ててコードが実行されるという特徴があります。
特にWeb開発の初期段階では、この手続き型が標準的な書き方として広く採用されてきました。

本質的には「何をするか」を関数単位で定義し、それらを組み合わせてアプリケーション全体を構築します。
例えば、入力データの取得、バリデーション、データベース処理、出力といった流れを、それぞれの関数に分割して記述することで構造化を図ります。

このような設計思想は、オブジェクト指向のように「データと振る舞いを一体化する」という発想とは異なり、処理の流れそのものを主軸に置いている点が重要です。
そのため、コードの追跡が直感的であり、小規模な開発では非常に扱いやすい特徴を持ちます。

典型的な手続き型PHPの構造は以下のようになります。

<?php
function getUserInput() {
    return $_POST['name'] ?? '';
}
function validateUser($name) {
    return !empty($name);
}
function saveUser($name) {
    // 仮の保存処理
    return true;
}
$name = getUserInput();
if (validateUser($name)) {
    saveUser($name);
    echo "保存に成功しました";
} else {
    echo "入力が不正です";
}

この例から分かるように、処理は上から順番に流れ、各関数は独立して単一の責務を持っています。
このような設計は、コードの見通しの良さを確保するうえで有効です。

また、手続き型プログラミングの特徴を整理すると以下のようになります。

観点	特徴	向いているケース
構造	上から下への逐次実行	小規模スクリプト
設計	関数中心	単機能ツール
学習コスト	低い	初学者・短期開発

一方で、このスタイルは規模が拡大するにつれて関数間の依存関係が複雑化しやすく、保守性に課題が生じることがあります。
そのため、単純さを活かせる範囲で使用することが重要です。

つまりPHPの手続き型プログラミングは、シンプルさと直線的な理解のしやすさを優先する設計手法であり、複雑な抽象化を必要としない場面において非常に強力な選択肢となります。

PHPにおける手続き型の基本構造と書き方

PHPにおける手続き型プログラミングの基本構造は、極めて明快です。
中心となるのは「関数」と「実行順序」であり、クラスやインスタンスといった抽象化レイヤーを排除することで、処理の流れを直接的に表現します。
この設計思想は、コードの読みやすさと実行の予測可能性を重視する点に特徴があります。

まず前提として、手続き型ではプログラム全体が「上から下へ順番に実行されるスクリプト」として構成されます。
その中で必要な処理を関数として分割し、それらを適切な順序で呼び出すことでアプリケーションを形成します。
このアプローチは、処理単位の明確化と再利用性の最低限の確保を両立するための現実的な設計です。

典型的な構造は以下の3層に整理できます。

入力処理（リクエストやデータ取得）
ビジネスロジック（検証・加工・判断）
出力処理（画面表示やデータ保存）

この分割は厳密なレイヤードアーキテクチャではありませんが、実務上は十分な整理効果を持ちます。

次に、実際のコード例を見ていきます。

<?php
// 入力取得
function getRequestData() {
    return $_GET['id'] ?? null;
}
// ビジネスロジック
function findUserById($id) {
    $users = [
        1 => 'Alice',
        2 => 'Bob',
        3 => 'Charlie'
    ];
    return $users[$id] ?? null;
}
// 出力処理
function renderUser($user) {
    if ($user === null) {
        echo "ユーザーが見つかりません";
    } else {
        echo "ユーザー名: " . $user;
    }
}
// メイン処理
$id = getRequestData();
$user = findUserById($id);
renderUser($user);

このように、手続き型PHPでは「データの流れ」がそのままコードの流れとして表現されます。
この点は非常に重要で、抽象化による複雑性が排除されるため、デバッグや動作確認が容易になります。

また、関数の設計においては「副作用の管理」が重要になります。
例えばデータベースアクセスや出力処理は副作用を持つため、それらをどの関数に閉じ込めるかが設計の品質を左右します。
手続き型ではこの境界が曖昧になりやすいため、意識的に責務を分離する必要があります。

構造的な特徴を整理すると以下のようになります。

要素	内容	設計上のポイント
入力層	リクエスト取得	グローバル依存を避ける
ロジック層	条件分岐・計算	純粋関数化を意識
出力層	表示・保存	副作用を明確化

このような構造を維持することで、手続き型であっても一定の保守性を確保することが可能です。

最終的に重要なのは、PHPの手続き型は単なる「古い書き方」ではなく、明示的な制御フローを持つ合理的な設計手法であるという点です。
特に小規模から中規模のプロジェクトでは、このシンプルさが開発速度と理解容易性に直結します。

手続き型PHPのメリット：シンプルさと開発速度

手続き型PHPの最大の利点は、その構造的な単純さにあります。
クラスや継承といった複雑な抽象化を必要とせず、関数と処理の流れだけでアプリケーションを構築できるため、開発初期のスピードが非常に速いという特徴があります。
この性質は特にプロトタイピングや小規模サービスの開発において強く機能します。

まず、手続き型では設計負担が極めて低い点が重要です。
オブジェクト指向ではクラス設計や責務分割を事前に考える必要がありますが、手続き型では「必要な処理を関数として追加する」という直感的なアプローチが可能です。
そのため、要件が不確定な段階でも柔軟にコードを拡張できます。

また、実行フローが明確であることも大きなメリットです。
コードは基本的に上から下へと順序立てて実行されるため、処理の流れを追跡しやすく、デバッグも容易になります。
これは特に障害調査やログ解析の場面で効果を発揮します。

さらに、学習コストの低さも無視できません。
PHPを初めて学ぶ開発者にとって、クラスやインターフェースの概念は抽象度が高く、理解に時間がかかる場合があります。
一方で手続き型は「入力→処理→出力」という単純なモデルで構成されているため、プログラムの本質的な動作を短期間で習得できます。

実務的な観点からメリットを整理すると以下のようになります。

観点	メリット	具体的な効果
開発速度	実装が早い	MVPやプロトタイプ構築に最適
構造	シンプル	コードの理解が容易
学習性	低い学習コスト	初学者でも即戦力化可能
デバッグ	追跡しやすい	障害調査が迅速

このように、手続き型PHPは「速さ」と「分かりやすさ」を重視する場面で特に有効です。

コード例として、簡易的なログイン処理を考えると、そのシンプルさがよく分かります。

<?php
function checkUser($username, $password) {
    $validUser = 'admin';
    $validPass = 'secret';
    return $username === $validUser && $password === $validPass;
}
function login() {
    $username = $_POST['username'] ?? '';
    $password = $_POST['password'] ?? '';
    if (checkUser($username, $password)) {
        echo "ログイン成功";
    } else {
        echo "ログイン失敗";
    }
}
login();

この例では、処理が非常に直接的であり、関数の呼び出し順序を追うだけで全体の動作を理解できます。
この「思考負荷の低さ」は、短期間で成果を出す必要がある現場において大きな価値を持ちます。

ただし、このシンプルさは裏返すと「設計の自由度が低い」という側面にもつながります。
しかし、それは欠点というよりもトレードオフであり、適切な規模のプロジェクトであればむしろ利点として機能します。

つまり手続き型PHPは、複雑な設計よりも速度と直感性を優先する状況において最適化された実装スタイルであると評価できます。

可読性と保守性：小規模開発での強み

手続き型PHPは、その構造の単純さゆえに可読性と保守性のバランスが取りやすいという特徴があります。
特に小規模なWebアプリケーションや社内ツールのように、仕様が限定され変更頻度が高い開発環境では、この特性が実務的な価値として強く現れます。

まず可読性の観点から見ると、手続き型では処理の流れがコードの記述順と一致するため、全体像を直感的に把握しやすいという利点があります。
関数の呼び出し関係が複雑にネストされることが少なく、ファイルを上から順に読むだけで処理の意図を追跡できる構造になっています。
これは特にチーム開発において、新規参加者が短時間でコードベースを理解する助けになります。

一方で保守性についても、適切に関数分割されていれば一定の品質を維持できます。
手続き型であっても、責務ごとに関数を分離する設計を徹底することで、修正範囲を局所化することが可能です。
例えばバリデーション処理やデータ取得処理を独立した関数として管理すれば、仕様変更が発生した際の影響範囲を限定できます。

ただし、保守性を維持するためには設計規律が重要になります。
特に以下の点は意識する必要があります。

関数の責務を単一に保つこと
グローバル変数の使用を避けること
副作用を持つ処理を明示的に分離すること

これらを守らない場合、手続き型のコードは急速に複雑化し、いわゆるスパゲッティコード化するリスクがあります。
そのため、シンプルであるがゆえに「設計の自律性」が求められる点は重要な注意点です。

実務的なイメージを明確にするために、簡易的な記事管理処理の例を示します。

<?php
function fetchArticle($id) {
    $articles = [
        1 => ['title' => 'PHP入門', 'content' => '基本構文の解説'],
        2 => ['title' => '配列操作', 'content' => '配列の扱い方']
    ];
    return $articles[$id] ?? null;
}
function formatArticle($article) {
    return $article['title'] . "\n" . $article['content'];
}
function displayArticle($id) {
    $article = fetchArticle($id);
    if ($article === null) {
        echo "記事が見つかりません";
        return;
    }
    echo formatArticle($article);
}
displayArticle(1);

この例では、処理が明確に分割されているため、各関数の役割を容易に把握できます。
fetchArticleはデータ取得、formatArticleは整形、displayArticleは制御というように責務が分離されており、可読性と保守性が両立されています。

また、このような構造はテストの観点からも有利です。
関数単位でのテストが可能になるため、ユニットテストの対象を明確に切り出すことができます。
オブジェクト指向に比べて抽象階層が少ないため、テスト対象の依存関係も単純化される傾向があります。

一方で注意すべき点として、規模が拡大すると関数数が増加し、全体の構造把握が困難になる可能性があります。
そのため、ディレクトリ構造や命名規則による整理が重要になります。

結論として、手続き型PHPは小規模開発において高い可読性と適度な保守性を両立できる現実的な選択肢であり、設計の規律さえ維持できれば十分に実務耐性を持つスタイルであると言えます。

デメリット：スパゲッティコード化とスケーラビリティ問題

手続き型PHPはシンプルさと開発速度に優れる一方で、規模が拡大した際に構造的な限界が顕在化しやすいという本質的なデメリットを抱えています。
特に代表的な問題がスパゲッティコード化とスケーラビリティの低下です。
これらは設計思想そのものに起因するため、単純なコーディング規約だけでは完全に回避することが難しい性質を持ちます。

まずスパゲッティコード化についてですが、これは関数同士の依存関係が複雑に絡み合い、処理の流れを一方向に追えなくなる状態を指します。
手続き型ではグローバルスコープや共有変数を用いることが比較的容易であるため、設計意識が低い場合に状態管理が破綻しやすくなります。
結果として、ある関数の変更が予期しない副作用を引き起こすケースが増加します。

この問題の本質は「責務の境界が曖昧になること」にあります。
オブジェクト指向であればクラス単位でデータと振る舞いをカプセル化できますが、手続き型ではその境界が自然には存在しないため、開発者自身が設計上の境界を明示的に定義する必要があります。

次にスケーラビリティの問題です。
小規模な段階では問題にならない構造でも、機能追加や要件変更が重なるにつれてコード量が増加し、全体の見通しが急速に悪化します。
特に以下のような状況では影響が顕著になります。

機能ごとの分離が不十分な場合
関数が肥大化している場合
データの流れが暗黙的に共有されている場合

これらが重なると、変更コストが指数的に増加し、開発効率が低下します。

実際のイメージとして、状態依存が強いコードは以下のような問題を引き起こします。

<?php
$user = null;
function loadUser() {
    global $user;
    $user = ['name' => 'Alice', 'role' => 'admin'];
}
function checkPermission() {
    global $user;
    return $user['role'] === 'admin';
}
function updateUserName($name) {
    global $user;
    $user['name'] = $name;
}
loadUser();
if (checkPermission()) {
    updateUserName('Bob');
}
echo $user['name'];

このようなコードでは、グローバル変数に依存することで関数間の結合度が高まり、どの関数がどの状態を変更しているのかが追跡しづらくなります。
これは典型的なスパゲッティコードの初期兆候です。

さらに、スケーラビリティの観点では「変更の波及範囲」が問題になります。
一箇所の修正が複数の関数に影響を与えるため、修正時のリスクが高くなります。
これは小規模開発では許容できても、中規模以上のシステムでは致命的な欠陥となり得ます。

これらの問題を整理すると以下のようになります。

問題	原因	影響
スパゲッティコード化	グローバル依存・責務不明確	可読性低下
スケーラビリティ低下	構造の非分離	変更コスト増大
副作用の増加	状態共有	バグ発生率上昇

結論として、手続き型PHPは設計規律が緩い状態では急速に破綻するリスクを持つため、適切な規模管理と構造設計が不可欠です。
特に長期運用を前提とするプロジェクトでは、このデメリットを十分に理解した上で採用判断を行う必要があります。

実務での活用シーン：小規模Webアプリやスクリプト開発

手続き型PHPは、そのシンプルな構造ゆえに、実務の中でも特定の領域において非常に高い適合性を持ちます。
特に小規模Webアプリケーションや業務用スクリプト開発のように、要件が明確かつ短期間での実装が求められる場面では、その特性が最大限に活かされます。

まず小規模Webアプリにおいては、機能が限定されているため、複雑なオブジェクト設計を行う必要がないケースが多く存在します。
例えば、問い合わせフォーム、簡易的な管理画面、社内向けツールなどは、数ファイル程度で完結することも珍しくありません。
このような状況では、クラスベースの設計を導入すること自体がオーバースペックとなり、開発コストを不必要に引き上げる可能性があります。

手続き型PHPは、このような場面で「必要十分な抽象化」を提供します。
関数単位で処理を分割することで、最低限の構造化を維持しつつ、過度な設計負担を回避できます。
結果として、実装スピードと理解容易性のバランスが非常に良好になります。

次にスクリプト開発の領域では、その効果はさらに顕著です。
例えば、CSVデータの変換処理、ログの整形、定期バッチ処理などは、明確な入力と出力を持つ単純な処理が中心です。
このようなケースでは、オブジェクト指向の設計よりも、手続き型の直線的な処理フローの方が自然に適合します。

実務でよく見られるスクリプトの例として、CSVを読み込んで整形する処理があります。

<?php
function readCsv($filePath) {
    $rows = [];
    if (($handle = fopen($filePath, 'r')) !== false) {
        while (($data = fgetcsv($handle)) !== false) {
            $rows[] = $data;
        }
        fclose($handle);
    }
    return $rows;
}
function transformData($rows) {
    $result = [];
    foreach ($rows as $row) {
        $result[] = [
            'name' => $row[0] ?? '',
            'email' => $row[1] ?? ''
        ];
    }
    return $result;
}
function outputJson($data) {
    echo json_encode($data, JSON_PRETTY_PRINT);
}
$rows = readCsv('data.csv');
$data = transformData($rows);
outputJson($data);

このように、各処理が明確に分離されているため、処理の流れが非常に追いやすくなっています。
特にバッチ処理やワンショットスクリプトでは、この直線的な構造が開発効率を大きく向上させます。

また、手続き型PHPはデプロイや運用面でも軽量であるという利点があります。
フレームワークを必要とせず、単一ファイルまたは少数ファイルで構成できるため、環境構築コストが低く、迅速なリリースが可能です。
これは特に社内ツールや短期プロジェクトにおいて重要な要素です。

実務的な適用領域を整理すると以下のようになります。

小規模Webアプリケーション（問い合わせフォーム、管理画面）
データ処理スクリプト（CSV変換、ログ解析）
バッチ処理（定期実行タスク）
簡易APIの試作

これらの領域に共通するのは、「複雑な設計よりも速度と単純性が優先される」という点です。

結論として、手続き型PHPは万能な設計ではありませんが、適切なスコープにおいては極めて効率的な選択肢となります。
特に短期間で成果物を求められる実務環境では、その軽量性と直線的な構造が強力な武器となります。

オブジェクト指向との比較：PHP設計思想の違い

PHPにおける手続き型とオブジェクト指向は、単なる記法の違いではなく、設計思想そのものが異なるアプローチです。
両者の違いを正しく理解することは、適切なアーキテクチャ選択を行う上で非常に重要です。
特にPHPは両方のパラダイムを柔軟に扱えるため、開発者の設計判断が品質に直結します。

まず手続き型は「処理の流れ」を中心に設計されます。
入力から出力までの一連のプロセスを関数単位で分割し、それらを順番に呼び出すことでシステムを構築します。
一方、オブジェクト指向は「データと振る舞いの統合」を重視し、クラスという単位で責務をカプセル化します。
この違いは、コードの構造だけでなく思考モデルそのものに影響します。

オブジェクト指向では、現実世界の概念をクラスとして抽象化し、それらの相互作用によってシステムを表現します。
例えばユーザー、商品、注文といった概念は、それぞれ独立したオブジェクトとして設計されます。
このアプローチは複雑なドメインを扱う際に強力であり、大規模システムにおいて特に効果を発揮します。

一方で手続き型は抽象化を最小限に抑え、処理の直線性を優先します。
そのため、設計の自由度は低いものの、理解コストが低く、短期間での開発に適しています。
つまり両者は「複雑性の管理方法」が根本的に異なるのです。

この違いを整理すると以下のようになります。

観点	手続き型PHP	オブジェクト指向PHP
設計軸	処理中心	データと振る舞い中心
構造	関数ベース	クラスベース
抽象化	低い	高い
適用規模	小〜中規模	中〜大規模
学習コスト	低い	高い

この比較から分かるように、両者は競合関係ではなく補完関係にあります。
例えば、初期段階では手続き型で素早くプロトタイプを構築し、システムが成長した段階でオブジェクト指向へ移行するという戦略も現実的です。

実際のコードレベルでも思想の違いは明確に現れます。
オブジェクト指向では以下のように構造化されます。

<?php
class User {
    private string $name;
    public function __construct($name) {
        $this->name = $name;
    }
    public function getName() {
        return $this->name;
    }
}
$user = new User("Alice");
echo $user->getName();

このように、データと操作が一体化しているため、状態管理が明確になります。
一方で設計コストは上がり、単純な処理であってもクラス設計が必要になる場合があります。

対照的に手続き型では、同様の処理がより直接的に記述されます。
この差異は「抽象化の階層数」に起因しており、オブジェクト指向では中間レイヤーが増えることで柔軟性を得る代わりに複雑性も増加します。

重要なのは、どちらが優れているかではなく「どの規模・目的に適しているか」という観点です。
手続き型は即時性と単純性を提供し、オブジェクト指向は拡張性と保守性を提供します。

結論として、PHPにおける設計選択は二者択一ではなく、プロジェクトのライフサイクルや規模に応じて適切に使い分けることが合理的です。
両パラダイムの本質を理解することが、安定した設計判断につながります。

手続き型からOOPへの移行と設計改善のポイント

手続き型PHPからオブジェクト指向（OOP）への移行は、単なるコードの書き換えではなく、設計思想そのものの転換を意味します。
このプロセスでは、処理中心の構造からデータと振る舞いを統合した構造へと再編成する必要があり、段階的かつ戦略的に進めることが重要です。

まず移行の第一段階として行うべきは「関数の責務整理」です。
手続き型コードでは、1つの関数が複数の責務を持っているケースが多いため、それらを分解し、単一責務の関数へと再構築する必要があります。
この作業は後のクラス設計の基盤となります。

次に重要なのが「データ構造の抽象化」です。
配列ベースで扱っていたデータを、意味単位でクラスへと置き換えることで、データの意図が明確になります。
これにより、コードの可読性と安全性が大幅に向上します。

さらに、グローバル変数や共有状態の排除も重要なステップです。
OOPでは状態はオブジェクト内部に閉じ込めるため、外部からの予期しない変更を防ぐことができます。
これにより、副作用の管理が容易になり、バグの発生確率が低下します。

移行プロセスを整理すると以下のようになります。

関数の単一責務化
データ構造のクラス化
グローバル状態の排除
処理のオブジェクトへの移譲
依存関係の明示化

これらのステップを順に実施することで、段階的にOOPへ移行することが可能です。

実際の改善例として、ユーザー情報を扱う処理を考えます。
手続き型では以下のように記述されている場合があります。

<?php
function createUser($name, $role) {
    return [
        'name' => $name,
        'role' => $role
    ];
}
function isAdmin($user) {
    return $user['role'] === 'admin';
}
$user = createUser("Alice", "admin");
if (isAdmin($user)) {
    echo "管理者です";
}

この構造をOOPへ移行すると、データと振る舞いが統合され、責務が明確になります。

<?php
class User {
    private string $name;
    private string $role;
    public function __construct($name, $role) {
        $this->name = $name;
        $this->role = $role;
    }
    public function isAdmin(): bool {
        return $this->role === 'admin';
    }
    public function getName(): string {
        return $this->name;
    }
}
$user = new User("Alice", "admin");
if ($user->isAdmin()) {
    echo "管理者です";
}

この比較から分かるように、OOPではロジックがデータ構造の内部に移動することで、外部からの操作がより制御された形になります。
これにより、システム全体の整合性が高まり、長期的な保守性が向上します。

また、設計改善の観点では「依存関係の明示化」が重要なポイントです。
手続き型では関数間の依存が暗黙的になりがちですが、OOPではコンストラクタやインターフェースを通じて依存関係を明示できます。
これにより、テスト容易性や拡張性が大幅に改善されます。

一方で注意点として、無理なOOP化は設計過多を招く可能性があります。
すべてをクラス化することが必ずしも最適ではなく、シンプルな処理は手続き型のまま残すという判断も重要です。

結論として、手続き型からOOPへの移行は一方向の強制的な変換ではなく、システムの成長に応じて段階的に抽象化を導入するプロセスであり、設計の成熟度を高めるための戦略的な手法であると言えます。

まとめ：PHPで手続き型を選ぶべきケースとは

PHPにおける手続き型プログラミングは、オブジェクト指向と比較して単純な構造を持ちますが、その単純さは単なる過去の遺物ではなく、特定の条件下では依然として合理的な選択肢となります。
本記事で解説してきた通り、手続き型は処理の直線性と理解容易性を重視する設計であり、その特性を適切に活かすことで高い開発効率を実現できます。

まず前提として、手続き型が最も効果を発揮するのは「要件が明確で規模が小さいシステム」です。
例えば、問い合わせフォーム、簡易管理画面、単機能のAPIエンドポイント、あるいはバッチスクリプトなどは、複雑なドメインモデルを必要としないため、クラス設計を導入することが必ずしも合理的ではありません。
このような領域では、過剰な抽象化はむしろ開発速度と可読性を低下させる要因となります。

また、短期間での開発が求められるプロジェクトにおいても手続き型は有効です。
プロトタイピングやPoC（概念実証）の段階では、設計の厳密さよりも実装速度が優先されるため、関数ベースの直線的な構造が非常に適しています。
この段階では将来的な拡張性よりも、仮説検証のスピードが重要になります。

さらに、個人開発や少人数チームにおいても手続き型は現実的な選択肢です。
設計責務を分担する必要がない場合、複雑なアーキテクチャを導入するコストは相対的に高くなり、結果として開発効率を損なう可能性があります。

手続き型を選択する判断基準を整理すると以下のようになります。