Welcome to the Lounge

Eric Lynch wrote:

Nowadays, they seem to use their customers as a QA department.

Herbie Mountjoy wrote:

All this stuff gets re-installed whenever I try to remove it.

public class DatabaseClass
{
   public List<Customer> GetCustomers()
   {
      // Get customers...
   }
}

public class BusinessLogicClass
{
   public int GetCustomerCount()
   {
      var db = new DatabaseClass();
      var customers = db.GetCustomers();
      // Use customers...
   }
}

public interface IDatabaseClass
{
   List<Customer> GetCustomers();
}

public class DatabaseClass : IDatabaseClass
{
   public List<Customer> GetCustomers()
   {
      // Get customers...
   }
}

public class BusinessLogicClass
{
   private readonly IDatabaseClass db;

   public BusinessLogicClass(IDatabaseClass db)
   {
      this.db = db;
   }

   public int GetCustomerCount()
   {
      var customers = db.GetCustomers();
      // Use customers...
   }
}

// Production code.
var bl = new BusinessLogicClass(new DatabaseClass());
var count = bl.GetCustomerCount();
// Do something with count.

// Testing code.
var bl = new BusinessLogicClass(new MyMockObject()); // Use a mocking framework instead!
var count = bl.GetCustomerCount();
// We know our mock object returns 5, but with an actual database we couldn't say.
Assert.Equals(5, count);

TNCaver wrote:

code that uses an external object still has to know about it's properties and methods in order to use them, so how does passing the object or interface to the constructor or a setter make the code any less dependent than using the concrete object with the 'new' keyword?

TNCaver wrote:

I'm learning about DI, and it kind of makes sense, but I'm not convinced it solves the loose coupling issue.

Slacker007 wrote:

I think you may have scared him off. I know I would be if I didn't know any better. Just saying...