canonical

    最近强调弹性设计的比较多，大概是因为需求的多变太令人挠头了吧。但从道理上说，一个良好的设计必然是刚柔并济的。所谓没有规矩不成方圆，你能想象没有钢 筋骨架结构的高楼吗。在基础核心架构方面特别需要适当的刚性和足够的稳定性，需要用接口明确表达出将用到的假设。内核稳定了，固化了，外围的aspect 才能安全的织入到系统体系架构中来。象变形金刚那样的自由组合变化的结构（在流动结构与固化结构之间转换）目前还只是一种幻想。

    强类型语言在控制大型系统的核心方面还是远胜于弱类型脚本语言的。有些人认为单元测试可以取代编译器的强类型语法检查，这完全是一种臆想。程序的正确性应 该在不同的层面上得到约束，验证，而不是一古脑的推到单元测试那里。在单元测试中对于概念一致性的保障是绝对无法与静态类型检查相比的。类型一致性的检查 在编译器的帮助下以非常低的成本就可以进行，而如果要在单元测试中实现同样的约束，成本要高得多。有一点我们应该明确：除了功能实现代码，其他任何文档， 代码都应该是多余的。为什么需要单元测试，那还不是因为没办法嘛。

   我其实很少谈到OO这个概念，一般情况下我只提结构的表达与结构的控制。软件开发是一个从二进制指令构造出一些高级结构的过程。无论是PO, OO, 还是XO, 只要它能有效的降低这种结构构造过程的复杂性，能够增强我们对程序结构的表达和控制能力，那么它就是有价值的。在我看来，继承（inheritance) 必然是有用的，因为它是一种表达推理结构的方式而无论它的概念诠释是什么。行为函数聚合在对象的名义下是有意义的，因为它使得这些关联得以明确化，静态 化。为什么函数式编程是有效的，它和OO是什么关系。说白了，FP能够方便的表达OO不易表达的结构。xml与OO是否是冲突的？xml能够方便的表达结 构，通过dtd或者xml schema又可以方便的实现对结构的约束（动态的类型系统?)。
    级列设计理论要求我们所有的讨论必须在一个统一的模型（最广义的模型）下进行。OO与非OO的思想其共同之处是什么，它们在什么层面上是统一的？无论是 OO还是PO，都可以归结为结构问题。所以我多谈结构，少谈OO。两个不同的概念，可能意味着它们处于复杂性的不同级列（可以实现平滑的过渡），也可能意 味着它们之间是正交的，互补的

                                      

http://www.xml.com/pub/a/ws/2003/09/30/soa.html
http://canonical.blogdriver.com/canonical/809426.html

   随着IBM, Microsoft这些世界级大厂商不遗余力的推销，SOA(Service Oriented Architecture)已经成为企业应用中的核心概念之一。我的一个同学在IBM做SOA架构咨询，前两天也和他聊到这个话题。从他们IBM的态度来 看，SOA无非是后EJB时代一个profitable enabled的概念而已。现在软件厂商的日子变得愈加艰难了，很多厂商都希望向服务转型，成为所谓IT service provider. 这是某种商业架构上的service oriented, 与技术上的SOA似乎有一些相互映衬的关系。IBM极力希望把SOA中的service概念提升到business layer, 希望在超越BPM(Business Process Management)的层次上提供一站式的打包服务。但是很显然，此service非彼service, 这种SOA的宣传中颇有一些偷换概念之嫌。把所有可以让用户买单的理由用MDA(Model Driven Architecture)做包装，打包到一个独立概念的package中在目前确实是一种可行的商业策略，只不过相对于用户脆弱的技术理解力而言，这种 SOA实在是不可承受之重。大多数用户所能理解的SOA不过是Integration的代名词，与EAI(Enterprise  Application Integration)没有什么可区分性。目前java技术的普及已经使得各个厂商的区别变得很小了，IBM这些巨型厂商鼓吹它们在异构系统集成方面的 优势当然是势所难免，在此过程中加点料也是可以理解的。


   虽然SOA这一概念中混杂了太多的商业因素，它也并不是一种单纯的fantasy. 从技术角度上说，SOA存在着如下关键性特征：
