Le découplage des interfaces et d'une manière générale l'assignation des responsabilités entre les classes / librairies / composants c'est de loin l'aspect le plus délicat du métier de développeur à mon avis. Si c'est mal fait c'est difficile à rattraper et les conséquences peuvent être dramatiques. J'ai personnellement abandonné plusieurs projets des suites d'un mauvais design à cause d'une répartition des rôles inadaptée au besoin / projet.
Par exemple, j'avais créé pour mon besoin une couche DAO complète qui consistait en un assemblage d'au moins 7 layers entre l'API exposée par la couche DAO et l'exécution concrète des requêtes. A la fin, je me suis rendu compte que d'une part c'était beaucoup trop complexe pour mon besoin initial et d'autre par que ça ne couvrait pas tous les usages et que les nouveaux étaient difficiles voire impossible à faire rentrer dans le modèle.
Il n'y a pas de règle formelle pour découpler correctement des interfaces, il existe de nombreux patterns pour adresser ce problème mais il n'existe pas de vérité absolue, ça dépend totalement de ton besoin et de tes compétences. Ce n'est pas quelque chose qui s'apprend, tu dois l'expérimenter toi même et faire tes propres erreurs pour trouver ton style.
On peut néanmoins considérer acceptable que deux classes qui on vocation à travailler ensemble puissent être couplées si (et seulement si) elles sont dans le même composant. Par exemple, l'objet MySQLObject peut déléguer la construction des requêtes SQL à MySQLQueryBuilder (car ils sont tous les deux dans le composant model/mysql). En revanche il est tout à fait inapproprié de faire travailler ensemble ArticlesController et PDO car il s'agit là de deux aspects complètement séparés.
Concernant le script boostrap.php, on peut également l’appeler init.php ou config.php ou autre. Il s'agit juste d'un script qui rassemble toute la logique d'initialisation de l'application (on appelle généralement cette phase le boostrap ou bootstraping). C'est là qu'on va définir la conf (ou la charger depuis un fichier), déclarer nos adaptateurs, définir la logique ACL etc.etc. Bref, tout ce dont l'application aura besoin lors du runtime.
Les tests sont également un point important dans la réalisation et la conduite d'un projet informatique. Ils permettent de valider que le projet, sa forme et son comportement sont conformes aux attentes fonctionnelles et techniques. Il y a plusieurs niveaux: test unitaires, test fonctionnels, tests de charge etc. Ils sont généralement outrepassés pour des raisons de coûts et de délais mais il faut bien comprendre que les tests font partie intégrante de la démarche de qualité au même titre que l'analyse et conception. Sans eux, comment valider que ce qu'on a écrit ou modifié fonctionne et est toujours valide au regard des spécification ?
Mon conseil: adopte une approche qui ressemble au TDD et décris tes tests avant d'écrire le code, je ne sais que trop bien combien on a la flemme d'écrire les tests après la lib ;)
Les tutos sur le net n'abordent pas ces points, ils se concentrent en général sur l'aspect purement technique, c'est pour ça que j'ai écrit un article dénonçant le "tout tuto" qui se pratique ouvertement sur le web de nos jours.
A toi de voir mais l'informatique est une maîtresse exigeante qui demande beaucoup de temps et d'investissement personnel.Citation:
je n'ai pas suffisamment de temps/motivation pour approfondir les cours un peu obscurs que je trouve sur internet
Mes indication sont relativement creuses, je ne suis pas un prof, je te donne des pistes à suivre, libre à toi d'aller au bout ou non. Je n'ai pas le temps de faire du coaching ou de l'enseignement à plein temps, comme beaucoup ici, je me contente de mettre les jeunes développeurs sur la voie (du moins j'essaie en tenant compte de ma propre expérience).
C'est à toi de jouer maintenant, il n'y a pas de vérité absolue et tant que ça marche et que t'en est content, finalement c'est tout ce qui compte.
