32 votes

L'injection de dépendance n'est-elle qu'un autre nom pour le modèle de stratégie?

Ces termes sont-ils identiques ou existe-t-il des différences importantes entre l'injection de dépendance et le modèle de stratégie? Il me semble que Martin Fowler vient de renommer le modèle de stratégie avec un nom plus accrocheur. Me manque-t-il quelque chose?

28voto

James Black Points 26183

Vous pouvez utiliser DI en tant que modèle de stratégie. Vous pouvez ainsi basculer dans l'algorithme requis pour chaque client. Toutefois, DI peut aller au-delà car il s'agit d'un moyen de découpler les parties d'une application, ce qui ne ferait pas partie intégrante de l'application. le modèle de stratégie.

Il serait risqué de dire que l'ID n'est qu'un modèle de stratégie renommé, car cela commence à diluer l'objectif de ce modèle, l'OMI.

7voto

Edward Ames Points 119

Les stratégies sont de niveau supérieur, les choses qui sont utilisés pour modifier la façon dont les choses sont calculés. Avec l'injection de dépendance, vous pouvez changer non seulement la façon dont les choses sont calculés, mais aussi de changer ce qui est là.

Pour moi, il devient clair lors de l'utilisation de tests unitaires. Pour la production de l'exécution du code, vous avez toutes les données cachées (c'est à dire privés ou protégés); attendu que, avec les tests unitaires, la plupart des données sont publiques, donc je peux la regarder avec l'Affirme.


Exemple de stratégie:

public class Cosine {
  private CalcStrategy strat;

  // Constructor - strategy passed in as a type of DI
  public Cosine(CalcStrategy s) {
    strat = s;
  }
}

public abstract class CalcStrategy {
  public double goFigure(double angle);
}

public class RadianStrategy extends CalcStrategy {
  public double goFigure(double angle) {
    return (...);
  }
}
public class DegreeStrategy extends CalcStrategy {
  public double goFigure(double angle) {
    return (...);
  }
}

Notez qu'il n'existe pas de données publiques qui est différent entre les stratégies. Il n'existe différentes méthodes. Les deux stratégies partagent tous les mêmes fonctions et de signatures.


Maintenant, pour l'injection de dépendance:

public class Cosine {
  private Calc strat;

  // Constructor - Dependency Injection.
  public Cosine(Calc s) {
    strat = s;
  }
}

public class Calc {
  private int numPasses = 0;
  private double total = 0;
  private double intermediate = 0;

  public double goFigure(double angle) {
    return(...);
}

public class CalcTestDouble extends Calc {
  // NOTICE THE PUBLIC DATA.
  public int numPasses = 0;
  public double total = 0;
  public double intermediate = 0;
  public double goFigure(double angle) {
    return (...);
  }
}

Utilisation:

public CosineTest {

  @Test
  public void testGoFigure() {
    // Setup
    CalcTestDouble calc = new CalcTestDouble();
    Cosine instance = new Cosine(calc);

    // Exercise
    double actualAnswer = instance.goFigure(0.0);

    // Verify
    double tolerance = ...;
    double expectedAnswer = ...;
    assertEquals("GoFigure didn't work!", expectedAnswer,
         actualAnswer, tolerance);

    int expectedNumPasses = ...;
    assertEquals("GoFigure had wrong number passes!",
        expectedNumPasses, calc.numPasses);

    double expectedIntermediate = ...;
    assertEquals("GoFigure had wrong intermediate values!",
        expectedIntermediate, calc.intermediate, tolerance);
  }
}

Avis les 2 dernières vérifications. Ils ont utilisé des données publiques dans le test double de ce qui a été injecté dans la classe sous test. Je ne pouvais pas le faire avec le code de production en raison de données masquage de principe. Je ne voulais pas avoir de but spécial de tests de code inséré dans le code de production. Les données publiques devait être dans une autre classe.

Le test de double a été injecté. C'est différent que de simplement une stratégie puisqu'il affectait de données et pas seulement les fonctions.

4voto

L'injection de dépendance est un raffinement du modèle de stratégie que je vais brièvement expliquer. Il est souvent nécessaire de choisir entre plusieurs alternatives de modules au moment de l'exécution. Ces modules de tout mettre en œuvre une interface commune, de sorte qu'ils peuvent être utilisés de façon interchangeable. Le but de la stratégie de modèle est de supprimer le fardeau de la décision sur les modules à utiliser (c'est à dire qui "béton" de stratégie ou de dépendance) en encapsulant le processus de prise de décision dans un objet distinct qui je vais appeler la stratégie de l'objet.

L'injection de dépendance affine le modèle de stratégie par pas seulement de décider de ce qui concrètes de la stratégie à utiliser, mais la création d'une instance de la stratégie concrète et "injecter" dans le module appelant. Ceci est utile, même s'il n'existe qu'une seule dépendance de la connaissance de la façon de gérer (initialiser etc) la stratégie concrète instance peut également être caché à l'intérieur de la stratégie de l'objet.

1voto

Calvin Points 137

En fait, l’injection de dépendance est également très similaire au modèle Bridge. Pour moi (et selon la définition), le modèle Bridge doit prendre en charge différentes versions de la mise en œuvre, tandis que le modèle Stratégie concerne une logique totalement différente. Mais l'exemple de code semble utiliser DI. Alors peut-être que DI est juste une technique ou une implémentation?

0voto

Blue Clouds Points 322

La stratégie est une arène pour utiliser votre dépendance à l'injection de compétences. Des moyens concrets pour mettre en œuvre l'injection de dépendance sont comme suit:-

  1. Les événements
  2. Les fichiers de Configuration de l'unité ou de la structure de la carte(ou par programmation) etc.
  3. Les Méthodes D'Extension
  4. Abstrait modèle de Fabrique
  5. L'Inversion de modèle de contrôle(utilisé par la stratégie et de l'Abrégé de l'Usine)

Il y a une chose qui rend la stratégie tient une place à part. Comme vous le savez, dans l'Unité au démarrage de l'application toutes les dépendances sont ensemble et nous ne pouvons pas changer cela plus loin. Mais la stratégie runtime prend en charge la dépendance de changement. Mais NOUS avons à gérer et à injecter de la dépendance, pas de la responsabilité de la Stratégie!

En fait la stratégie de ne pas parler de l'injection de dépendance. Si besoin, il peut être fait par le biais de l'Abrégé de l'Usine à l'intérieur d'un modèle de Stratégie. La stratégie ne parle que de la création d'une famille de classes de l'interface et de "jouer" avec elle. Pendant la lecture, si nous constatons que les classes sont dans un autre niveau, alors nous devons injecter soi-même, mais pas l'emploi de la Stratégie.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X