ソフトウェア開発の世界では、命令型と宣言型という 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 }
言い換えると、一連の命令というよりは一連の宣言に近いシステムを構築していることになります。アダプターとモデルは、ランダムな axios.get() 呼び出しのアドホック クラスターではなく、コードの残りの部分が依存できるパターンを形成します。
なぜこのような努力をするのでしょうか?プロジェクトが成長するにつれて、命令型ロジックの地雷原を進むのに時間を無駄にしたくないからです。宣言的なデザインは期待を設定します:
このアプローチでは、開発者としての知性が尊重されます。どのエンドポイントがどのモデルに属しているか、ヘッダーがどこに定義されているかを思い出す必要はありません。代わりに、より高いレベルで考えることができます。データがどのようなもので、どのように関連するかを定義し、残りの処理はフレームワークに任せます。
私たちは、アダプターと静的フィールドを使用した宣言型アプローチが生の命令型コードよりも普遍的に優れているとは主張しません。小さなスクリプトの場合、必要なのは axios.get() だけかもしれません。しかし、システムが拡大するにつれて、宣言的アプローチにより、変更の苦痛が軽減され、機能の追加が容易になり、全体的な複雑さが適切に管理される持続可能な環境が作成されます。
これは、開発者であるあなたを、指示を書き写す人ではなく、賢いエンジニアのように扱うシステムを構築することであると言えます。
すべてのステップを手書きすることに慣れている場合、宣言型のアプローチは最初は異質に感じるかもしれません。しかし、一貫したパターン、明確に宣言されたエンドポイント、カスタム ロジックをきちんと追加する場所があるという穏やかさを一度経験すると、命令型のスプロールに戻るのは難しくなります。
それは優位性を証明することではありません。それは、将来の自分にもっと優しく、自分の時間をより尊重し、データと関係についての考え方にもっと調和したアプローチを提供することです。すべてのリクエストを細かく管理するのではなく、それを取得する方法の面倒な詳細ではなく、何をしたいかに焦点を当てて、物語のように読めるコードを作成します。
以上が宣言型データ アクセスを採用して開発者としての知性を尊重するの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。