Question

I’m not sure I really understand dependency management. Does it mean you’re only not dependent on the details of another class? It doesn’t mean have anything to do with the call itself correct? I keep hearing to make smaller more specific class but they can’t depend on each other and this doesn’t seem possible to me. Can someone try to simply explain this to me. I put some examples below.

//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);
     }
}

There can be only set of settings per run, so why would I want to keep hitting the database everytime a new class is called?? Is this a bad dependency

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) { //... }
    }
}

Answer 1

Certainly if you’re using resource-intensive actions like calling a database, you can probably justify breaking a design pattern for the sake of performance. That said, I’m not certain this is always a bad practice – I’m pretty sure there are examples in the .NET framework (among others, I’d bet) that are pretty tightly coupled, though I doubt you’ll see a lot of that exposed to the public. If you do break a design pattern, though, you may want to document what’s going on and why, especially if someone else will ever look at or maintain this code, and internalize as much as you can.