2010-08-26 5 views
1

Je ne suis pas sûr de comprendre vraiment la gestion des dépendances. Cela signifie-t-il que vous n'êtes pas dépendant des détails d'une autre classe? Cela ne signifie pas avoir quelque chose à voir avec l'appel lui-même correct? Je n'arrête pas d'entendre pour faire des classes plus petites et plus spécifiques mais elles ne peuvent pas dépendre l'une de l'autre et cela ne me semble pas possible. Quelqu'un peut-il essayer de me l'expliquer simplement? J'ai mis quelques exemples ci-dessous.Gestion des dépendances Question

//Bad Dependency 
public class TestOne 
{ 
    TestTwo testTwo; 
    public void TestOneMethod() 
    { 
      testTwo = new TestTwo(); 
      testTwo.SomeProperty = "Value"; 
      testTwo.SomeMethodThatWorksWithSomeProperty(); 
    } 
}
//Bad dependency?? 
public class TestOne 
{ 
    TestTwo testTwo; 
    public void TestOneMethod() 
    { 
      int myInt = 0; 
      TestThree testThree = new TestThree(); 
      //... Some Code that works with testThree 

      testTwo = new TestTwo(); 
      myInt = testTwo.GetSomeInteger(testThree); 
    } 
}

Il ne peut être le seul ensemble de paramètres par course, alors pourquoi je veux continuer à frapper la base de données chaque fois qu'une nouvelle classe est appelée ?? Est-ce une mauvaise dépendance


public static class Application 
{ 
    public static int SomeSetting = 0; 
    public static GetSettingsFromDatabase() 
    { 
     //loads the settings for this store 
     DatabaseClass dbClass = DatabaseClassDataSource.LoadForStore(); 
     SomeSetting = dbClass.SomeSetting; 
    } 
} 

public class MyClass 
{ 
    public void MethodOne() 
    { 
     if(Application.SomeSetting == 1) { //... } 
    } 
} 

public class MyClassTwo 
{ 
    public void MethodOne() 
    { 
     if(Application.SomeSetting == 1) { //... } 
    } 
} 

Répondre

0

Certes, si vous utilisez des actions gourmandes en ressources comme appeler une base de données, vous pouvez probablement justifier la rupture d'un modèle de conception pour des raisons de performance. Cela dit, je ne suis pas certain que ce soit toujours une mauvaise pratique - je suis sûr qu'il y a des exemples dans le framework .NET (entre autres, je parie) qui sont assez étroitement couplés, même si je doute que vous verrez beaucoup de ce qui est exposé au public. Cependant, si vous cassez un motif de conception, vous voudrez peut-être documenter ce qui se passe et pourquoi, surtout si quelqu'un d'autre verra ou maintiendra ce code, et intériorisera autant que vous le pouvez.

1

La gestion des dépendances est une pratique qui évite qu'une grande base de code ne puisse être maintenue. Nous pouvons dire qu'une base de code n'est pas maintenable quand elle ressemble à une assiette de spaghettis si vous essayez de comprendre comment elle est structurée !!

La gestion des dépendances consiste à regrouper les artefacts de code comme les classes, en gros morceau des composants nommés et vérifier que les dépendances entre les composants reste compréhensible et sain d'esprit (en évitant les défauts comme les cycles de dépendance) .Plus de détails dans cet article: Control component dependencies to gain clean architecture

Questions connexes