说到分解，很多人心中的意象大概只有正交分解。正交分解无疑是最重要的一种分析方法，它也是所谓“分而治之”思想最常见的实现策略。但是正交分解一般潜在的假定是分解后的子部分是大致均衡的，它们是相对具有独立价值的，可以彼此脱离独立发展。这是分解后实现系统解耦的重要原因。http://canonical.javaeye.com/blog/33885
但是物理学中另一种重要的分析学思想是微扰论(Perturbation). 针对一个复杂的物理现象，首先建立一个全局的规范的模型，然后考虑各种微扰条件对原有模型的影响。在小扰动情况下，模型的变化部分往往可以被线性化，被 ...
所谓WebMVC即Model2模型是目前Web开发领域的主流模型，Struts/Struts2框架是其典型实现。在概念层面上，这种程序组织模型是
怎样建立起来的?与其他Web开发模型(如面向对象模型)具有怎样的联系? 它未来可能的发展方向在哪里?
结合Witrix开发平台的具体实践，基于级列设计理论我们可以看到一条概念发展的脉络。http://canonical.javaeye.com/blog/33824
1.
外部视角：原始的servlet规范提供了一个简单的面向IO的程序响应模型。一次前台访问由一个特定的servlet负责响应，它从r ...
关系数据库模型在理论上主要解决的是消除数据冗余的问题。关系模型的数学基础是所谓的集合论，而集合的基本含义正是一组具有某种原子性的互不相同的元素。面向对象技术是对相关性进行局域化的一种手段（相关的数据和操作聚集到同一对象名义下），在这一局域化过程中，相同的元素被识别出来，成为独立的对象。从某种意义上说，关系模型与对象模型是殊途同归的过程，是从不同侧面对同一事物的反映。关系模型中，我们关注的重点是元素组成的集合，允许的连接关系定义在集合之上。而在对象模型中，我们关注的首先是横向关联的实体，实体之间具有稳定的联系。在概念层面上，从对象模型映射到一种关系存储模型只是一个分组问题。为了断开实体之间的直接 ...
我在各种场合一直都在强调结构问题是独立的，在程序语言之外存在着独立的，可研究的，富有成效的结构问题。http://canonical.javaeye.com/blog/147424 在这个方向上更进一步，我们注意到所有的代码并不是天然出现的，而是由人所编制的，因此代码世界内部并不构成封闭的，自足的某个世界。代码中的结构问题并不是由代码本身完全解决的，即在代码之外仍然存在着技术上可研究的结构问题。
我们在编制代码的同时也在编制着大量的说明文档。这些文档描述了代码片断之间的相互关系，描述了代码未来的扩展方向，描述了代码之间的可能的交互方式，同时也描述了针对现有代码实现的很多具体约束。例如 ...
设计考虑的是最终需要什么，最终我们要提供的调用接口是什么，我们所直接需要的某个有价值的，直接存在的，直接可以接触的结构是什么，而不是它所依据的原理是什么，不是它的具体构造过程或者构造方法是什么。比如说我们在程序中完全不需要内置Map这一结构，因为它可以通过列表等结构组合构建出来，但是很显然，Map这一概念的直接存在对我们来说是方便的，是经济的，是有效的。我们在思考的时候并不需要考虑它是采用List实现还是采用Set实现，或者任何它本身的构造结构。这一概念在我们的思想中成为某种原子化的东西。
那么，我们到底需要构建哪些概念，才能够最方便的基于这些概念应对万千应用系统的开发呢。 这是我们 ...
没有人否认抽象的意义，但是抽象是否就是抽象到无穷大，这是个可以明确定义的问题，也是数学领域正在解决的问题。在我们的思考中没有明确定义何处是边界，没有明确的限制，这便是导向无穷的一种思维方式，它和现实中是否真的允许消耗无限多的资源，创建无限多的对象无关。当我们认为自己明白了终极的意义，明白了一种推向无穷的抽象，这并不是理解了世界的全部，我们仍然要明白如何解决一些更加小范围，但是却又普遍发生的事情。
例如现在我的系统中只需要10个相互依赖的线程，如果我们定死了10这个数字，显然我们可以发展一种这个领域特有的高效的一些算法结构。而抽象到通用语言中的时候，显然我们只能假设线程数是任意大，或者是 ...
数学上的有效性与物理中的有效性是不同的，例如对于密码学问题，如果通过穷举法破解密码成功时，经过这些密码加密的数据已经过了有效期限，此时我们在数学上定义穷举法不是一种有效的破解方法。但是物理层面上我们说只要一种方法比另一种方法能够更快的解决问题，我们就说第一种方法比第二种方法有效，而无论密码被破解的时候该密码是否已经过了有效期限。
我所表述的论题并不是说特定的领域结构无法在某个特定的通用语言中有效实现。我想很多人对我的话语都有些误解。
引用
如果我们认为一种通用语言是比较稳定的,则它一般选择只内置一些通用的不带有领域特定含义的概念. 而缺乏领域知识,或者说因为通用语言故意的摒弃领域依赖 ...
我在前面的文章中列举了大量物理学相关的例子来试图说明采用物理视角的必要性,但是可能因为物理事实大家不熟悉,结果直接被无视了. 在本文中我想有必要举一个软件领域的例子。只是在实际思考的过程中,我主要还是基于物理概念进行推理.
首先我所谓“现在的通用语言”，它并不意指“现在至未来所有通用语言之合集”，而是指“目前正在被使用的某一种通用语言”，这种差别便体现了我所强调的不同的价值观和不同的视角。不是一种覆盖一切的全称判断，而是在特定物理约束下的物理实体。
现在无论我们设计什么大型系统，一般总是要优先考虑微内核设计。但是很显然，如果我们的编程控制能力极强（强大到不现 ...
每当我在文字中对函数式语言有些不敬之意时,便好像动了某些人的奶酪,以至我的言辞总在被曲解后遭到排斥。我想这就是因为视角差异过大所造成的. 但是谦虚谨慎是传统的美德, 不能容纳他人的观点只会妨碍自己在某些方向的探索。
首先请不要轻易怀疑我的知识水平。当然如果总无法聚集起足够的注意力来理解别人话语中的细节，我也无话可说。
容纳他人的观点就意味着不要总在自己的话语体系中试图找到反例. 一个人总是受限于他的知识范围，因此他也经常在自己的知识范围内篡改曲解别人的意见。我从未说过 "一个具体的问题是现有的通用语言无法描述的". 我说的是"现实开发中所需要处理的结构问题并不是在语言层面得到充 ...
我的观点并不是什么具体的程序结构问题不能用函数式语言处理.我所要表述的是这和函数式语言中能否加入结构解决任意复杂问题无关。为什么所有的问题不能在集合论中解决，为什么要有独立的数学学科。物理学所有的定律都使用数学表述，是否意味着物理学的真理蕴含在数学之中。
我说实际上现在的通用语言也是无法有效承载Domain Specific Structure的。其实与以下说法是类似的
数学是无法涵盖物理学的，现在的已知的数学工具是无法有效承载尚未得到充分探索的领域的物理的
我说我所关心的不是语言层面的问题。这类似于说不要把所有物理问题都推到数学层面去解决。
我们应该研究独立的结构 ...
1. 函数式语言可以合理的看作是泛函分析思想的一种体现，从历史发展的时间上看大概也是具有这种可能性的。在Backus的论文中对函数式语言的一种乐观的情绪甚至扩大到functional algebra can be used to tranform programs and to solve equations whose "unknowns" are programms in much the same way one transform equations in high school algebra。这种信心只能来源于泛函分析和方程论，来自于数学分析学的发展。将函数的函数作为分析对象就构成 ...
我习惯于概念层的推演，而且所阐述的东西多数是我们创造过程中的副产品，与业内常见的观念实际上是有着很大差异的。感觉不明白是因为你没有采用类似的视角，或者还没有独立思考过很多问题。如果你只是从业内已经熟知的概念出发试图理解我所写的内容，显然是不可能的事情。所以我常说know something already known.
如果你在编制一个新的应用，存在大量代码可能是
myFunc(){
for each x in set
doSomethingValuable(x);
return packedResult;
}
myOtherFunc(packedResult ...
地址(Address)是现代计算机体系架构中的核心概念，它在程序设计语言上的体现就是C语言中的指针(Pointer)。在C语言中，所有的高级技巧都和指针这个概念相关。指针只是一个存放了一个地址的变量，但是C语言中提供了一个方便的间接访问方式，p->x, 它使得拥有指针在概念上就等价于拥有了指针所指的全部内容。在这种诱导下，我们渐渐模糊了地址和地址所存储的内容之间的区别。这也是指针的指针这样的概念总是让初学者迷惑不解的重要原因。
指针是对地址的符号化。它所带来的第一大好处是使得我们摆脱了对绝对地址空间 ...
判断和循环是程序中最基本的语句结构。而在vonNeumann体系架构下，循环是对集合进行操作所需的基本步骤。一个有趣的事实是，函数式语言所宣称的 生产力的来源很大程度上在于集合操作的便捷性。在数学中我们通过张量分析，泛函分析等可以清楚地意识到集合之间的相互作用是可抽象的，是可以独立理解的， 即我们可以在不涉及具体基元结构的层面上独立的定义并执行集合运算。如何将这种概念独立性在框架层面展开是一个非常深刻的命题。
在基元结构上应用基础操作p(d)这一微观场景一般情况下是容易理解并实现的, 但通常程序中所定义的大量边界是基 ...
Witrix开发平台基于级列设计理论发展了一系列新的设计思想和软件分解机制。并提出了一种新的Web体系架构。http://canonical.javaeye.com/blog/33824
Witrix架构呈"可"字形态，其中定义了三条主要的分界线:
1. 浏览器和服务器之间通过语义结构明晰的URL形成两分结构。http://canonical.javaeye.com/blog/99122
2. 系统前台至后台存在一条预制的非侵入的信道. 它维持了一种无害的可扩展 ...
程序中大量的工作其实都是在定义结构以及结构之间的关系. 一般情况下我们应该识别出结构,并把它们封装到函数,对象和组件中去. 但是封装并不永远都是有利的. 将某个结构独立出来, 在某种程度上也就割裂了它和其他元素之间的关系, 这会引发结构融合的障碍, 也会造成思维上的负担. 事实上如果程序整体具有足够的可理解性和概念稳定性, 我们并不需要独立识别出什么子部分. 一个简单的例子是数组循环. 一般情况下我们应该尽量把循环查找等操作封装到函数中, 避免多重循环嵌套时产生过于复杂的代码块. 但是如果数组或者语言本身提供了each, map等函数式操作符,则这种封装需 ...
元数据(meta)是描述数据的数据。它所描述的有一部分是数据本身的特性，如字段的长度，精度等，另外一部分描述的则是我们使用这些数据的可行方式和目的等。使用meta可以在程序中更加清楚的表达出我们的意图。例如现在需要在界面上显示一个列表，我们的意图未必是要在界面上显示指定的字段A, 字段B,字段C对应的列，而是"显示那些应该显示在列表中的字段"。这一看似同义反复的表述，如果采用元数据表达，则成为 <ui:PageTable fields="${dsMeta.listableFields}" />。通过使用元数据，我们可 ...
ORM（Object Relational Mapping）技术为什么是有效的？对这个问题一般的答案是ORM解决了面向对象技术和关系数据库之间的阻抗匹配问题。但是任何一种成功的技术，它的支持理由都不会是单一的。在Witrix平台的实践中，ORM的如下几个特性是关键性的：
1. 主键和对象之间的一一对应关系。在Web应用中，前台浏览器持有的只能是对象的某种表示, 因此一种locator机制是最基础的要求。
2. Container结构。Container所拥有的信息包括其所有元素以及元素之间的关系。因为Container具有全局知识,所以它可以解决对 ...
REST(Representational State Transfer) 是Roy Thoms Fielding在其博士论文中所提出的一种架构风格（Architectual Style）。http://roy.gbiv.com/pubs/dissertation/top.htm http://www.redsaga.com/opendoc/REST_cn.pdf 可以说它也体现了整个互联网架构的基本设计原则。随着AJAX等技术的发展，互联网的资源语义逐渐得以恢复，最近对于REST的讨论也热烈起来。http://www.ibm.com/developerworks/c ...
今天adun给我讲了一个他所谓可退化的设计，在我看来问题还是多多。从直观的角度上说，在java中声明一个具有多个参数的函数，调用的时候对于不需要用到的参数都传入null, 这不是理想的可退化场景。所谓的退化不仅仅是概念层面的，不仅仅是关于语义的，很大程度上它也是形式上的，是关于语法结构的。
理想的退化场景是尽量维持形式/结构稳定性的情况下实现诠释范围的缩减，在任何层面上都不需要知道超出当前需要的信息。而如果我们被要求必须传入自己实际上不需要使用的参数，则必然存在着一定程度上的信息泄漏。一个朴素的看法应该是，当我们需要 ...
命名(Naming)无疑是人们认识世界最基本的手段之一。从软件技术的发展中我们也可以观察到命名技术的不断深化。
1. 助记的名：汇编之中我们有了move/push/pop这样的指令，所面对的不再是010101这样的同质的数字世界。变量也逐渐可以拥有自己的名字，甚至多个名字。在C语言中指针的概念被进一步抽象化，使得我们可以为任意内存地址起一个可读的名字。我们甚至渐渐忘怀了pStruct是指针的名字，而直接把它等同于指针所指的内容本身。
2. 局部的名：函数(例程)概念的出现把局部 ...
软件这个领域中传统上占优势的是自vonNeumann以降的数学视角，计算问题是其思想内核，而函数式语言无疑是其比较贴切的表现。但是仅有数学，我们对于世界的认识是不充分的。有这样一个笑话。烧一壶水的完整步骤如下：1.向空壶中注满水 2.放到火炉上 3.烧到冒泡。现在有半壶水，求解烧水的步骤。数学家的回答是直接把半壶水倒掉，然后宣称问题已经解决，因为它已经被归结为第一个问题。实际上数学的视角直接限制了某些命题进入研究者的领域。现在业界占主流的面向对象技术，并不像是理论界的自然创造，它的思想来源更像是来自于开发窗口系统的工程实践。http://gagne.hom ...
最近D语言发布了1.0版，这是一个由编译器开发者所设计的编译语言，语法类似C++, 但是针对C++的弊病作了大量修正，并增加了很多现代特征，其中还是有一些新意在其中的。http://www.digitalmars.com/d/overview.html 我对其比较感兴趣的部分是D语言明确提出的编译期运行的概念。虽然C++让大众了解了meta programming技术，很多人因此认为meta programming的威力在于类型演算，但是在我看来meta programming的真正作用在于在编译期可以“动态”产生或调整代码结构。它依赖于类型是 ...
代码生成现在已经逐渐成为软件开发中的一种标准技术，在众多的软件领域都大大减轻了我们重复劳动的工作量。程序中总是存在着这样那样的隐蔽的关联，它们无法在通用的程序语言框架下得到明确的表达，代码生成是我们突破既定的语言和框架限制的一种重要手段。但是代码生成也存在着严重的弊病，一方面一般的程序语言在设计时没有考虑到和代码生成工具的相互配合，因此生成代码是一次性的，代码生成工具无法以增量的方式修正已经生成的代码。另一方面，程序的结构是复杂的，代码生成工具一般基于某种简化的通用的程序模型（例如CRUD)来产生代码，它无法承载完整的程序结构，因此 ...
目前的AOP(Aspect Oriented Programming)技术虽然以动态代码织入为核心，但是这种织入仍然是一次性的。一般在系统构造的时候(例如ClassLoader装载Class的时候)实现类和成员函数的增强。此后在运行时刻代码结构是固定的而不再发生变化。但是在真正的业务处理过程中，我们在不同的应用场景下可能要求织入不同的Aspect。例如基本的权限Aspect, 如果在不同的应用场景有不同的权限设定，则我们显然希望进入一个确定的操作场景的时候就指定一整套的权限策略，而不是在每个函数调用时刻写上一大堆的if/ ...
几年前Michael Atiyah受邀在浙江大学做过一个讲演，题目是Mathematics in the 20th Century,
http://www.cnw3.org/smth/Mathematics/historiesandmathmaticians/goodessays/00000035.htm， 在其中他回顾了二十世纪的主要的数学发展。被他列在第一条的进展就是From Local To Global. 在传统上，数学的主要研究对象是一些得到显性表达的局部公式，而拓扑学对于整体性的“不变性质”的研究最终将我们对于数学和物理学的理解推进到一个新 ...
http://partech.blogdriver.com/partech/1217744.html
partech基于AspectJ对于AOP的深入应用作了一些有益的探索。ORM的价值之一正在于通过ORM引擎对于对象上的局部操作作出持久化诠释（参见 面向对象之形式系统 ）。在partech的方案中，对象删除操作(destroy)的引入显得有些勉强：因为我们需要标记一个删除的时刻，所以调用了一次空的destroy()方法。但是如果在事件驱动的应用场景中，调用时刻唾手可得，这样的问题便很少出现了。
我个人所关心的方向主要是框架层面上对于AOP概念的应 ...
面向对象技术中最重要的概念是什么？在面向对象理论发展的初期，几乎所有的正统声音都在鼓吹继承(inheritance)概念，言必称虚拟函数和多态性。但是依赖继承这种推导关系来构建庞大系统的弊病在实践中逐渐暴露出来，随着组件(Component)技术的发展，所谓的封装概念逐渐被推崇为面向对象思想的精华。在此过程中，接口(interface)概念作为系统细粒度正交分解的手段也逐渐发展起来。在软件系统结构的日益复杂化的今天，封装概念开始成为了质疑的对象。是否与一个概念相关的所有实现都要统一封装到一个具体的对象中？伴随着Java，C#等语言进入主流程序界的AOP(A ...
实现是一种具体的东西，对于同一种实现可以有不同层面的各异的诠释，而每一种诠释都可能对应于不同的概念体系。对于一种具体的技术实现，总有人争论说这样这样一下，不是也可以做到什么什么效果吗。但这只是实现上在某种程度上可以达到目标，并不意味着该实现基于的概念体系自身直接体现了我们所需要的结构。这就如同我们可以用汇编实现一切，但并不意味着汇编语言本身的结构包含了所有高级程序结构一样。同样，说到一种失败的技术的时候，也需要区分清楚问题是出在实现细节上还是对应的概念体系上。
在我看来，软件开发就是一个从二进制指令构造出一些高级结构的过程(from
binary chaos to artificial
intelligence)。这种构造依赖于我们控制各种结构的能力。结构化编程向我们展现了一个机械化的分解与合成的世界，但这个世界与我们的真实世界
却差异良多。于是，面向对象编程试图直接跳跃到真实的世界，依赖于我们对真实世界中结构的控制能力，直接对真实的结构建模。早期面向对象技术的陈述中充斥
着这种乌托邦式的理想图景。但是这种隐喻是含混的，两个世界的巨大差异造成了必然的转换成本，我们只能压缩这种成本而不可能完全抛弃它，我们必须要经历 ...
canonical
- 浏览: 99109 次
- 性别:
- 来自: 北京
- 详细资料
搜索本博客
最近加入圈子
链接
最新评论
-
关于REST
说的太抽象，看完之后好像是理解了，又好像很模糊。
-- by zjq_blog -
[导入]关于jsplet的一些 ...
我有一个疑问：把一个request || response带入到biz里面会不会 ...
-- by deepthink -
C++配置管理
boost里已经有现成的啦！
-- by jimmy_c -
不完全的计算
当我们 oo 的时候，一般都不认为自己在“计算”，当我们计算的时候，根本就想不起 ...
-- by hotman_x -
面向集合的框架设计
嘿嘿，说句不合时宜的话，一个事物“完美”是因为它已经没有价值，没有改进的必要。费 ...
-- by hotman_x
评论排行榜