设计模式之源(2)

参考
To Be Explicit: martinfowler.com/ieeeSoftware/explicit.pdf

上次说了一个软件设计和设计模式的驱动力“avoid repitition”，现在说另一个驱动力“容易理解”，明确化。"To Be Explicit"这篇文章好像不是在说设计模式的驱动力，而是在说软件设计的驱动力，而"To Be Explicit"中有些东西和一些目前流行的观念却有所不同。下面说细说说：

1.属性与字典：OOD中我们习惯于明确指定类的属性，但是很多流行的语言都提供了Dictionary/Map等结构，所以在运行时我们实际上可以动态改变（增减）一个对象的属性。如果真的使用这种设计，使类变得更灵活，有可能避免重复代码（你不需要生成新的类了）,而且可以在运行期更改行为；但是它却牺牲了可理解性，如果不是满足一些约定，程序员可能不知道字典中到底放着什么。

2.事件与明确调用：这里假定大家了解Observer的模式，文中举例说明，Event的Handler（或说Observer的Listener）可以任意的添改而不被Event本身所知（它只保存Handler的接口对象列表），这个模式很不错。但作者认为，这牺牲了代码的易理解性，因为如果需要理解这段代码具体做了什么，可能需要查看所有添加Handler到Event的代码，这个角度看，设计是有问题的。作者说：“As you can see, explicitness is not always the dominant force in designdecisions. In this example, packaging and dependency forces are also important. People often underestimate the value of explicitness. There are times when I would add a dependency to make code more explicit, but, as always
with design, each situation has its own trade-offs to consider.”
  我认为，如果是我，可能还是会选择Event模式，而通过注释和文档，可以让一些东西变得explicit.

3.明确的子类对象:看到此标题,原以为作者要说:不要面向接口编程,使子类具体化. 怎么想怎么不对. 看了文中所写的例子,才明白,是在说:要面向接口编程,而不要把所有的子类提到同一个类中,以为可以减少类的使用.

这篇文章说的都挺有道理,但都不像"avoid repition"那么绝对,而且有时"To Be Explicit"会造成与avoid repitition的小矛盾.所以到底要不要explicit,取决于设计者的一个断断,anyway,最重要是把软件正确的做出.其实开发人员适应了设计,不必过份拘泥于细节.