我们在软件工程中进行的架构设计、模块实现、编码等工作，很多时候说到底就是围绕一件事进行：解耦。
三层架构，MVC，微服务，DDD.我们分析问题，抽象问题，然后划分边界，划分层次。
也是为了让我们的类、模块、系统有更强的复用能力，提高生产效率。
这一次，我想深入了解和探讨我曾经很迷糊，也没有一直仔细了解的：依赖倒置、控制反转、依赖注入 这些概念。
什么是依赖？ 通常可以理解为一种需要，需求。需要协助才能完成一件事情。例如，我们依赖日志服务写日志：
public class Contract { public void Successed() { string msg = "save, successed!"; Log log = new Log(); log.Write(msg); } }Contract类正依赖Log类，协助完成整个业务流程。这就产生了依赖。
什么是抽象？ 什么是细节？我们经常会听说，面向接口编程，依赖于抽象不能依赖于具体实现细节。
我们每次修改接口时候，一定会去修改具体实现。但是我们修改具体实现却很少修改接口。
所以接口比具体实现更稳定。
此时，我们在中间加入一层接口，看看如何。
public interface ILog { void Write(); } public void Successed() { string msg = "save, successed!"; ILog log = new Log(); log.Write(msg ); }关系变化如图：
此时，Contract类可以看做上层。Log看做底层。
上层模块：指挥控制
底层模块：策略实现
依赖倒置理清楚了 上层、底层、细节、抽象、依赖概念，
我们不难发现，上面的依赖箭头发生了改变。
所以依赖倒置也由此而来：
上层模块不应该依赖底层模块，它们都应该依赖于抽象。 抽象不应该依赖于细节，细节应该依赖于抽象。依赖倒置，使得我们的扩展性增强。
public class Log:ILog public class NLog : ILog public class Log4 : ILog // ILog log = new Log(); // ILog log = new Log4(); ILog log = new NLog(); log.Write(msg);以上代码我们也可以看出，我们需要不断注释修改Contract类，以至于引用不同的Log组件来应对需求。
每次都要修改这个类来满足需求(修改关闭，扩展开放原则)，显然是我们所不希望的。造成这种现象的原因是：
因为对于上层的Contract类，不仅仅负责业务逻辑的实现，第二职责还要负责日志实例的构造。
对于Program类，有日志服务类直接拿来使用即可，不需要关心这些实例的构造。
有没有一种机制能够将构造和使用进行分离？使得Contract的职责更加单一，耦合更低？（单一职责原则）
控制反转 怎么算是控制反转了呢？我们改一下上面的代码将日志类的实例化控制权，转移到类的外部：
public class Contract { public Contract(ILog log) }调用
class Program { static void Main(string[] args) { ILog log = new NLog(); Contract contract = new Contract(log); contract.Successed(); } }这样，无论外部日志组件如何变化，都不用会影响现有的Contract类。
Contract只专注于属于自己的职责。上层Contract类和日志类解耦更加彻底。互不影响。
如果从职责角度来看，我们是不是可以有一个类专门来管理创建日志类呢？
就像仓库管理员一样，根据单子出货，不需要关心这些货物到底如何被使用的。
public static class Ioc { public static ILog GetLogInstance(int type) { switch (type) { case 1: return new Log(); case 2: return new Log4(); case 3: return new NLog(); default: return new Log(); } } } class Program { static void Main(string[] args) { ILog log = Ioc.GetLogInstance(1); Contract contract = new Contract(log); contract.Successed(); } } 依赖注入 什么是依赖注入呢？其实我们刚刚已经实现过了，全文先是依赖倒置，然后控制反转，而现在说的依赖注入是控制反转的具体实现方式。
依赖注入是解开依赖并实现反转的一种手段。
大约分为三种方式：
构造函数方式
public class Contract { private ILog _log { get; set; } public Contract(ILog log) { _log = log; } }优点: 构造Contract就确定好依赖。
缺点：后期无法更改依赖。
Set方式注入
public class Contract { private ILog _log { get; set; } public Contract(ILog log) { _log = log; } public void Successed() { string msg = "save, successed!"; _log.Write(msg); } public void SetLogInstance(ILog log) { _log = log; } }优点: 将Log实例化延迟，Contract类可以灵活变动依赖。
缺点：使用_log前需要判断null情况
接口方式注入
public interface ILogSetter { ILog Setter(ILog log); } public class Contract: ILogSetter { ... ... public ILog Setter(ILog log) { _log = log; return _log; } }接口方式和方式二有点类似，这里将依赖注入提升为一种能力，可以支配依赖关系的能力。
探讨 控制反转从这个图中，可以看到依赖的倒置，这里低层定义接口并继承实现，高层引用低层定义的接口进行调用使用。
那么现在的控制权是在低层，那么定义接口这个权力到底属于谁？
比如我们有一个流程对应着5个步骤，这5个步骤又对应着5个接口：A1，A2，A3，A4，A5
业务系统a,需要使用这个流程就需要依次调用这5个接口：A1 -> A2 -> A3 -> A4 -> A5
现在这个流程非常公用，已经上升成为企业级中台的一个流程，越来越多的业务系统给都在对接。
此时，很多的业务系统需要重新用代码组织一套这样的调用流程，当然现在的控制权还是在业务系统这里。
所以此时我们对外公开的5个接口，只是简单提供了调用能力，对于接口的编排全部寄希望于业务系统。