Head.First.Object-Oriented.Design.and.Analysis《深入浅出面向对象的分析与设计》读书笔记（六）...

　　

 

好的设计产生灵活的软件-下（good design = flexible software part 2）

------------give your software a 30-minute workout

 

引言

　　如果你在对应用进行修改的时候发现问题，很有可能说明你的软件需要更加灵活和富有弹性。你需要做更多的分析，整体的设计，学习可以使系统更加松耦合的OO原则。在最后，你将会看到提高内聚性如何帮助你解耦。

 

正文

 

      让我们再看一下前面的乐器销售例子，我们将在上面使用OO原则，使得它更加灵活。

 

      在上面图中可以看到，有三个地方需要改进：

•       addinstrument方法，如果有新乐器类型需要添加的话，这个方法要修改代码，因为乐器的type判断的if代码需要添加一个判断。
•       对每一个乐器类型都有一个search方法。以后如果增加乐器类型，还需要打开inventory的代码进行增加search方法，不是一个好的解决方式。
•  　  每个乐器子类都只有一个构造函数，用于设定乐器类型，没有其他行为

      造成这两个问题都是由于我们再方法里面针对实现编程，而没有针对接口编程。

　　search方法可以进行如下的修改

 

代码

<!--<br/ /><br/ />Code highlighting produced by Actipro CodeHighlighter (freeware)<br/ />http://www.CodeHighlighter.com/<br/ /><br/ />-->   public  List < Instrument >  Search(InstrumentSpec  searchSpec)
        {
            List < Instrument >  instances  =   _inventory  .FindAll(i  =>  i.Spec.Matches(searchSpec));
             return  instances;
        }

 

　　

 　　我们创建子类的主要原因是子类的行为有别于父类？但是我们目前的乐器子类和父类有不同的行为吗？他们没有不同的行为，但是还有有两个原因来解释我们为什么需要乐器子类。

• 　　因为instrument只是一个乐器的抽象概念，不是具体的乐器，因此instrument应该是abstract。因为我们需要乐器子类。
• 　　每个乐器的属性是不一样的，spec是不一样的，所以需要通过构造函数来赋值。

　　一个设计的死亡

 

　　最困难的一件事就是否定自己的设计。

　　设计是一个迭代的过程，不要害怕检查自己的设计决定，如果有问题，一定要改进它。虽然改进需要一定时间，但是在软件开发的长期看来，是值得的，会给后期的开发和维护节约很多时间。

 

结论

      分析与设计

•       设计良好的软件应该很容易修改和扩展。
•       使用基本的OO原则，例如：封装和继承，使得你的软件更加灵活。
•       如果一个设计不灵活，马上改进它。不要停留在一个不好的设计，即使这个不好的设计还没有到不得不修改的地位。
•       保持每个类的内聚性，每个类应该集中做一个事情。
•       在软件的生命周期中，尽量最求更高的内聚性。