La Corée du Sud est-elle une « république Spring » ?
Si vous voulez être recruté comme développeur backend en Corée, il y a une question à laquelle vous échapperez difficilement : « Vous savez utiliser Spring ? »
Sur les sites d’emploi, neuf offres sur dix mentionnent explicitement « expérience avec Spring Boot » dans les prérequis. Au point qu’on parle même de « république Spring ». À l’université, je pensais que ce n’était qu’une mode.
« Pourquoi ne pas simplement coder en Java ? Pourquoi s’embêter avec un Spring aussi lourd ? » « Node.js ou Python (Django), ce n’est pas plus simple ? »
Mais une fois confronté à la réalité des grands projets, j’ai compris. Spring n’était pas une simple tendance, mais un établi standard façonné au fil du temps par d’innombrables développeurs expérimentés afin de construire des systèmes d’entreprise immenses et complexes de manière sûre et rapide.
Cette série raconte justement comment construire, sur cet établi standard, un château qui ne s’effondre pas : un Monolith.
Framework : pourquoi on ne peut pas tout faire à sa manière
Avant d’entrer dans le vif du sujet technique, il faut clarifier un point. Qu’est-ce qu’un framework, exactement ? Et en quoi diffère-t-il d’une bibliothèque ?
Je l’avais brièvement évoqué dans la série Re: Booting, mais la différence décisive entre les deux tient en une question : qui garde l’initiative ?
Spring est un framework. Utiliser Spring, c’est donc presque signer une promesse : « Je vais mettre un peu de côté ma façon personnelle de coder et suivre les règles imposées par Spring. » Le cœur de ce « faire comme Spring le demande », c’est justement le sujet du jour : l’inversion de contrôle (IoC).
« S’il vous plaît, arrêtez d’utiliser new partout »
La première règle de cette promesse m’avait choqué. Elle disait en substance : n’utilisez plus new, pourtant l’un des fondamentaux les plus basiques de Java.
À l’université, si j’avais besoin d’un objet, j’écrivais naturellement MemberService service = new MemberService();. Si j’ai besoin de quelque chose, je le crée moi-même et je l’utilise. Quoi de plus logique ?
Mais après mon entrée dans le monde professionnel, quand j’ai ouvert un projet Spring Boot, impossible de trouver le mot-clé new dans le code. À la place, il y avait partout des annotations comme @Autowired ou @RequiredArgsConstructor.
« Attendez, si personne ne crée l’objet, comment la méthode est-elle appelée ? Ce truc fonctionne vraiment ? »
Quand j’ai posé la question à un développeur senior, sa réponse m’a semblé terriblement floue : « Le Spring Container l’injecte automatiquement, donc on n’a pas besoin de le créer nous-mêmes. Au contraire, si tu utilises directement new, le code sera bien plus difficile à maintenir plus tard. »
Je n’arrivais pas à l’accepter. J’étais le propriétaire du code que j’écrivais, alors pourquoi ne pouvais-je même pas créer librement un objet ? J’avais l’impression de subir une dictature de Spring.
Le chef et le responsable des ingrédients (IoC & DI)
Pour comprendre pourquoi cette règle qui ressemble à une forme d’autorité est nécessaire, changeons de métaphore et passons dans la cuisine d’un restaurant.
1. La méthode traditionnelle (c’est moi qui décide)
Je suis un chef, donc une Class. Pour cuisiner, j’ai besoin d’un couteau, donc d’une Dependency.
2. La méthode Spring (c’est Spring qui décide)
Je suis toujours le chef. Mais cette fois, il y a un gestionnaire des ingrédients et des outils : le Spring Container.
Autrement dit, au lieu de gérer moi-même les ressources dont j’ai besoin, une entité extérieure les gère et me les fournit. C’est exactement cela, l’inversion de contrôle (IoC: Inversion of Control), et la technique concrète qui permet de le faire s’appelle l’injection de dépendances (DI).
[Code Verification] Pourquoi new est-il dangereux ?
En rester aux mots ne suffit pas pour bien le sentir. Comparons-le directement dans du code. Imaginons que nous construisions un système de paiement par carte.
1. Mauvais exemple : instanciation directe (couplage fort)
public class PaymentService {
// Jai choisi et cree moi-meme une Samsung Card (avec new)
private final SamsungCard card = new SamsungCard();
public void pay() {
card.payment(); // Paiement possible uniquement avec Samsung Card
}
}
Le problème : un jour, le patron dit : « Passons à Hyundai Card, les frais sont moins élevés ! » À ce moment-là, il faut ouvrir le code de PaymentService et remplacer partout SamsungCard par HyundaiCard. Et si ce code existe à cent endroits différents ? Les heures sup sont garanties.
2. Bon exemple : injection de dépendances (couplage faible)
public class PaymentService {
private final Card card; // Ne pas specifier de fournisseur concret (utiliser linterface)
// Injection par constructeur : faire confiance au fait que quelquun fournira la carte de lexterieur
public PaymentService(Card card) {
this.card = card;
}
public void pay() {
card.payment();
}
}
Désormais, PaymentService se moque de l’implémentation concrète de carte qu’on lui fournit.
C’est précisément le cœur de ce qu’on appelle en pratique un « code facile à maintenir », ou le principe OCP. Et c’est exactement pour cette souplesse qu’on utilise Spring Boot.
Spring Container : un hôtel pour les objets
Alors qui est ce « gestionnaire » qui crée les objets et les distribue ? C’est précisément le Spring Container.
Au moment où l’on démarre un serveur Spring Boot avec run, énormément de choses se passent en interne.
Notre rôle consiste seulement à coller une étiquette sur la classe qui dit en substance : « merci de gérer ceci », avec par exemple @Service. Pour le reste, Spring s’en charge, comme l’immense directeur d’un hôtel qui organise tous ses clients.
Conseil pratique : utilisez l’injection par constructeur
Spring propose plusieurs manières d’injecter des dépendances : injection de champ avec @Autowired, injection par setter ou injection par constructeur. Mais dans les projets réels, on recommande presque toujours l’injection par constructeur. C’est le modèle souvent utilisé avec @RequiredArgsConstructor de Lombok.
@Service
@RequiredArgsConstructor // Cela genere automatiquement linjection par constructeur.
public class OrderService {
// final peut etre utilise, donc cest sur
private final PaymentService paymentService;
}
Pourquoi ?
Pour conclure : pas un magicien, mais un chef d’orchestre
Au début, Spring me rebutait parce que j’avais l’impression qu’il manipulait mon code à sa guise. Aujourd’hui, je le vois autrement. Spring n’est pas un dictateur qui me complique la vie, mais un chef d’orchestre compétent qui organise des relations complexes entre les objets.
Grâce à cela, je passe moins de temps à me demander « quel objet dois-je créer ? » et davantage à réfléchir à « comment construire la logique métier avec cet objet ? ». C’est probablement pour cela que tant de développeurs en Corée continuent de faire confiance à Spring.
Nous avons maintenant confié la gestion des objets à Spring. Le serveur est prêt à démarrer. Mais une application web ne tourne pas seule : elle doit dialoguer avec le frontend. À l’époque de PHP, c’était pratique parce que HTML et code cohabitaient dans un seul fichier. Alors pourquoi sépare-t-on aujourd’hui le frontend, avec Vue ou React, du backend ? Et pourquoi une erreur CORS en rouge apparaît-elle dès qu’on essaie de relier les deux ?
La prochaine fois, nous examinerons l’évolution de l’architecture web, SSR vs CSR, ainsi que la véritable nature de CORS, ce mur qui se dresse entre les deux.