1. 独立运行(standalone)。所谓的service, 它与组件(component)的根本不同，首先在于service是独立于调用者自行运转的。访问service的接口相对狭窄，我们只需要知道 service如何满足我们的功能需求，而不需要管理它的生命周期，不需要理会那些维持service运行所需要考虑的种种细节。即我们对于 service的了解只需要局限于功能接口即可，不需要理会它的那些管理接口，配置接口等。各种service在功能接口这一层面发生交互，整个图景得到 简化。最常见的一个例子就是数据库服务器，调用程序只要知道如何通过sql语言进行数据访问即可，另有数据库管理员去对付各种配置管理问题。从技术上说， 这可以看作是singleton模式的一种扩展。实际上spring容器中管理的bean在某种程度上就可以看作是独立于bean的调用者的，因而 spring这样的容器可以成为SOA架构的自然接入点。

2. 异步调用(asynchronous)。内禀的异步特性是SOA包容真正的商业智能的关键所在。想象一下我们现在需要评估用户的信用度,它对应于函数 evaluateCustomerCredit(customer). 最简单的情况下，我们只需要根据用户的某些指标直接进行算术运算即可。如果评估规则非常复杂，我们可能放弃硬编码，而引入规则引擎（Rule Engine)这种人工智能的解决方案。在更加复杂的情况下，我们可能无法抽象出以数学方式表达的规则，而必须依赖于业务人员的人工处理（真正的智能）。 此时，系统可能需要弹出一个页面，等待业务人员作出判断，部分情况下还需要经过审批流程才能决定对于用户信用度的最终评定。对于计算机系统而言，这些都是 漫长的过程，是同步调用方式所无法容纳的。同样是一个函数调用，只有异步特性才能够包容真正的商业智能，才能在函数这种最小的程序结构单元中引入最复杂的 处理过程。现在SOA的宣传往往集中于机器之间的互相调用，强调异构系统之间的一种包容性，但事实上异步特性所能承载的内容要远远超越机器世界本身。当 然，同步调用方式也是SOA架构的自然组成部分，就像我们既需要email， 也需要手机一样。

3. 基于消息(message based)。基于消息的调用方式是分布式系统的一种内在要求。消息是一种数据，它并不是远程对象指针。distributed object这种基于proxy-stub的方案其内禀要求是远程状态同步（状态的一致性）,而分布式系统是由众多独立的状态空间（进程空间）所构成的， 这种内在的不协调是造成分布式对象方案难以实现可扩展性的关键原因。
  SOA与EBI(event-based integration)的区别主要在于EBI往往是push模式的，消息源向注册的消息consumer推送消息，而SOA往往还是一种pull的调 用。这两种方式各有千秋，在大的scale情况下，pull模式的可扩展性要更好一些。但是两种模式在企业应用中都是必不可少的，可能这些概念很快就会出 现融合。


