Les Abstractions ne devraient pas dépendre des détails. Les détails devraient dépendre des abstractions?

au cours des derniers jours, j'ai lu pas mal de choses sur l'injection de dépendance/inversion du contrôle/inversion de la dépendance. J' penser cela, maintenant ma compréhension du concept est beaucoup mieux. Mais je ne reçois toujours pas ce qui suit de wikipedia:

A. Les modules de haut niveau ne devraient pas dépendent de modules de bas niveau. Les deux devrait dépendre des abstractions. B. Les Abstractions ne devraient pas dépendre des détails. Détails dépendent abstraction.

je comprends la partie du les modules de haut niveau ne devraient pas dépendent de modules de bas niveau. mais, je suis confus au sujet des abstractions et des détails.Quelqu'un peut-il svp de les simplifier pour moi. Grâce.

19
demandé sur Sandbox 2009-11-10 21:09:18

4 réponses

Cela signifie que si les détails changent, ils ne devraient pas affecter l'abstraction. L'abstraction est la façon dont les clients voient un objet. Exactement ce qui se passe à l'intérieur de l'objet n'est pas important. Prenons l'exemple d'une voiture: les pédales, le volant et le levier de vitesses sont des abstractions de ce qui se passe à l'intérieur du moteur. Ils ne dépendent pas des détails cependant parce que si quelqu'un change mon vieux moteur pour un nouveau je devrais encore être en mesure de conduire la voiture sans savoir que le moteur modifié.

D'un autre côté, les détails doivent être conformes à ce que dit l'abstraction. Je ne voudrais pas mettre en place un moteur qui fait soudainement doubler la vitesse de la voiture. Je peux remettre les freins en place de la façon que je veux tant qu'ils se comportent extérieurement de la même manière.

31
répondu Vincent Ramdhanie 2009-11-10 18:16:30

Un cas intéressant où une abstraction dépend des détails, c'est quand vous définissez une interface qui hérite de IDisposable. Regardez l'abstraction suivante:

public interface ICustomerRepository : IDisposable
{
    Customer GetById(Guid id);
    Customer[] GetAll();
}

Remarque::IDisposable est une interface spécifique .NET, mais vous pouvez facilement imaginer votre interface contenant un Dispose la méthode elle-même au lieu d'hériter d'une telle interface.

Ça peut paraître commode pour l' ICustomerRepository à mettre en oeuvre IDisposable. De cette façon, tout appelant peut disposer du dépôt et de cette façon, l'implémentation peut disposer de la connexion ou de l'Unité de travail qu'elle utilise en interne.

l'interface cependant est maintenant écrite avec une certaine implémentation à l'esprit, puisque ce n'est pas évident du tout que tout ICustomerRepository implémentations aurait besoin de nettoyer toutes les ressources. L'interface fuit donc les détails d'implémentation et viole donc le principe de L'Inversion de dépendance.

3
répondu Steven 2014-06-20 14:17:43

Exemple de l'abstraction et les détails: un flux fournit une interface pour lire un jeton. C'est une abstraction.

une implémentation stream du stream est liée à l'implémentation de l'interface définie par l'abstraction: c'est pourquoi elle en dépend. S'il fournit une interface différente (une pour lire 100 caractères à la fois), il ne peut prétendre implémenter la même abstraction.

1
répondu xtofl 2009-11-10 18:16:41

pensez au travail que vous devez invoquer, et à quelle distance c'est de l'endroit où vous codez actuellement. Il y a un spectre, il y; votre position représente la quantité de travail que vous devez faire pour invoquer cette fonctionnalité.

Abstractions déplacez cette position plus près du code que vous écrivez. Par exemple, si vous devez appeler un service web, vous pouvez soit 1) écrire le code d'appel directement où vous devez l'utiliser, ou 2) mettre ces détails derrière une abstraction (comme un interface.)

dans ce cas, #1 vous rapproche du service web sur le spectre, tandis que #2 vous rapproche de votre travail. L'Abstraction peut être considérée comme une mesure de la mesure dans laquelle vous devez étirer votre esprit pour comprendre le travail que vous devez faire.

cela signifie que chaque travail peut être abstrait de sorte qu'il soit "plus proche" du code qui l'utilise. En ayant les deux côtés d'une opération dépend des abstractions, ils deviennent plus faciles à comprendre, et ni côté doit abriter la connaissance du fossé entre eux - c'est le travail de l'abstraction.

Wow, c'était abstrait.

1
répondu Bryan Watts 2009-11-20 21:22:13