好的设计产生灵活的软件-下（good design = flexible software part 2）
------------give your software a 30-minute workout
| 引言 |
如果你在对应用进行修改的时候发现问题，很有可能说明你的软件需要更加灵活和富有弹性。你需要做更多的分析，整体的设计，学习可以使系统更加松耦合的OO原则。在最后，你将会看到提高内聚性如何帮助你解耦。
| 正文 |
让我们再看一下前面的乐器销售例子，我们将在上面使用OO原则，使得它更加灵活。
在上面图中可以看到，有三个地方需要改进：
-
addinstrument方法，如果有新乐器类型需要添加的话，这个方法要修改代码，因为乐器的type判断的if代码需要添加一个判断。
-
对每一个乐器类型都有一个search方法。以后如果增加乐器类型，还需要打开inventory的代码进行增加search方法，不是一个好的解决方式。
-
每个乐器子类都只有一个构造函数，用于设定乐器类型，没有其他行为
造成这两个问题都是由于我们再方法里面针对实现编程，而没有针对接口编程。
search方法可以进行如下的修改
代码
public List<Instrument> Search(InstrumentSpec searchSpec)
{
List<Instrument> instances = _inventory .FindAll(i => i.Spec.Matches(searchSpec));
return instances;
}
{
List<Instrument> instances = _inventory .FindAll(i => i.Spec.Matches(searchSpec));
return instances;
}
我们创建子类的主要原因是子类的行为有别于父类？但是我们目前的乐器子类和父类有不同的行为吗？他们没有不同的行为，但是还有有两个原因来解释我们为什么需要乐器子类。
- 因为instrument只是一个乐器的抽象概念，不是具体的乐器，因此instrument应该是abstract。因为我们需要乐器子类。
- 每个乐器的属性是不一样的，spec是不一样的，所以需要通过构造函数来赋值。
一个设计的死亡
最困难的一件事就是否定自己的设计。
设计是一个迭代的过程，不要害怕检查自己的设计决定，如果有问题，一定要改进它。虽然改进需要一定时间，但是在软件开发的长期看来，是值得的，会给后期的开发和维护节约很多时间。
| 结论 |
分析与设计
- 设计良好的软件应该很容易修改和扩展。
- 使用基本的OO原则，例如：封装和继承，使得你的软件更加灵活。
- 如果一个设计不灵活，马上改进它。不要停留在一个不好的设计，即使这个不好的设计还没有到不得不修改的地位。
- 保持每个类的内聚性，每个类应该集中做一个事情。
- 在软件的生命周期中，尽量最求更高的内聚性。