Nécessité d'interfaces, injections dans un projet unique

Question

Pourquoi devrais-je implémenter des interfaces et une injection de dépendances sur un site avec aucune chance de les réutiliser ou de les mettre à niveau par quiconque?

Answer 1

Lorsque vous avez appris à programmer un ordinateur, vous développiez une sorte de "mémoire musculaire" de votre art. Au fil des ans, vous continuez à programmer dans le même état d'esprit. La plupart des gens n'apprennent pas tous les principes astucieux de la POO dès le début, alors ils semblent avoir plus d'efforts que la façon dont ils ont appris.

Vous devriez prendre l’habitude d’utiliser des techniques de conception POO chaque fois que vous utilisez un langage POO, car cela ferait de vous un meilleur développeur dans l’ensemble. Votre objectif devrait être de réorganiser votre mémoire musculaire de programmation pour utiliser ces techniques. Ensuite, vous n'aurez pas à poser ces questions et à supposer que les techniques «gênent» votre programmation. Vous devenez un programmeur qui programme simplement de cette façon.

Answer 2

Cela simplifie souvent les tests unitaires. Par exemple, vous pourriez avoir un type qui utilise un autre type qui se connecte à une base de données. Pour les tests unitaires du premier type, vous pouvez injecter une maquette de test à la place du second type, ce qui vous permet de tester efficacement le premier type sans se connecter indirectement à la base de données via le second type.

Answer 3

Pourquoi, en effet?

Je ne pense pas que les interfaces et l'injection concernent uniquement la réutilisation ou la mise à niveau.

Personnellement, j'utilise des interfaces et des ID pour tous les projets. Les frais généraux ne suffisent pas pour faire en sorte que les éviter soit un avantage.

Answer 4

Parce que l’hypothèse que vous faites est la même que celle qui a abouti à l’an 2000.

Answer 5

Je trouve qu'il est beaucoup plus facile de réutiliser mon code d'une manière que je n'avais pas encore pensée. Cela facilite également la modification du code sans changer le code source.

J'utilise Spring.NET pour l'injection de dépendance.

Disons que vous avez une classe Machine qui a une fonction DoWork (). Ensuite, vous créez une interface IWorkAlgorithm, avec des implémentations d’algorithmes spécifiques pour chaque machine.

Chaque instance de Machine contient un algorithme IWorkAlgorithm, et Machine.DoWork () appelle l'implémentation injectée.

Maintenant, vous bénéficiez des avantages suivants:

1. Vous pouvez permuter de nouvelles implémentations simplement en modifiant un fichier XML.
2. Vous pouvez modifier les propriétés de chaque implémentation (délais d'expiration, limites, etc.) en modifiant un fichier XML.
3. Vous pouvez réutiliser vos implémentations en dehors de la classe Machine.

Answer 6

Si vous faites de la programmation orientée objet, même si vous êtes le seul développeur à consulter le code, vous devriez quand même effectuer des tests unitaires, ce qui devient compliqué si vous n'utilisez pas l'injection de dépendance.

N'oubliez pas que le " autre développeur " sur votre logiciel peut très bien être vous. Vous pouvez pirater ensemble une masse de code hautement couplé et interdépendant qui fonctionne, et même la comprendre pendant que vous y travaillez, mais dès que vous vous retirez du projet, même pendant quelques jours, vous commencerez d'oublier toutes les petites choses qui ont empêché la pelote de se défaire.

Lorsque vous y reviendrez (et je n'ai pas encore vu de logiciel ne nécessitant pas de modifications ultérieures), vous souhaiterez avoir suivi toutes les meilleures pratiques.