饭否，没有用过，twitter倒是偶尔上去看看。

他貌似倒下很久了……

在豆瓣上看到有人说饭否今天回来，所以赶紧去看看~只有一张图片，然后没有其他的了~看下首页代码，看到这样的一句话：

  We are troubled on every side, yet not distressed;
  we are perplexed, but not in despair;
  Persecuted, but not forsaken;
  cast down, but not destroyed; 

  Thank you all, for always being with us. 

好吧，等着饭否回来~

上一篇文章中说到了依赖降低的方式，其中最后一点是“惯例优于模式”，其实，惯例就算是一种约束，设想你是一个刚刚开始创业的老板，你没有足够的资金、人力来开发大型的项目，这些算是你的约束，但是同时也是你的优势。上篇文章中说到了一个最给力的公司37signal，他们的书中曾经就提到过约束是你的优势这一点：

永远都是僧多粥少。没有足够的时间；没有足够的资金；没有足够的人手。这是一件好事。

你不必异想天开为客户增加更多自己想要实现的功能，你仅仅是服从你的约束条件把手头的东西做到最好，在一个sprint中，你能完成的就是一个个不同的user case然后让这个story延续迭代，当你的客户得到他们想要的时候就收手，记住这个时机是客户刚好满足需要。

约束让我们减少对无关紧要的东西的注意力；

约束让我们增加对手头任务的关注度；

约束是一种大家都集体采用的模式，优劣会暴漏的很明显，所以如果他成为了约束就接受他，你可以挑战权威但是不能不尊重他~

软件项目中我觉得在我这个阶段还局限于这样的约束：

1 技术

技术的约束让我不能够异想天开并加以实现，所以以仅有的技术来前进要求能够不断地自省，知道自己擅长什么不擅长什么，然后扬长避短，同时，前进的过程中不断地补充营养~

2 想法

一个好的项目源于一个好的点子，但是，当你局限于周围熟悉的人或事物的时候这些成了你思考的约束，但是，如果留心你会发现其实周围的好多东西还不完善呢，所以，别想太远，从手头做起吧~你看，约束让我们更关注于一步一个脚印的前行~

3 能力

作为一个20岁的毛头小子，现在没有做过人生中让我引以为傲的东西，所以，能力这东西还有待培养，这也算是一种约束。起码，这种约束让我知道自己还嫩着呢，别骄傲自大，三人行必有我师~

最后还是使用37signals的那句话：约束通常是一种隐蔽的优势。忘记风险投资，长发布周期和快速招聘吧，就在你现有的条件下工作好了。

在前边的文章中说过关于IoC的东西，其目的是减少对象之间的依赖从而让软件的可扩展性增强~但是，减少相互之间依赖方式并不只有这一，下面是一些其他的方式，来源于张逸：

1 配置文件与反射技术

在前几天看MVC的时候写过一篇文章关于反射的运用，这是第一个采用反射，发现他的强大时让我们把静态的编译语言变成伪动态，增加了灵活性，而对于减少依赖，我们同样可以使用反射技术，从一点上可以推断出来：减少依赖的目的是动态的扩展，而反射就是动态的。

public class Order
{
  private statis readonly IOrderStrategy orderInsertStrategy=
                  LoadInsertStategy();
  private static IOrderStrategy LoadInsertStrategy()
  {
    string path=ConfigurationManager.AppSettings["OrderStrategyAssembly"];
    string className=ConfigurationManager.AppSettings["OrderStrategyClass"];
    return (IOrderStrategy)Assembly.Load(path).CreateInstance(className);
  }
}

<
add vlaue="SomeThing.BLL" key="OrderStartegyAssembly" />

然后你还需要实现相应的辅助方法来调用这些~

2 表驱动法

上边的方法的一个好处就是动态获取，但是依然会有if else的语句存在，因此，使用表驱动法来

进行变成可以有效地消除这一现象。依旧是对于上边的例子进行扩展，我们创建一个Manager对象

，负责初始化并维护对象，这里我们需要一个字典：

public static class OrderManager
{
  private static IDictionary _ST;
  static OrderManager()
  {
    Init();
  }
  private static void Init()
  {
    _ST=new Dictionary();
    _ST.Add("sync",new OrderS());
    _ST.Add("asyn",new OrderA());
  }
  public static IOrderStrategy GetOrderStrategy(string st)
  {
    IOrderStrategy stt;
    if(_ST.TryGetValue(st,out stt))
    {
      return stt;
    }
    else
    {
      throw new Expection("无法找到");
    }
  }
}

但是这段代码中存在一个问题就是硬编码，也即是说依赖其实没有真正的解除耦合，作者给出了改进的方式，就是同样的采用配置文件来进行辅助扩展。

3 依赖注入

这里不再介绍，因为方式主要是采用存在的扩展类库实现~

可以看下作者实现的方式~

4 惯例优于配置

以上的方式中不可缺少的就是配置文件，也就是说你虽然实现了解耦，但是却要面对复杂的配置文件，这些xml文档，作者给出了一种方式就是Ruby On Rails的设计理念“惯例优于配置”，源于37Singal，这个公司大家可能都听说过，起码他们的关于创业的书是很值得一读的，以后再给出读后感。这里，ROR给出的不仅仅是框架还有各种预定，这一点有点像MVC一个controller必须符合特定的名称。其实，这不是一种技术而是一种理念，让我们按照特定的方式在前人的基础上前行而不是闭门造车~

以上就是从张逸处取到的真经，同时，也有点自己的看法，对于解除依赖，我觉得理念最重要，方法是理念驱动。不过我还是觉得Ioc在合格方面比较顺手，因为已经有现成的类库进行扩展，也就是说比较方便吧~

还有就是依赖不能解开的情况，这个貌似可以通过横切关注的方式实现，当然这个方式主要是内部的方法解耦，相关的东西也不太理解~以后再谈吧~