PHP pourquoi n'est-il pas bon d'initier une connexion à une base de données dans une construction ?

Question

Je lisais un article de blog quand je suis tombé sur ce code :

<?php
include_once 'config.php';
class User
{
//Database connect 
public function __construct() 
{
$db = new DB_Class();
}

Dans les commentaires, quelqu'un a posté ce qui suit :

NE JAMAIS INITIER la connexion db dans le constructeur

Mais comme avec tous les guerriers de commentaire ils ne donnent jamais une raison pourquoi ? Pourquoi est-ce mal ou une mauvaise pratique à faire ?

Answer 1

Les constructeurs ne doivent pas faire de travail réel :

Le travail dans le constructeur tel que : la création/initialisation des collaborateurs, la communication avec d'autres services, et la logique pour mettre en place son propre état supprime les coutures nécessaires pour les tests, forçant les sous-classes/mocks à hériter de comportements non désirés. Trop de travail dans le constructeur empêche l'instanciation ou la modification des collaborateurs dans le test.

Au lieu de cela, utilisez Injection de dépendances et passe tout collaborateur au constructeur. Cela permettra de créer un code plus facile à tester. Lorsque vous new quelque chose dans le ctor, il est beaucoup plus difficile de faire un simulacre/une souche avec un Test double .

De plus, en injectant des collaborateurs, vous facilitez l'échange de collaborateurs avec des implémentations différentes, ce qui réduit les risques d'erreur. accouplement l'encouragement réutilisation du code y codage vers des interfaces plutôt que des implémentations concrètes .

Answer 2

Le passage d'une instance de la base de données au constructeur est appelé "injection de dépendance". Cela permet de découpler les objets, c'est-à-dire de réduire les dépendances entre les objets. L'un des avantages du découplage est une plus grande flexibilité du système, une maintenance plus facile et l'écriture de tests unitaires.

Mais vous pouvez profiter de tous ces avantages principalement si vous construisez vos logiciels en utilisant des modèles de conception, en pratiquant le développement piloté par les tests et une architecture bien définie - comme par exemple dans la conception pilotée par le domaine.

Mais si vous commencez seulement à explorer la méthode de développement de logiciels basée sur la POO ou à apprendre la programmation en général, vous ne devriez peut-être pas vous poser ce genre de questions pour l'instant.

Answer 3

Je dirais que l'initialisation d'une connexion DB dans un constructeur viole le contrat général pour un constructeur. Lorsque vous faites new User() vous vous attendez à obtenir un objet décrivant un utilisateur. Si cela nécessite une connexion à la base de données qui fonctionne, quel est l'état de l'objet si l'établissement de la connexion échoue ? Un constructeur ne devrait pas lever une exception, parce que son seul but est d'assurer l'état correct de l'objet. (Du moins c'est mon point de vue... Je sais que d'autres personnes ne pensent pas que les exceptions des constructeurs sont mauvaises. Cependant, je le fais).

Et en plus : Vous ne pouvez pas réutiliser la connexion à la base de données si elle est encapsulée dans un objet.

Answer 4

Dans ce cas particulier, peut-être un modèle pour travailler avec les données des utilisateurs, il peut être très utile. Mais que se passe-t-il si vous voulez soudainement que cette classe soit portable et fonctionne avec une autre base de données ? J'ai moi-même rencontré ce problème lorsque j'ai voulu utiliser ma classe de gestion des utilisateurs dans un autre projet.