宣言型データ アクセスを採用して開発者としての知性を尊重する

ソフトウェア開発の世界では、命令型と宣言型という 2 つのパラダイムの間で引き裂かれることがよくあります。多くの開発者にとって、命令型コードの魅力はそのシンプルさです。手順を段階的に記述するだけで、コンピューターが何をしているのかが正確にわかります。ただし、複雑さが増すにつれて、その段階的なアプローチは、コードベース全体に点在する複雑なロジックに変わります。対照的に、宣言的アプローチは、欲しいものをどうやって手に入れるかではなく、欲しいものを説明できるようにすることを目的としており、詳細を細かく管理することから解放されます。

この投稿では、宣言型が「最良の」アプローチであることを証明するためにここにいるわけではありません。代わりに、宣言的設計によって、開発者としての知性を尊重するシステムを作成する方法を検討します。これにより、アプリケーションを適切に拡張し、認知的オーバーヘッドを大幅に軽減して維持できるようになります。

---

命令: 詳細な指示の道

さまざまな API から投稿やユーザーを取得する小さなアプリケーションを構築していると想像してください。命令型の方法は次のようになります:

const axios = require('axios');

// Imperative approach: You write every step for every request
async function fetchAllPosts() {
    const response = await axios.get('https://jsonplaceholder.typicode.com/posts');
    return response.data;
}

async function fetchUsers() {
    const response = await axios.get('https://dummyjson.com/users');
    return response.data.users;
}

一見すると、これは簡単です。GET リクエストを実行してデータを返すだけです。しかし、複雑さが忍び寄ると何が起こるでしょうか?以下が必要になる場合があります:

• さまざまなモデルの複数のエンドポイント。
• 認証ヘッダー。
• ページネーション、フィルタリング、複雑なクエリ。
• データの検証とモデル間の関係。

コードをコピーして貼り付け、エンドポイントとヘッダーをあちこちにハードコーディングし、複雑なロジックの網を手動で管理することになるでしょう。命令型スタイルは面倒に思えてきます。同じ命令を何度も何度も書くことになり、すべてのロジックがどこにあるのか見失いやすくなります。

---

宣言的: 意図とパターンの世界

次に、より宣言的なデザインを見てみましょう。各リソースをどのように取得するかをシステムに指示する代わりに、各リソースがどのように見えるか、どこに存在するか、他のリソースとどのように関連するかを記述します。その後、柔軟なアダプターまたはマネージャーに内部で詳細を処理させます。 これが例です:

一見すると、クラス、静的プロパティ、アダプターがあるため、これはより複雑に見えるかもしれません。しかし、よく見てください:

class PostAdapter extends APIAdapter {
    static baseURL = 'https://jsonplaceholder.typicode.com/';
    static headers = {};
    static endpoint = 'posts';

    async *all(...args){
        // Insert custom business logic here (e.g., logging, pagination)
        return await super.all(...args)
    }
}

class UserAdapter extends APIAdapter {
    static baseURL = 'https://dummyjson.com/';
    static headers = {};
    static endpoint = 'users';
}

class CustomValidatedPost extends Post {
    static schema = {
        ...Post.schema,
        email: 'string',
        body: 'string',
        userId: 'number'
    };
    static adapter = PostAdapter;
}

class CustomUser extends User {
    static adapter = UserAdapter;

    async _post() {
        return await CustomValidatedPost.objects.query({ id: this.id });
    }
}

// Using the declared models and adapters:
const userIterator = await CustomUser.objects.all();
async function processNextUser() {
    const { value: user, done } = await userIterator.next();
    if (done) return;
    // Handle your user data here
}

• どこにもハードコードされた URL はありません: ベース URL、エンドポイント、ヘッダーはクラス レベルで 1 回定義されます。そのモデルに対するリクエストでは、これらのデフォルトが自動的に使用されます。
• 関係は宣言されており、強制ではありません: CustomUser は、ユーザーに関連する投稿を返す _post メソッドを定義します。これは、命令型コードの束ではなく、ほとんどクエリのように感じられます。 「このユーザーの投稿が欲しい」という意図を述べています。
• 拡張とカスタマイズが簡単: 投稿を取得するためのカスタム ロジックが必要ですか? PostAdapter で all() をオーバーライドするだけです。このロジックをデフォルトの動作のクリーンな拡張にすることで、他のものを誤って壊してしまう可能性を減らします。

言い換えると、一連の命令というよりは一連の宣言に近いシステムを構築していることになります。アダプターとモデルは、ランダムな axios.get() 呼び出しのアドホック クラスターではなく、コードの残りの部分が依存できるパターンを形成します。

---

本当の勝利: 開発者のインテリジェンスを尊重する

なぜこのような努力をするのでしょうか?プロジェクトが成長するにつれて、命令型ロジックの地雷原を進むのに時間を無駄にしたくないからです。宣言的なデザインは期待を設定します:

• CustomUser.objects.all() を見ると、その意味がすぐにわかります。すべての CustomUser インスタンスのイテレータを返します。推測は不要です。
• 静的アダプター = UserAdapter; を宣言すると、CustomUser でのデータ操作はすべて内部で UserAdapter を使用することがわかります。一貫性と明確さが組み込まれています。
• モデルに静的スキーマを定義すると、命令型コードを繰り返し記述しなくても、システムがそれらのフィールドを検証または処理する方法を認識していると信頼できます。

このアプローチでは、開発者としての知性が尊重されます。どのエンドポイントがどのモデルに属しているか、ヘッダーがどこに定義されているかを思い出す必要はありません。代わりに、より高いレベルで考えることができます。データがどのようなもので、どのように関連するかを定義し、残りの処理はフレームワークに任せます。

---

「最高」であることではなく、持続可能であることが重要

私たちは、アダプターと静的フィールドを使用した宣言型アプローチが生の命令型コードよりも普遍的に優れているとは主張しません。小さなスクリプトの場合、必要なのは axios.get() だけかもしれません。しかし、システムが拡大するにつれて、宣言的アプローチにより、変更の苦痛が軽減され、機能の追加が容易になり、全体的な複雑さが適切に管理される持続可能な環境が作成されます。

これは、開発者であるあなたを、指示を書き写す人ではなく、賢いエンジニアのように扱うシステムを構築することであると言えます。

---

結論

すべてのステップを手書きすることに慣れている場合、宣言型のアプローチは最初は異質に感じるかもしれません。しかし、一貫したパターン、明確に宣言されたエンドポイント、カスタム ロジックをきちんと追加する場所があるという穏やかさを一度経験すると、命令型のスプロールに戻るのは難しくなります。

それは優位性を証明することではありません。それは、将来の自分にもっと優しく、自分の時間をより尊重し、データと関係についての考え方にもっと調和したアプローチを提供することです。すべてのリクエストを細かく管理するのではなく、それを取得する方法の面倒な詳細ではなく、何をしたいかに焦点を当てて、物語のように読めるコードを作成します。

以上が宣言型データ アクセスを採用して開発者としての知性を尊重するの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。