4. 纯文本协议+元数据(Plaintext Meta)。SOA架构中基于纯文本协议是一个非常关键的技术抉择。当需要跨越众多硬件平台和软件系统的时候，各种二进制的RPC方案总是存在着难以彻底 解决的可理解性的问题。凭借纯文本的结构透明性加上元数据的自描述特性，我们希望实现一种语义透明性，使得各种中间层都能够以通用的方式传递经过的消息， 并理解其中需要理解的部分。与OOP(Object Oriented Programming)中的传统模式不同的是，SOA架构中强调的是结构(structure)与内容(content)的分离，而不是数据与行为的耦 合与封装. 表面上看起来，SOA中的调用方式似乎是对procedure（过程）化调用的回归，但实际上其中有着深刻的不同。在与元数据结合之后，在系统之间传递的 消息（信息）并不是完全被动的，而是具有某种smart特性。当数据这一方面可以包容更多的变化的时候，处理函数这一方面的结构可以得到简化。实际上，在 SOA架构中，我们推崇一种uniform interface, 也只有通过一种通用的接口，信息才能以比较低的代价穿越各种状态空间边界。基于通用接口，我们又重新发现了世界的简单性，而pipe-and- filter这种在unix系统中久经考验的设计模式也得到了新的发挥空间。
    说到纯文本的元语言，xml无疑是这一概念最强势的候选者。作为一种半结构化的文本表述，xml天然就是人机共享的信道。但是，随着应用的深入，当越来越 多的xml设计变得无法让人直观理解的时候，我们也感觉到了一些对于xml滥用的痕迹。W3C的Web Service协议栈提供了非常关键性的思想，并作为标准化的实现方式存在了很长的时间了，但是其实现和调用的繁琐和冗长逐渐引起了开发者的不满。 SOAP虽然号称Simple Object Access Protocol，但是今天已经很难把它和simple这个词拉上什么关系。也许Web Service的未来就如同EJB一样, 渐渐被更加pragmatic的方案所取代。

    在SOA架构中，松散耦合(loose couple)是late binding(discovery), standalone和message based等多种技术策略综合作用之后所达到的一种效果，这为外部灵活的流程配置做好了铺垫。

    web开发这个领域是很有意思的。首先，web的兴起是在软件业发展到一定阶段才发生的，它必然吸收了软件业最优良的思想，必然有其本质上先进的地方。另 一方面，web的应用毕竟是时日较短的事情，造成很多基础架构方面也是薄弱的，原始的。
    具体来说，前台html的展现模型本身是非常先进的。xhtml+css+js实现了结构(structure), 表现(presentation)和行为(behavior)的分离。xhtml本身是简单的文本文件，通过工具的支持可以做到结构上的"所见即所得" (WYSIWYG)。 在js中操纵html结构具有多种方式：可以通过id直接访问html片断，可以直接操纵dom的层次结构，可以将html作为线性文本处理，可以应用 xml相关的技术对dom结构进行变换，可以动态切换html元素的css风格等。dom结构的访问方式是高度统一的，通过parentNode, childNodes, setAttribute, getAttribute等少数几个 API函数，我们可以通过一种简洁一致的方式操纵所有的节点和相关属性（当然,IE这方面的bug不少）。html相关技术中所显示的结构控制能力远远超 越了传统桌面程序中组件技术所能达到的程度。
    但另一方面，html也是原始的，缺乏现代应用程序所必需的标准控件，典型的如Tree控件和Tab控件等。每个开发商都不得不实现并维护自己的界面库。 通过web界面调用后台业务逻辑的方式更是很粗糙的。基础的servlet只提供了基于IO的有限状态机模型，对于后台功能缺乏有效的组织，而对于前台界 面也缺乏合适的抽象手段，仅仅作为文本输出。MVC框架建筑在servlet模型之上，将后台逻辑功能以一种统一的组织方式向外暴露。而tag技术在前台 界面中的应用，使得我们可以有效的识别并分离出我们所关心的结构。这些技术的发展都是web开发模型逐渐精细化的必然结果。
    为了在服务器端获得足够强的结构控制能力，有些人求助于桌面程序的历史开发经验，希望通过java语言中的结构表达能力来扩展web开发的模型，于是便有 了echo2, tapestry这样的组件化web开发框架。坦率的说，我并不看好这类强类型建模的框架。除了性能上的原因之外，我反对这类框架的一个主要原因是 java语言直接表达的结构一般无法达到用xml文本表达的结构的统一性和灵活性，从而很难应对界面的快速变化。实际上，对web界面进行组件化的分解并 不一定需要一种强类型语言支持的组件模型。通过自定义标签的使用，我们完全可以实现将页面分解为多个子部分的目的，这一点已经由witrix平台中的 tpl模板技术所证实。

    web开发是个既先进又落后的领域。很多人面对这种矛盾的情况，难免思想上会出现混乱。关键是要认清技术的本质而不要被OO是否必需等抽象的讨论所迷惑。

web程序需要完成  html <--> java 之间的映射，在界面越来越复杂，越来越多变的今天，这项工作也变得越来越困难。按照级列设计理论的观点，我们应该去寻求一些中间的过渡步骤。在 witrix平台中，tpl模板引擎正扮演了这种中间角色。通过tpl模板我们实现了如下映射路径

html <--> tpl <--> java

