设计模式-对软件设计中耦合程度的思考

　　软件耦合度高的模式，一般对象数少，可能容易理·32解写；耦合度低的模式，对象数相对多。拿计算器的业务来讲：

耦合度较高的版本：

private static double getResult(double n1, double n2, string operation)
{
  double double rtnResult;
  switch(operation)
  {
    case "+":
    ...
    break;
    case "-"
    ...
    break;
    case "*"
    ...
    break;
    case "/"
    ...
    break;   
  }
  return rtnResult;
}

　　　计算器的加减乘除操作通过一个函数，直接就实现了主要的业务逻辑。这种方式的优点是没有形成新的业务对象；缺点是扩展性差、后期不易维护等。显然加减乘除是主要的业务操作，所以需要改造为4个业务对象，每个业务对象封装自己的操作，以及一个类能管理这4个模块。并且，这4个模块功能是并列的，这样可以套用“工厂模式”来实现。

　　UML如下所示：

　　　类图很简单，4个业务类分别实现接口，MangeOper类引用4个业务对象，确定接口的实现类，UI客户端引用这个ManageOper类，告诉它用户选择了加减乘除中的哪个操作。

　　在计算器这个例子中，以上设计模式是好的，主要业务对象耦合度较低，以后想要扩展其他操作，只需要写出很多个新的业务类即可。但是，是不是所有的设计都要耦合度尽可能的低？

　　这是一个好问题！

　　问题无绝对！ 不是说松耦合就一定好，紧耦合就一定不好。如果构成某个软件的模块地位非常低，那么就要考虑是不是要设计的耦合度很低，灵活性很强了？！

　　因为我完全不想花太多精力去编写它，并且以后它几乎不怎么改变，这样的话，采取紧耦合也未尝不是一种好的设计方法；换句话说，如果这是公司的一个重点业务，那么，需要写的耦合度小写，好好构思相应的设计模式来。

　　设计模式跟着业务和未来的业务走！