|
|
这几日，在阅读GoF之一的John Vlissides著作《设计模式思考》，在James O. Coplien为本书所撰写的序中，摘引了Richard Helm的一封邮件：
GoF的设计模式只解决了微观架构（micro-architecture）。你仍然必须把宏观架构（marco-architecture）设计好：分层、分布、功能隔离……。而且就像Cope说的，你仍然必须把纳米架构（nano-architecture）设计好：封装、liskov……。
我很赞成这种根据设计粒度来划分架构的方式。从严格意义上讲，软件设计也可看做是架构的一部分。从marco-architecture到micro-architecture，再到nano-architecture，是一种设计粒度的自上而下。但在架构过程中，我们并非一定要从宏观到微观，再到更为具体的细节，这些架构其实是平等的。这几种粒度的架构，似乎存在某些玄奥的原则与设计精神，贯穿其中。我以为，如果能把握它们之间的脉络，甚至通过某种方式将它们串联起来，形成一种有机结合或者说浑然一体的架构，对于我们的架构与设计而言，无疑会带来极大的帮助。
最近一年来，我一直在思考隐藏在设计背后的基本思想与原则。因为在纷繁复杂的模式中，我们很容易迷失自己，要么患上模式病，要么在选择模式方面变得无可适从，或者就干脆鄙视模式，按照自己的一套方法野蛮施工。不幸的是，这种野蛮施工在有时候确乎能取得不错的效果。然而，这无疑落入了一种类似“按巧合编程”的反模式陷阱中，我将其称之为“按巧合设计”，即在项目或产品设计过程中，因为偶然原因，设计取得成功，从而给设计者带来错觉，以为寻觅到了某种“放之四海皆准”的终南捷径。
我对设计的思考总结而言，包括七个方面，即“重用、扩展、变化、分离、简约、一致、间接”。我在多次会议上也阐述和分享了我的这些想法（当然，这些想法绝非我的独创，有很多其实本身就是业界公认的原则，我不过是期望能够融为一体地来阐述架构与设计这一命题。）然而，囿于自身经验与能力，我还未能将其总结得更好。我对设计模式（即所谓微观架构）的理解是有几分自信的，对于OO的基本原则（即所谓纳米架构），也可以说是深谙于心，但对宏观架构的把握，还欠缺几分火候。我始终感觉我的总结有一些散，我追求的设计原则，应该像散文的精神那般，能够做到“形散而神不散”，而现在对设计的理解正好缺乏某种能够符合类似天体运行规律的链条所在。Richard Helm对架构的叙述，为我打开了一扇窗户。
此外，通过我这几个月负责的产品研发，我对UML的理解也更近了一层。我越来越觉得UML对架构和设计的帮助。正如Craig Larman的那本名著《Applying UML and Patterns》，UML与模式可以结合得更紧密一些。UML的重要性不言而喻，如果有人对其产生轻视，乃至于鄙视，归根结底，一定是对UML进行了误用或者滥用。UML是工具，但它不同于普通的工具，它能够启发我们的设计。例如用例图可以帮助我们识辨角色与场景，还可以帮助我们找到能够重用的元素。组件图无疑属于宏观架构的范畴，它帮助我们体会封装与松散耦合，还能够帮助我们定义服务。我不认为从一开始，就只能利用组件图来划分模块，毕竟在很多时候，我们很难完全对模块进行分解。但如果能够合理地利用组件图，对模块的划分无疑会变得轻松许多。在微观架构的层面，我特别喜欢时序图（sequence diagram），在我心中，它的重要性甚至胜过测试驱动开发。结合用例图，它能够帮助我们找到对象协作的顺序与方式，帮助我们找到抽象以及接口，当然还包括对象的职责。我们还可以适当地结合ICONIX方法，并结合原型，来帮助我们对用例场景的理解，并最后找到必须、应该且恰如其分地需要参与到这一场景中的业务对象。
从架构的角度来看，我们需要将自上而下与自下而上两种方式进行结合。此外，我们必须遵循所有层级架构都应遵循的原则，例如高内聚、松耦合以及关注点分离。我在思考，这些基本原则，似乎正是我要寻找的穿起纳米架构、微观架构和宏观架构的链条呢？如果是，我们该怎样运用它们。毕竟，对于大多数设计者而言，这些原则都太空泛，太抽象，以至于落入玄奥的“道”中无可自拔。架构与设计自然有其玄妙之处，有其不可言传之处，但如果一味地故弄玄虚，并不利于设计者的提高。因此，对我而言，我希望能够提供大量的案例，来佐证这些原则；更重要的不是佐证，而是指引，以好的例子，甚至可以称为典范的例子，展现这些精妙的原则，使得我们的开发人员都能够看懂，都能够理解设计的妙处。这是我努力期望做到的。
若要做到这一点，我必须还要提高自己的架构与设计水平。但我以为，我几乎要寻觅到登堂入室的入口所在了。我期待自己能早一天找到它！
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