注 意到这里html与tpl之间，以及tpl与java之间的映射都不是trivial的同构关系，而是都可能存在着复杂的运算过程，从而实现了html与 java映射过程中复杂性的分解与均摊。tpl与java之间的关联主要通过EL(expression language)表达式来完成，而html与tpl的映射则主要通过自定义标签(tag)机制。
注意到tpl所提供的中间层具有独立的重大意 义，它并不是臆造的或者是简单的技术驱动的结果。实际上，在web开发中除了java结构与html结构之外还存在着第三种结构，即用户眼中的界面结构， 本来它与html所描述的结构是简单的一一对应的，但是随着界面技术的发展，html的描述能力逐渐被耗尽，成为了internet时代的"汇编语言"。 现在一个简单的页面片断就可能对应着大量html代码，因而丧失了"所写即所见"的简单性。tpl通过强大的抽象能力在某种程度上恢复了程序员对于界面表 现结构的直观控制能力，并在一定程度上保留了html所见即所得的特性。

在witrix平台中因为存在着tpl这一强大的抽象层，使得我们对于ajax的支持可以采取更加灵活的方式。
ajax(Asynchronous JavaScript + XML)的标准结构是
html <--> js <==> xml <==> java

在 这种结构中通过xml信道的只是数据，而界面的表达逻辑与展现逻辑完全由js来控制。这种结构发展的一个极端是所有的界面展现结构都由 javascript动态构造出来，而完全丧失了html静态描述的特点,丧失了所见即所得的设计。与直接实现html<-->java之间 的映射情况类似，直接实现 html <--> js之间的映射也是困难的，尽管dom模型的支持可能使得js映射的难度要低于java映射。

在witrix平台中ajax的方案为
html <--> js <==> tpl <--> java

即tpl取代了ajax标准方案中xml的位置，使得映射过程的复杂性得以分散化。

结合jsplet框架的拉模式（pull mode)，我们定义了如下ajax访问接口
js.ajax.load({request='objectName=/@Test&objectEvent=query',tpl:'/test.tpl:partA',targetId:'testDiv'});

1。 远程服务请求就是一段普通的http post request， 避免了额外的xml编码解码需求。
2。请求到的数据先由tpl文件来进行处理。注意到这里tpl文件的url分成两部分，前一部分是tpl文件的虚拟路径，而 ：后面的部分，即partA指出请求的是该tpl文件内的partA部分，而不是整个tpl文件。
3。返回的html结果被填充到targetId所指定的html元素中。

test.tpl文件的内容
＜html＞
＜body＞

＜tpl:define id="partA"＞
＜img tpl:tag="ui:EditTable" /＞
＜/tpl:define＞

＜div id="testDiv"＞
＜img tpl:tag="ui:ViewTable" /＞
＜/div＞

＜/body＞
＜/html＞

tpl具有强大的结构构造能力，在这里我们以非常小的代价实现了tpl片断的定义，例如test.tpl中的partA部分。这里通过id访问tpl片断就如同js中通过id来访问html片断一样。
最后提一个很重要的思想：大量零碎的代码片断需要集中存放，否则人的精力会被耗散。一个反例就是struts中的action, 明明只干那么点事，偏偏要占据一个单独的java文件，占据大量单独的配置条目，最终给程序员带来很大的困扰。

Ajax: A New Approach to Web Applications http://www.adaptivepath.com/publications/essays/archives/000385.php
Ajax(Asynchronous JavaScript + XML)并不是一个革命性的崭新概念（也许根本就不存在突发的革命），它的技术基础在多年之前就已经牢固的建立起来了，在概念层次上的探讨也早就不是一个 新鲜的话题，只是大规模的有深度的应用似乎是最近才开始的。
从广义上说，web应用至少涉及到两个结构，
1. 后台以java语言表达的业务逻辑结构
2。前台以html语言表达的界面表现结构。

web开发很大一部分工作就是建立这两个结构之间的关系。即我们需要
html <--> java

