Dependency Management Question

I'm not sure I really understand dependency management. Doe开发者_开发知识库s 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) { //... }
    }
}

---

Dependency Management is a practice to avoid a large code base to become un-maintainable. We can say that a code base is un-maintainable when it looks like a plate of spaghettis if you try to understand how it is structured!!

Dependency Management consists in grouping code artifacts like classes, in chunk named components and check that the dependencies between components remains understandable and sane (by avoiding flaws like dependency's cycles).More details in this article: Control component dependencies to gain clean architecture

---

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.