软件设计中的分解难题

很有意思的分析，我也很想直接加入这个讨论，但是沿着T1的消息分派的思路往下谈，一时也不知从何说起，就扯远一点吧。

通常我们做软件开发，往往是最难的事情，就是分解。

对于将要做出来的那个系统，进行合理的分解。庖丁解牛，是一个不错的“隐喻”。解牛之前，也只能看得到牛的“表象”，对于牛的身体结构并无了解，贸然去做分解切割的工作，就会吃力不讨好。但是庖丁的活毕竟还是容易的，因为不同的牛的身体结构，还是大同小异的。

更加困难的是，我们面对着一个不同的动物，以前可能没有见过，当然，我们希望他不过是牛的一个变种或者近亲，这样过去的经验，还能派上一些用处。

再进一步，这个被我们分解的动物，并不是死的，他还是活的，不但会不断的动来动去，甚至还会长出些新的器官和骨骼来。这就太恐怖了。

通常我们所做的分解的决策，一般会从上自下的进行（分解这个词，就隐含了这个意思）。这样的分解有两层意思：
一是：在本层面看来，几个部分可以相对独立的分工的。
二是：从上一层面看来，这几个部分是为了同一个目的合作的。

麻烦的就是，当这种分解逐渐细化之后，原本就不太了解的细节浮现出来了，这下才发现，原本的那种分解，并不合理，需要在某一层次上，重新分解，最糟糕的，就是需要整个系统设计推倒重来。

一般我们能够用到的分解策略，也无非就是两种，纵向的业务分解，横向的技术分解，然后再把这横向纵向的参合在一起，搞成更加复杂的网状结构。。。

从上自下的分解，可以分为两个重要的阶段，一个是与语言无关的分解，一个是与语言相关的分解。前者，可以称之为设计，后者，可以称之为实现。而T1 探讨的内容，我的理解是：在实现阶段，不同语言，对于各种分解需求的支持。不同的消息分派机制，对于同样的分解、再分解需求的支持能力是不同的。这也就是 各种语言，在实现同样的设计时的难易区别。当然，我们也经常会碰到这样的情况，特定语言的功能限制，会迫使我们去修改原本很自然的，语言无关的设计结构， 这就是无奈但自然的现象了。

再进一步探讨，为什么设计这么困难，因为存在未知的复杂性。灵活方便的语言，有助于开发设计人员，快速、轻松的调整已有的实现、甚至设计方案。而那 些使用死板、僵硬的语言的工程师们，就要为此付出更大的努力。这也正是我为什么要发明一种新的语言的原因。在我看来，语言应该更进一步，对于设计，尤其是 开发过程中的再设计，提供更好的支持。

关于DJ的开发思路
http://zbw25.spaces.live.com/Blog/cns!1pA6-3FOo9yNp_4lmEHxdDqA!344.entry

为什么DJ要将Event提出作为语法概念
http://zbw25.spaces.live.com/Blog/cns!1pA6-3FOo9yNp_4lmEHxdDqA!358.entry

这样的思路，其实是一种实验主义的方法，而再次之前，软件设计，要么就是凭借工程师在丰富经验之后，具有的技术直觉。要么就是试错，再试错，在付出了巨大的成本之后，完成一次系统开发。

先说到这里吧......

原本的讨论帖《失踪的链环》
http://www.javaeye.com/topic/25649