我 们首先要意识到这两种结构之间并不一定是同构的，即后台数据的组织方式与前台展现时的结构是不同的。同样的数据可以对应于不同的展现结构。这也是所谓 MVC架构实现模型与视图分离的依据。传统上，基于Model2模式的MVC框架中，这两种结构的映射只能在很粗的粒度上进行（即整个页面的粒度上），因 此妨碍了封装和重用。为了进行细粒度的映射，我们必须要拥有细粒度的结构控制能力。而目前最强的结构控制能力存在于javascript/DHTML模型 之中，在js中html的结构可以是一段线性的文本(innerHTML和outerHTML), 可以是层级组织的节点（parentNode, childNodes), 也可以是按照key组织起来的Map(getElementById)。在不同的情形下，我们可以根据需要选择不同的结构模型。
ajax体系很直接的一个想法就是将所有关于界面表达和控制的结构都推到前台，由控制力最强的js来控制后台数据模型与前台html模型之间的映射。
html <--> js <==> xml <==> java
在ajax 体系中，xml所扮演的角色是js与java之间的翻译通道，它将js中的结构与java中的结构对应起来，这种翻译比html/java之间的映射要简 单的多。其实它甚至可以是一种同构的映射，可以用一种通用的方式来进行，例如结合burlap与buffalo包的功能。结合webservice的一些 思想，js/java之间的映射是可以在函数调用这种细粒度上自动进行的，从而我们最终可以在概念上完成html/java之间的细粒度映射。

    AOSD(Aspect-Oriented Software Development)可以看作是AOP技术思想在设计领域的一种投射. 采用Aspect的观念之后, 我们在系统分析时应用如下的分解策略
     base + extensionA + extensionB +... 而不仅仅是 partA + partB + ...
  这种分解的基本理由在于base/extension的依赖关系与extension之间的依赖关系并不相同. 在理想情况下, extension之间是完全正交的, 而它们通过base可以构成一个整体, 这是一种典型的star schema. 但是在实际的软件构造过程中, 软件各个元素之间的交互方式要复杂的多:
 1. extension之间可能存在着相互作用, 最简单的一种情况是extension执行时的序关系(order).
 2. 一个结构上的extension可能分散到多个component上, 如何精确而有效的控制定位是一个非常困难的问题.
    就目前的AOP技术而言, 对于extension的控制其实是非常乏力的(但这并不意味着AOP必然放弃对extension的控制), 我们尚需要积累更多的经验. 在实做中, 更加稳健的方法往往是应用aspect的思想而采用传统的实现方式.
    AOSD在理论上存在一些价值, 例如它为use case的extension符号找到了技术对应, 因而使得这个概念变得更加明晰, 而在传统中, 对于use case的extension的解释一直是模糊而混乱的. 目前在真正的开发中, AOSD所描绘的全程建模仍然只是一个遥远的梦想.

  如果一个东西看起来象花生，闻起来象花生，吃起来也象花生，那它究竟是不是花生？ 如果两个事物在所有可观测行为上都表现一致，那两者的本质是否统一就成为了一个不可证伪的问题，从而处于科学范畴之外。而从人的机会主义倾向来看，我们理 所当然的会认为这两者是同一概念。我们以观察来认识世界，当然也就是以行为来界定事物。问题在于，我们在理论上要以事物的所有行为来界定它，而我们目前观 测到的又永远只是它的部分行为。在泛函分析分析中，有一种弱（weak)等价的概念，两个函数如果与某个空间中所有函数的作用（内积）的结果都相等，则这 两个函数在此空间中就是弱等价的。swartz正是通过这种方法定义了广义函数，为delta函数在数学上建立了严格的基础，回避了delta函数的本质 性定义困难。在物理学家看来，delta函数当然是个客观存在的实体，而在数学家看来，它只是通过分布间接定义的概念。（当然，部分研究非标准分析的数学 家认为广义函数兜了个大圈子）
    接口(interface)与类(class)相比，接口的概念完全是由其行为定义的，而类还涉及到其封装了的成员变量，这些变量的作用在继承的时候会隐 蔽的表现出来。毫无疑问，接口所代表的概念是比类变得"浅薄"了，它是明确暴露的行为切片而不是象类那样欲遮还羞的实体定义。

IntelliJ老板的一篇文章Language Oriented Programming: The Next Programming Paradigm
英文 http://www.onboard.jetbrains.com/articles/04/10/lop/
中文 http://blog.csdn.net/chelsea/archive/2005/02/17/290486.aspx

