依赖性 C#
近来看了一些外国人写的书籍，
发现了一个不太习惯的地方：
那就是他们写程序的时候喜欢写一个接口 ， 比如：
public interface IProductRepository
{
IQueryable<Product> Products { get; }
void SaveProduct(Product product);
void DeleteProduct(Product product);
}//end interface
然后写一个具体的类来继承接口
public class EFProductRepository : IProductRepository
{
//具体不写了
}
最后就是将类模型绑定到 ninject 中
ninjectKernel.Bind<IProductRepository>().To<EFProductRepository>();
后面程序里面用的时候，就用：
IProductRepository repository这个就行了！！
我的问题是：为什么一开始不直接写具体的EFProductRepository ， 用的时候就直接用EFProductRepository ，接口看起来很多余！
我看别人的说法是：使用di容器（比如刚才的ninject）可以保持松散耦合，什么叫松散耦合，什么叫依赖性啊？？
[解决办法]
就是说比如
A调用B，那么A依赖B，如果我们需要让A调用C，那么就要修改A的代码。
class A
{
public void foo()
{
//B b = new B();
//b.bar();
C c = new C();
c.bar();
}
}
class B
{
public void bar()
{
...
}
}
class C
{
public void bar()
{
...
}
}
为什么我们要让A调用C？比如B是一个SQL Server数据库的访问层，C是一个MySQL的访问层，A是BLL，现在我们要替换实现，那么就需要修改A了。
我们希望A不修改，怎么办？
class A
{
Public I dal;
public void foo()
{
dal.bar();
}
}
interface I
{
void bar();
}
class B : I
{
public void bar()
{
...
}
}
class C : I
{
public void bar()
{
...
}
}
我们只要在实例化A的时候通过传递不同的I接口的对象（B或者C）就可以让A调用某个特定的实现而不用修改A 的代码了？
为什么我们那么在意修改A的代码？因为可能A是封装在一个dll中的。或者是另一个团队开发的。这在大型项目中很常见。
[解决办法]
我有一个方法，可以对所有的集合类型的数据进行处理，看起来是准格尔样子的：
public void ProcessSet(/*神秘的入参*/)
{
//......
}
public void ProcessSet(IEnumerable set)
{
//......
}
