Adopter l'accès déclaratif aux données pour respecter votre intelligence en tant que développeur

Dans le monde du développement logiciel, on se retrouve souvent tiraillé entre deux paradigmes : impératif et déclaratif. Pour de nombreux développeurs, l’attrait du code impératif réside dans sa simplicité : il suffit d’écrire les instructions étape par étape et vous savez exactement ce que fait l’ordinateur. Cependant, à mesure que la complexité augmente, cette approche étape par étape se transforme en un fouillis de logique dispersée dans la base de code. En revanche, l'approche déclarative vise à vous permettre de décrire ce que vous voulez plutôt que comment l'obtenir, vous libérant ainsi de la microgestion des détails.

Dans cet article, nous ne sommes pas là pour prouver que la déclarative est la « meilleure » approche. Au lieu de cela, nous explorerons comment une conception déclarative peut créer un système qui respecte votre intelligence en tant que développeur, vous permettant de développer votre application de manière gracieuse et de la maintenir avec beaucoup moins de surcharge cognitive.

---

Impératif : une route d’instructions détaillées

Imaginez que vous créez une petite application pour récupérer les publications et les utilisateurs de diverses API. La voie impérative pourrait ressembler à ceci :

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;
}

À première vue, c'est simple : il suffit de faire une requête GET et de renvoyer les données. Mais que se passe-t-il lorsque la complexité s’installe ? Vous pourriez avoir besoin de :

• Plusieurs points de terminaison pour différents modèles.
• En-têtes d'authentification.
• Pagination, filtrage et requêtes complexes.
• Validation des données et relations entre les modèles.

Vous vous retrouverez bientôt à copier et coller du code, à coder en dur des points de terminaison et des en-têtes partout, et à gérer manuellement un réseau de logique complexe. Le style impératif commence à ressembler à une corvée : vous écrivez encore et encore les mêmes instructions et il est facile de perdre la trace de toute la logique.

---

Déclaratif : un monde d'intentions et de modèles

Regardons maintenant une conception plus déclarative. Au lieu d'indiquer au système comment récupérer chaque ressource, vous décrivez à quoi chaque ressource ressemble, où elle se trouve et comment elle se rapporte aux autres. Ensuite, vous laissez un adaptateur ou un gestionnaire flexible gérer les détails sous le capot.

Voici un exemple :

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
}

À première vue, cela peut sembler plus complexe car nous avons des classes, des propriétés statiques et des adaptateurs. Mais regardez de plus près :

• Aucune URL codée en dur partout : l'URL de base, le point de terminaison et les en-têtes sont définis une fois au niveau de la classe. Toute demande pour ce modèle utilise automatiquement ces valeurs par défaut.
• Relations déclarées, non forcées : CustomUser définit une méthode _post qui renvoie les publications liées à l'utilisateur. Cela ressemble presque à une requête, pas à un tas de code impératif. Vous déclarez votre intention : "Je veux des publications pour cet utilisateur."
• Étendez et personnalisez facilement : Besoin d'une logique personnalisée pour récupérer les publications ? Remplacez simplement all() dans PostAdapter. En faisant de cette logique une extension propre du comportement par défaut, vous réduisez le risque de casser accidentellement quelque chose d'autre.

En d’autres termes, vous construisez un système qui ressemble plus à un ensemble de déclarations qu’à un ensemble d’instructions. Les adaptateurs et les modèles forment un modèle sur lequel le reste du code peut s'appuyer, plutôt qu'un cluster ad hoc d'appels axios.get() aléatoires.

---

La vraie victoire : respecter l’intelligence de votre développeur

Pourquoi faire cet effort ? Parce qu’à mesure que les projets se développent, vous ne voulez pas perdre de temps à naviguer dans un champ de mines de logique impérative. La conception déclarative définit les attentes :

• Quand vous voyez CustomUser.objects.all(), vous savez immédiatement ce que cela signifie : il renvoie un itérateur de toutes les instances de CustomUser. Aucune hypothèse.
• Lorsque vous déclarez static adapter = UserAdapter;, vous savez que toute opération de données sur CustomUser utilise UserAdapter sous le capot. La cohérence et la clarté sont intégrées.
• Lorsque vous définissez un schéma statique sur un modèle, vous pouvez être sûr que le système sait comment valider ou gérer ces champs sans que vous ayez à réécrire du code impératif répétitif.

Cette approche respecte votre intelligence de développeur. Cela ne vous oblige pas à rappeler quel point de terminaison appartient à quel modèle ou où les en-têtes sont définis. Au lieu de cela, il vous permet de réfléchir à un niveau supérieur : définissez à quoi ressemblent vos données et comment elles sont liées, et laissez le framework gérer le reste.

---

Il ne s’agit pas d’être « le meilleur », mais d’être durable

Nous ne prétendons pas qu’une approche déclarative avec des adaptateurs et des champs statiques est universellement meilleure qu’un code impératif brut. Pour un petit script, axios.get() pourrait suffire. Mais à mesure que les systèmes évoluent, l'approche déclarative crée un environnement durable où les changements sont moins pénibles, les fonctionnalités sont plus faciles à ajouter et la complexité globale est gérée avec élégance.

On pourrait dire qu'il s'agit de créer un système qui vous traite, vous, le développeur, plus comme un ingénieur intelligent et moins comme un transcripteur d'instructions.

---

Conclusion

L'approche déclarative peut sembler étrangère au début si vous avez l'habitude d'écrire chaque étape à la main. Mais une fois que vous ressentez le calme d'avoir un modèle cohérent, des points de terminaison clairement déclarés et un endroit pour ajouter proprement une logique personnalisée, il devient difficile de revenir à l'étalement impératif.

Il ne s’agit pas de prouver sa supériorité. Il s’agit de proposer une approche plus respectueuse de votre futur moi, plus respectueuse de votre temps et plus en phase avec votre perception des données et des relations. Au lieu de microgérer chaque demande, vous écrivez du code qui se lit comme une histoire, en vous concentrant sur ce que vous voulez, et non sur tous les détails fastidieux de comment pour l'obtenir.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!