Martin Follower的一篇文章 Language Workbenches: The Killer-App for Domain Specific Languages?
http://www.martinfowler.com/articles/languageWorkbench.html

概念解释：
DSL(Domain Specific Language): a limited form of computer language designed for a specific class of problems, 例如SQL语言，xml配置文件。
LOP(Language Oriented Programming): the general style of development which operates about the idea of building software around a set of domain specific languages.
Language Workbench： the new breed of tools to do language oriented programming

LOP不是一个新的提法，不过随着前段时间MDA(Model Driven Architecture)概念的热炒，LOP似乎终于熬到了应用层面。Sergey Dmitriev的文章中批评了主流程序语言的不足，大概有这么几条：
1. 通用语言表达能力(expressive power)很差，Time Delay to Implement Ideas
2. 领域概念的表达分散在实现代码中，整体图像迷失，因而Understanding and Maintaining Existing Code很困难。
3. 类库等不是用领域概念表达的，因而Domain Learning Curve很陡峭。

这 些都是标准的陈词滥调。地球人都知道，从问题描述到软件实现之间存在着巨大的逻辑障碍，这种障碍有一部分是本质性的，即源于我们认识中的创造性因素，而另 一部分是技术性的，即源于我们使用的技术手段的限制。我们所能想到的解决的办法就是尽量提高解决方法的抽象层次, 提升到所谓的领域层面，从而消解技术性障碍，同时辅助创造性发展。当我们的脑子里不再充斥着各种技术性细节的时候，大概就可以集中精力做些创造性工作了。 LOP把这些老帐又翻出来，到底它提供了什么新意？下面我们简要分析一下LOP方案中概念的含义。

1. 领域(Domain)。
    计算机语言与自然语言在使用上是有着深刻不同的。自然语言只是传递着信息，而计算机语言还要负责具体干事情，即计算机语言要同时说明怎么做和怎么用。做与 用这是两个不同的领域，例如我现在编了一个时光机器的软件，上面就一按钮，只要轻轻一按，嗖的一声我就回到了500年前。怎么样，使用简单吧，但实现呢？ 我们当然希望在一个领域中使用最适合它的描述方法和控制指令。目前主流语言都是面向机器实现领域的(是实现领域的DSL?)，加上Von Neumann串性化体系的限制, 强迫我们用动态过程来实现静态概念，更加剧了它对使用领域描述的不适应性。我们所要做的就是将做与用尽量分离，但同时尽量增大用的灵活性，domain representation不仅仅给最终用户用，还给程序员用。能在使用领域概念范围内解决的问题，我们不要将其拖延到实现领域。在领域间进行转换，总 存在信息转换成本，甚至会造成信息失真。例如，一幅画看起来结构很简单，但是用自然语言描述起来都相当困难，更别说转换为计算机语言了（当然，这个例子很 有可能是误导的，因为涉及到不同的感官，其中的区别是非常深刻的，无法用单一的原因去解释）。所谓领域区分，最重要的还是使用领域与实现领域的区分（不同 的复杂性，不同的表现形式...），而不仅仅是业务领域与计算机领域的划分。在业务领域内部我们也要区分使用与实现。

2. 领域特定语言(DSL)
    语言与库的最大差别在于语素可以自由组合，以极低的代价构造出无数可验证的结构，而库函数的组合和搭配调用是冗长的，受限的，难以进行校验的。DSL强大 的描述能力和推理能力其实是通过放弃其通用建模能力而实现的。最有效的DSL必须弱于图灵机，必须将大量做的过程分离出去，必须引入大量的领域概念（本 体）。
    在引入外部概念的时候，DSL会将其转义为领域概念之后使用，从而消除歧义性并降低理解难度。
    DSL不是在通用环境下工作，而是在明确受限的context下工作，因而概念的表达可以更加简洁，而且领域概念之间还可以通过context构成一种整体性，例如非此即彼。
    witrix平台中的tpl模板引擎在一定程度上可以看作是一种DSL tools, 我也一直推动tpl在这个方向上发展。tpl具有强大的领域抽象能力,例如
       弹出一个选择系统用户的窗口，直接实现为 
        ＜a href="select_user.jsp?deptId=1"＞选择用户＜a＞

    封装为tag之后，使用形式变为
        ＜app:选择用户 部门编号="1" /＞
    经过转换之后，这里的调用不再是API含义，不再是说明怎么做，而是描述用什么。tpl中的标签可以使用调用时明确指定的参数，也可以从全局 context中导入隐含的变量，从而依赖于所在领域的假定。例如，我们的很多界面控件需要与后台交互，依赖于后台jsplet框架，因而这些tpl标签 选择自动导入$thisObj和objectName等变量。领域抽象与context依赖其实正是DSL的精华所在。
    (关于DSL，有些人可能会将其等价于规则引擎(rule engine), 这其实是一种误解。规则引擎实现的是条件空间的分解与合并，它是一个独立的技术，与DSL并没有必然的联系)

3. 语言工作台(Workbench)
    Workbench是LOP的使能技术。我们希望自由的构造DSL,必然需要对结构具有强大的控制能力。而文本语言总是线性的，静态的。看看现在对自然语 言的研究吧，显然我们对于怎样在线性文本中塞入更多的结构缺乏本质性的认识。我们人为构造的语言，限于表现形式，其结构都异常的贫乏。计算机的脑袋是简单 的，于是，我们想到增加维度，通过复杂的工具配合，来实现多层次，多视角, 动态的结构控制。在我看来，很多时候这是一种无奈之举，当然也确实是目前唯一可行的办法。
    工具复杂了之后，造成的本质性障碍在于结构上的僵化，其具体表现之一就是所谓的厂家锁定,一种结构融合上的困难。不同厂家产品的结构具有巨大的差异而无法 互相交互。xml其实正是为了解决这种结构交互困难而产生的，所以我更希望看到基于xml的工作。而在xml的形式下，能够实施的结构变换现在也在不断发 展当中，AOP, XSLT等等。

http://spaces.msn.com/members/zbw25/Blog/cns!1pA6-3FOo9yNp_4lmEHxdDqA!248.entry

     物理和数学的新分支的产生多半有着哲理性的开端，而软件中OO技术的兴起想必也是有一定的哲学基础的。但哲学是一种整体的，超越的认识，当我们在实际的应 用中走得越远，就会发现现实的操作距离哲学的理想越远。早期面向对象总是鼓吹对现实世界的直接表达，鼓吹Object,Class的本体论含义。但现在我 们已经可以清楚的感觉到面向对象的哲学隐喻存在着本质上的困难，而软件希望作为真实世界的翻版也必然面临着建模的本质性问题，即任何一个单一的模型与事实 相比总是简化的，贫瘠的。通过无限多自恰的模型构成的概念包络，再加上无法用技术手段表达的哲学升华，我们才达到了所谓不随人的意志转移的客观世界。软件 只能是客观世界的一部分，而不可能是客观世界的镜像。
    OO技术已经得到了深刻的发展与应用，实际上现在可以不再总是需要一件哲学的外衣了。我一直强调继承(inheritance)是一种推理技术，而接口 (interface)是一种正交分解技术, 希望抛开OO的诠释而从数学上为OO技术找到根基。 无论是推理还是正交分解，我们都可以在数学上严格的证明它们的好处， 因此OO必然是一种好的技术。至于它对现实世界的表达能力，那是另外一个独立的问题。我的这种思想深受测度论(measure theory)的影响。测度论中对于概率的定义是纯粹数学化，满足一定条件的数学量就定义为概率。 至于它是否对应于我们日常思维中的概率概念，那是使用者的责任，那是物理学所面临的问题。只有通过这种公理化的定义，测度论才摆脱了概念完备性与自恰性的 问题，才摆脱了哲学上的循环论证。当然，诠释问题在物理学中仍然是一个非常严重的问题, 例如对于量子力学的Copenhagen诠释的争论从未间断过，只是对于数学层面上的操作过程一般还能保持共识。当然，说的深入一些，即使数学上的定义也 未必是逻辑上必然的。为什么实数轴是完备的，为什么1.999999999...的极限是2, 这实际上是一个公理: 选择公理(axiom of Choice), 等价于Zorn引理。