??xml version="1.0" encoding="utf-8" standalone="yes"?>亚洲熟妇无码久久精品,国产精品亚洲精品日韩电影,久久亚洲AV成人无码电影http://www.tkk7.com/canonical/category/4849.htmlzh-cnSun, 08 May 2011 22:31:23 GMTSun, 08 May 2011 22:31:23 GMT60从面向对象到面向切面http://www.tkk7.com/canonical/archive/2011/05/08/349771.htmlcanonicalcanonicalSun, 08 May 2011 04:07:00 GMThttp://www.tkk7.com/canonical/archive/2011/05/08/349771.htmlhttp://www.tkk7.com/canonical/comments/349771.htmlhttp://www.tkk7.com/canonical/archive/2011/05/08/349771.html#Feedback0http://www.tkk7.com/canonical/comments/commentRss/349771.htmlhttp://www.tkk7.com/canonical/services/trackbacks/349771.html
2. 面向对象(OOP)指出Q在q一领域上可以徏立分l?group)l构Q一l相关的变量和函数构成一个集合,我们UC为对?Object)。同时在分组l构上可以定义一个运?推理)关系:  D > B, zcD从基cBl承Qinheritance)Q相应的z对象W合基类对象所满的所有约束。推理是有h值的Q因为根?D > B, B > A 可以自动推导?D > AQ所有针对A的断a在理Z对D都成?q也是我们常说?#8220;z对象 is a 基类对象”)。编译器也能有点了?br />    一个有的地方是,D > B意味着在D和B之间存在着某种差异Q但是我们却无法把它昑ּ的表辑և来!也就是说在代码层面上我们无法明确表达 D - B是什么。ؓ了把更多的信息不断的导入到原有系l中Q面向对象内|提供的Ҏ是徏立不断扩展的cd树,cd树每增长一层,可以多容纳一些新的信息。这是一U金字塔式的l构Q只不过是一U倒立的金字塔Q最l基点会被不断增长的l构压力所压垮?br />
3. lg技?Component)本质上是在提倡面向接?interface)Q然后通过接口之间的组?Composition)而不是对象之间的l承(inheritance)来构造系l。基于组合的观念相当于是定义了运关p:D = B + C。终于,我们勉强可以在概念层面上做加法了?br />    lg允许我们随意的组合,按照q单到复杂的方向构造系l,但是lg构成的成品之间仍然无法自q建立关系。这意味着lgl装得到的成品只是某U孤立的Q偶然的产物?br />    F = A + B + C  ? G = A + D + C?br />
4. 在数学上Q配备了加法q算的集合构成半,如果要成为群(Group)Q则必须定义相应的逆运:减法?结构得大_度的结构变换成为可能?br />    F = A + B + C = A + D - D + B + C = (A + D + C) - D + B = G - D + B
   在不破坏原有代码的情况下Q对原有pȝ功能q行增删Q这是面向切面(AOP)技术的全部价倹{?br />



canonical 2011-05-08 12:07 发表评论
]]>
业务架构q_的自N?/title><link>http://www.tkk7.com/canonical/archive/2011/02/11/344053.html</link><dc:creator>canonical</dc:creator><author>canonical</author><pubDate>Fri, 11 Feb 2011 06:02:00 GMT</pubDate><guid>http://www.tkk7.com/canonical/archive/2011/02/11/344053.html</guid><wfw:comment>http://www.tkk7.com/canonical/comments/344053.html</wfw:comment><comments>http://www.tkk7.com/canonical/archive/2011/02/11/344053.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.tkk7.com/canonical/comments/commentRss/344053.html</wfw:commentRss><trackback:ping>http://www.tkk7.com/canonical/services/trackbacks/344053.html</trackback:ping><description><![CDATA[   业务架构q_的设计与实现要比普通业务系l困隑־多。一个核心难点在于如何徏立普遍有效的应用E序模型Q如何控制各U偶然性的业务需求对pȝ整体架构的冲凅R大多数现有的业务架构^台都是提供了一个庞大的万能性品,它预料到了所有可能在业务pȝ开发中出现的可能性,q提供了相应的处理手Dc业务系l开发h员的能力被限定在业务架构q_所允许的范围之内。如果业务架构^台的复杂度ؓA+Q则我们最多只能用它来开发复杂度为A的业务系l。一个典型的特征是使用业务架构q_的功能配|非常简单,但是要开发相应的功能Ҏ则非常困难Q而且必须采用与业务系l开发完全不同的技术手D和开发方式?br />    采用业务架构q_来开发业务系l,即看似开发工作量,最l生的各类配置代码量也可能会大大超q普通手工编E生的代码量,q意味着q_装了业务内在的复杂性,q是意味着q_引入了不必要的复杂性?很多业务架构q_的卖炚w是零代码的应用开发,低水q的开发h员也可以d的开发,但是Z么高水^的程序员不能借助于这些开发^台极大的提高生率?<br />    一般的业务架构q_无法回答以下问题Q?br /> 1) 业务pȝ可以通过使用设计工具来重用业务架构^台已l实现的功能Q但是业务系l内部大量相似的模型配置如何才能够被重用Q?br /> 2) 特定的业务领域中存在着大量Ҏ的业务规则,例如“审批串行q行Q每一步都允许回退C一步,而且允许选择跌{CQ意后一?#8221;。这些规则如何才能够被引入设计工P化配|过E?<br /> 3) 已经开发好的业务系l作Z品来销售的时候,如何应对具体客户的定制化Q如果按照客戯求修攚w|,则以后业务系l自w是否还能够实现版本升Q?br />    <br />    Witrixq_提供的基本开发模型ؓ <br />           <strong>App = Biz aop-extends Generator<DSL></strong><br /> 在这一图景下,我们可以回{以上三个问题:<br /> 1) 业务模型通过领域特定语言(DSL)来表达,因此可以使用语言中通用的承或者组件抽象机制来实现模型重用?br /> 2) 推理机对于所有推理规则一视同仁,Ҏ的业务规则与通用的业务规则一样都可以参与推理q程Qƈ且一般情况下Ҏ的业务规则更能够大幅化系l实现结构?br /> 3) 相对于原始模型的修改被独立出来,然后应用面向切面(AOP)技术将q些特定代码l入到原始模型中。原始模型与差异修改怺分离Q因此原始模型可以随时升U?br /> <br />   Witrixq_所的不是强大的功能Q而是一切表象之后的数学规律。Witrixq_通过数基本原理的反复应用来构造Y件系l,它本w就是采用^台技术构造的产物。我们用复杂度ؓA的工具制造复杂度为A+的品,然后q一步以q个复杂度ؓA+的品ؓ工具来构造复杂度为A++的品?br /> <br /> <img src ="http://www.tkk7.com/canonical/aggbug/344053.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.tkk7.com/canonical/" target="_blank">canonical</a> 2011-02-11 14:02 <a href="http://www.tkk7.com/canonical/archive/2011/02/11/344053.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>模型驱动的数学原?/title><link>http://www.tkk7.com/canonical/archive/2011/02/07/343919.html</link><dc:creator>canonical</dc:creator><author>canonical</author><pubDate>Sun, 06 Feb 2011 18:56:00 GMT</pubDate><guid>http://www.tkk7.com/canonical/archive/2011/02/07/343919.html</guid><wfw:comment>http://www.tkk7.com/canonical/comments/343919.html</wfw:comment><comments>http://www.tkk7.com/canonical/archive/2011/02/07/343919.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.tkk7.com/canonical/comments/commentRss/343919.html</wfw:commentRss><trackback:ping>http://www.tkk7.com/canonical/services/trackbacks/343919.html</trackback:ping><description><![CDATA[<p>    一U技术思想如果实能够化编E,有效降低pȝ构造的复杂性,那么它必然具有某U内在的数学解释。反之,无论一U技术机制显得如何华丽高深,如果它没? 清晰的数学图象,那么很难证明自w存在的价倹{对于模型驱动架?MDA)Q我长期以来一直都持有一U批判态度。(Physical Model Driven<a > http://canonical.javaeye.com/blog/29412</a> Q。原因就在于“由工兯动实Cq_无关模型(PIM)向^台相x?PSM)的{?#8221;q一图景g只是xpȝ从实现的泥沼中拯救出来,遮蔽特定? aQ特定^C的偶然的限制条gQƈ没有触及到系l复杂性这一核心问题。而所谓的可视化徏模充光不过是说明hc超强的视觉模式识别能力使得我们可以q? 识别pȝ全景图中隐含的整体结构,更快的实现对pȝl构的理解,q没有证明系l复杂性有M本质性的降低。不q如果我们换一个视? 不把模型局限ؓ某种可视化的l构?而将它定义ؓ某种高度羃的领域描q? 则模型驱动基本上{h于根据领域描q自动推导得到最l的应用E序。沿着q一思\QWitrixq_中的很多设计实际上可以被解释为模型定义,模型推导以及 模型嵌入{方面的探烦。这些具体技术的背后需要的是比一般MDA思想更加_致的设计原理作为支撑。我们可以进行如下抽象分析。(Witrix架构分析 <a >http://canonical.javaeye.com/blog/126467</a> Q?br /> <br /> 1. 问题复杂Q线性切分是削减问题规模Q从而降低问题复杂性)的通用手段Q例如模?Module)。(软g中的分析?<a >http://canonical.javaeye.com/blog/33885</a> Q?/p> <div style="background-color: #eeeeee; font-size: 13px; border: 1px solid #cccccc; padding: 4px 5px 4px 4px; width: 98%;"><!--<br /> <br /> Code highlighting produced by Actipro CodeHighlighter (freeware)<br /> http://www.CodeHighlighter.com/<br /> <br /> --><span style="color: #000000;">App </span><span style="color: #000000;">=</span><span style="color: #000000;"> M1 </span><span style="color: #000000;">+</span><span style="color: #000000;"> M2 </span><span style="color: #000000;">+</span><span style="color: #000000;"> M3 </span><span style="color: #000000;">+</span><span style="color: #000000;"> <img src="http://www.tkk7.com/Images/dot.gif" alt="" />    <br /> </span></div> <p><br /> </p> <p>2. 分块q多Q同态映是pȝU化的一般化{略Q例如多态(polymorphismQ。(同构与同态:认识同一?<a >http://canonical.javaeye.com/admin/blogs/340704</a> Q?/p> <div style="background-color: #eeeeee; font-size: 13px; border: 1px solid #cccccc; padding: 4px 5px 4px 4px; width: 98%;"><!--<br /> <br /> Code highlighting produced by Actipro CodeHighlighter (freeware)<br /> http://www.CodeHighlighter.com/<br /> <br /> --><span style="color: #000000;">(abc,abb,ade,<img src="http://www.tkk7.com/Images/dot.gif" alt="" />) </span><span style="color: #000000;">-></span><span style="color: #000000;"> [a],   (bbb, bcd,bab,<img src="http://www.tkk7.com/Images/dot.gif" alt="" />) </span><span style="color: #000000;">-></span><span style="color: #000000;"> [b]</span></div> <p><br /> </p> <p>3. 递归使用以上两种ҎQ将分分合合的游戏进行到底,推向极致?br /> <br /> 4. 以少控多的终极Ş态?如果存在Q则构成输入与输Z间的非线性变换(输入中局部微变化将D输出中大范围明显的变化)?/p> <div style="background-color: #eeeeee; font-size: 13px; border: 1px solid #cccccc; padding: 4px 5px 4px 4px; width: 98%;"><!--<br /> <br /> Code highlighting produced by Actipro CodeHighlighter (freeware)<br /> http://www.CodeHighlighter.com/<br /> <br /> --><span style="color: #000000;">App </span><span style="color: #000000;">=</span><span style="color: #000000;"> F(M)</span></div> <p><br /> </p> <p>5. 变换函数F可以被诠释ؓ解释?Interpreter)或者翻译机Q例如工作流引擎工作流描述信息译Z步步的具体操作,工作描q可以看作是由底 层引擎支撑的Q在更高的抽象层面上q行的领域模型。但是在q种观点下,变换函数Fg是针ҎU特定模型构造的Q引擎内部信息传导的途径是确定的Q关注的 重点始终在模型上Q那么解释器自n应该如何被构造出来呢Q?/p> <div style="background-color: #eeeeee; font-size: 13px; border: 1px solid #cccccc; padding: 4px 5px 4px 4px; width: 98%;"><!--<br /> <br /> Code highlighting produced by Actipro CodeHighlighter (freeware)<br /> http://www.CodeHighlighter.com/<br /> <br /> --><span style="color: #000000;">App </span><span style="color: #000000;">~</span><span style="color: #000000;"> M</span></div> <p><br /> </p> <p>6. 另外一U更加开攄观点是将变换函数F看作是生成器(Generator)或者推理机。F根据输入的信息Q结合其他知识,推理生成一pd新的命题和断 a。模型的力量源于推导。变换函数F本n在系l构造过E中处于核心CQM仅仅是触发其推理q程的信息源而已。F榨qM的最后一点剩余h|所有根据M 能够定的事实将被自动实玎ͼ而大量单靠M自n的信息无法判定的命题也可以结合F内在的知识作出判断。生成器自n的构造过E非常简?-只要不断向推理系 l中增加新的推理规则卛_。语a内置的模板机?template)及元~程技?meta programming)Q或者跨语a边界的代码生成工具都可以看作是生成器的具体实例。(关于代码生成和DSL <a >http://canonical.javaeye.com/blog/275015</a> )</p> <div style="background-color: #eeeeee; font-size: 13px; border: 1px solid #cccccc; padding: 4px 5px 4px 4px; width: 98%;"><!--<br /> <br /> Code highlighting produced by Actipro CodeHighlighter (freeware)<br /> http://www.CodeHighlighter.com/<br /> <br /> --><span style="color: #000000;">App </span><span style="color: #000000;">=</span><span style="color: #000000;"> G</span><span style="color: #000000;"><</span><span style="color: #000000;">M</span><span style="color: #000000;">></span></div> <p><br /> </p> <p>7. 生成器G之所以可以被独立实现Q是因ؓ我们可以实现相对知识与绝对知识的分离, q也正是面向对象技术的本质所在。(面向对象之Ş式系l?<a >http://canonical.javaeye.com/blog/37064</a> Q?/p> <div style="background-color: #eeeeee; font-size: 13px; border: 1px solid #cccccc; padding: 4px 5px 4px 4px; width: 98%;"><!--<br /> <br /> Code highlighting produced by Actipro CodeHighlighter (freeware)<br /> http://www.CodeHighlighter.com/<br /> <br /> --><span style="color: #000000;">G</span><span style="color: #000000;"><</span><span style="color: #000000;">M</span><span style="color: #000000;">></span><span style="color: #000000;"> </span><span style="color: #000000;">==></span><span style="color: #000000;"> G </span><span style="color: #000000;">=</span><span style="color: #000000;"> {m </span><span style="color: #000000;">=></span><span style="color: #000000;"> m.x(a,b,c);m.y(); <img src="http://www.tkk7.com/Images/dot.gif" alt="" /> }</span></div> <p><br /> </p> <p>8. 现实世界的不完美Q就在于现实决不按照我们为其指定的理惌\U前q。具体场景中L存在着大量我们无法预知?#8220;噪声”Q它们得Q何在“q去”立的方E? 都无法在“未来”保持持久的^衡。传l模型驱动架构的困境在于此。我们可以选择模型M和生成器G不断复杂化,容纳来多的偶然性,直至失去Ҏ型整 体结构的控制力。另外一U选择是模型在不断膨胀Q不断提高覆盖能力的q程中,不断的空z化Q生大量可插入(plugin)的接入点Q最l失模型的推理 能力Q退化成ZU编码规范。Witrixq_中采用的是第三种选择Q模型嵌?-模型中的多余信息被不断清z掉Q模型通过_化来H出自n存在的合? 性,成ؓ更广泛的q行环境中的支撑骨架。(l构的自x?<a >http://canonical.javaeye.com/blog/482620</a> Q?/p> <div style="background-color: #eeeeee; font-size: 13px; border: 1px solid #cccccc; padding: 4px 5px 4px 4px; width: 98%;"><!--<br /> <br /> Code highlighting produced by Actipro CodeHighlighter (freeware)<br /> http://www.CodeHighlighter.com/<br /> <br /> --><span style="color: #000000;">App </span><span style="color: #000000;">!=</span><span style="color: #000000;"> G0</span><span style="color: #000000;"><</span><span style="color: #000000;">M0</span><span style="color: #000000;">></span><span style="color: #000000;">  Q?nbsp;App </span><span style="color: #000000;">!=</span><span style="color: #000000;"> G0</span><span style="color: #000000;"><</span><span style="color: #000000;">M1</span><span style="color: #000000;">></span><span style="color: #000000;">Q?nbsp;App </span><span style="color: #000000;">=</span><span style="color: #000000;"> G1</span><span style="color: #000000;"><</span><span style="color: #000000;">M1</span><span style="color: #000000;">></span><span style="color: #000000;"> <br /> </span></div> <p><br /> </p> <p>9. 现在的问题是Q如何基于一个已l被完美解决的重大问题,来更有效率的搞定不断出现但又不是重复出现的小问题。现在我们所需要的不是沿着某个l度q行均匀? 切分Q而必L某种有效的降l手Dc如果我们可以定义一U投q子P, 待解决的问题投到已经被解决的问题域中Q则剩下的补集往往可以被简化。(M分解而不是正交分?<a >http://canonical.javaeye.com/blog/196826</a> Q?/p> <div style="background-color: #eeeeee; font-size: 13px; border: 1px solid #cccccc; padding: 4px 5px 4px 4px; width: 98%;"><!--<br /> <br /> Code highlighting produced by Actipro CodeHighlighter (freeware)<br /> http://www.CodeHighlighter.com/<br /> <br /> --><span style="color: #000000;">dA </span><span style="color: #000000;">=</span><span style="color: #000000;"> App </span><span style="color: #000000;">-</span><span style="color: #000000;"> P[App]  </span><span style="color: #000000;">=</span><span style="color: #000000;"> App </span><span style="color: #000000;">-</span><span style="color: #000000;"> G0</span><span style="color: #000000;"><</span><span style="color: #000000;">M0</span><span style="color: #000000;">></span></div> <p><br /> </p> <p>10. 要实C上微扰分析策略,前提条g是可以定义逆元Qƈ且需要定义一U精l的_结操作Q可以将分散的扰动量极ؓ_的应用到基础pȝ的各处。Witrixq_的具体实现类g某种AOPQ面向切面编E)技术。(逆元Q不存在的真实存?<a >http://canonical.javaeye.com/blog/325051</a> Q?/p> <div style="background-color: #eeeeee; font-size: 13px; border: 1px solid #cccccc; padding: 4px 5px 4px 4px; width: 98%;"><!--<br /> <br /> Code highlighting produced by Actipro CodeHighlighter (freeware)<br /> http://www.CodeHighlighter.com/<br /> <br /> --><span style="color: #000000;">App </span><span style="color: #000000;">=</span><span style="color: #000000;"> A </span><span style="color: #000000;">+</span><span style="color: #000000;"> D </span><span style="color: #000000;">+</span><span style="color: #000000;"> B </span><span style="color: #000000;">=</span><span style="color: #000000;"> (A </span><span style="color: #000000;">+</span><span style="color: #000000;"> B </span><span style="color: #000000;">+</span><span style="color: #000000;"> C) </span><span style="color: #000000;">-</span><span style="color: #000000;"> C </span><span style="color: #000000;">+</span><span style="color: #000000;"> D </span><span style="color: #000000;">=</span><span style="color: #000000;"> App0 </span><span style="color: #000000;">+</span><span style="color: #000000;"> (</span><span style="color: #000000;">-</span><span style="color: #000000;">C </span><span style="color: #000000;">+</span><span style="color: #000000;"> D) </span><span style="color: #000000;">=</span><span style="color: #000000;"> G0</span><span style="color: #000000;"><</span><span style="color: #000000;">M0</span><span style="color: #000000;">></span><span style="color: #000000;"> </span><span style="color: #000000;">+</span><span style="color: #000000;"> dA</span></div> <p><br /> </p> <p>11. 模型驱动q不意味着一个应用只能由唯一的一个模型来驱动Q但是如果引入多个不同Ş式的模型Q则必须为如下推理提供具体的技术\径:<br />   A. 多个模型变换到共同的描q域 <br />   B. 实现多个模型的加?<br />   C. 处理模型之间的冲Hƈ填补模型之间的空?br /> 在Witrixq_中模型嵌?l合主要依赖于文本化及编译期q行{机制。(文本?<a >http://canonical.javaeye.com/blog/309395</a> Q?/p> <div style="background-color: #eeeeee; font-size: 13px; border: 1px solid #cccccc; padding: 4px 5px 4px 4px; width: 98%;"><!--<br /> <br /> Code highlighting produced by Actipro CodeHighlighter (freeware)<br /> http://www.CodeHighlighter.com/<br /> <br /> --><span style="color: #000000;">App </span><span style="color: #000000;">=</span><span style="color: #000000;"> Ga</span><span style="color: #000000;"><</span><span style="color: #000000;">Ma</span><span style="color: #000000;">></span><span style="color: #000000;"> </span><span style="color: #000000;">+</span><span style="color: #000000;"> Gb</span><span style="color: #000000;"><</span><span style="color: #000000;">Mb</span><span style="color: #000000;">></span><span style="color: #000000;"> </span><span style="color: #000000;">+</span><span style="color: #000000;"> dA</span></div> <p><br /> </p> <p>12. pȝ的开发时刻t0和实施时刻t1一般是明确分离的,因此如果我们要徏立一个包含开发与实施时刻信息的模型,则这一模型必须是含时的Q多阶段的。关于时 _我们所知道的最重要的事实之一?#8220;未来是不可预知的”。在t0时刻建立的模型如果要늛t1时刻的所有变化,则必d出大量猜,而且t1时刻距离 t0时刻远Q猜的量越大,“猜测有效”q一集合的测度越,直至?。gq选择是实现含时系l控制的不二法门?br />    在Witrixq_中,所有功能特性的实现都包含某U元数据描述或者定制模板,因此l合配置机制以及动态编译技术既可实现多阶段模型。例如对于一个在未来 才能定的常量数l,我们可以定义一个Excel文g来允许实施h员录入具体的|然后通过动态编译技术在~译期解析Excel文gQƈ完成一pd数值映 运,最l将其{化ؓ~译期存在的一个常量。这一q程不会引入M额外的运行成本,也不要求M特定的缓存机Ӟ最l的q行l构与在未来当所有信息都? 位之后再手写代码没有M区别。(D语言与tpl之编译期动作 <a >http://canonical.javaeye.com/blog/57244</a> Q?/p> <div style="background-color: #eeeeee; font-size: 13px; border: 1px solid #cccccc; padding: 4px 5px 4px 4px; width: 98%;"><!--<br /> <br /> Code highlighting produced by Actipro CodeHighlighter (freeware)<br /> http://www.CodeHighlighter.com/<br /> <br /> --><span style="color: #000000;">App(t1) </span><span style="color: #000000;">=</span><span style="color: #000000;"> G(t0,t1)</span><span style="color: #000000;"><</span><span style="color: #000000;">M(t0,t1)</span><span style="color: #000000;">></span><span style="color: #000000;"> </span><span style="color: #000000;">+</span><span style="color: #000000;"> dA(t0,t1)</span></div> <p><br /> </p> <p>13. U列理论提供了一个演化框Ӟ它指出孤立的模型必须被放在模型列中被定义,被解释。(关于U列设计理论 <a >http://canonical.javaeye.com/blog/33824</a> Q?/p> <div style="background-color: #eeeeee; font-size: 13px; border: 1px solid #cccccc; padding: 4px 5px 4px 4px; width: 98%;"><!--<br /> <br /> Code highlighting produced by Actipro CodeHighlighter (freeware)<br /> http://www.CodeHighlighter.com/<br /> <br /> --><span style="color: #000000;">M[n] </span><span style="color: #000000;">=</span><span style="color: #000000;"> G</span><span style="color: #000000;"><</span><span style="color: #000000;">M[n</span><span style="color: #000000;">-</span><span style="color: #000000;">1</span><span style="color: #000000;">]</span><span style="color: #000000;">></span><span style="color: #000000;"> </span><span style="color: #000000;">+</span><span style="color: #000000;"> dMn</span></div> <p><br /> </p> <p>14. 推理的链条会因ؓM局部反例的出现而中断。在L时空点上Q我们能够断a的事实有哪些Q信息越,我们能够定的事实越,能够做出的推Zp。现 在流行的很多设计实质上是在破坏系l的对称性,破坏pȝ大范围的l构。比如明明ORM容器已经实现所有数据对象的l一理Q非要将其拆分ؓ每个业务表一? 的DAO接口。很多对灉|性的q求完全没有搞清楚信息是对不定性的消除Q而不定性的减少意味着限制的增加,U束的增加。(From Local To Global <a >http://canonical.javaeye.com/blog/42874</a> Q?br /> <br />    lg/构g技术的宣言是生产即l装Q但是组装有成本Q有后遗症(例如需要额外的胶水或者螺钉)。Y件的本质q不是物质,而是信息Q而信息的本质是抽象的? 律。在抽象世界中最有效的生产方式是抽象的运,q算即生产。组件式开发意味着服从现有规律Q熟l应用,而原理性生产则意味着不断创造新的规律。功能模 块越多,l护的成本越高,是负担,而推理机制越多,生的成本越低,是胦富。只有恢复Y件的抽象性,明确把握软g构造过E内在的数学原理Q才能真正释放Y 件研发的生力。(从编写代码到刉代?<a >http://canonical.javaeye.com/blog/333167</a> Q?br /> </p> <p><br /> </p> <p>注解1Q很多设计原则其实是在强调Y件由人构造由人理解,软g开发本质上是hcdE学Q需要关注hcȝ理解力与协作能力。例如共同的建模语言减少交互成本Q基于模型减设计与实现的分,易读的代码比高性能的代码更重要Q做一件事只有唯一的一U方式等?br /> <br /> 注解2Q生成系l的演绎q比我们惌的要深刻与复杂得多。例如生命的成长可以被看作是在外界反馈下不断调整的生成过E?br /> <br /> 注解3Q领域描q是更紧致但却未必是更本质的表达。hcȝDNA如果表达为ATGC序列完全可以拯到U盘中带走Q只要对DNA做少量增删,可以实现? 鼠到人类的变换(人类和老鼠都有大约30000条基因,其中U有80%的基因是“完全一L”Q大U共享有99%的类似基因)Q但是很难认ZhcL有智? 的本质都体现在DNA中,DNA看v来更像是某种序列化保存Ş式而已?br /> <br /> 注解4Q模型{换这一提法g是在模型之间的同构对应,转换gL可以双向q行的,仅仅是实现难度限制了反向转换而已。但是大量有用的模型变换却是单向的,变换q程要求不断补充新的信息?br /> <br /> 注解5Q模型驱动在很多人看来就是数据库模型或者对象模型驱动系l界面运行,但实际上模型可以意指L抽象知识。虽然在目前业内q泛行的对象范式下Q所 有知识都可以表达为对象之间的兌Q但是对象关p(名词之间的关联关p)对运结构的揭示是远q不够充分的。很多时候所谓的领域模型仅仅是表明概念之间具 有相x,但是如果不补充一大段文字说明Q我们对于系l如何运作仍然一知半解。数学分析其实是领域内在的意义抽空Q仅余下通用的Ş式化W号?br /> </p> <img src ="http://www.tkk7.com/canonical/aggbug/343919.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.tkk7.com/canonical/" target="_blank">canonical</a> 2011-02-07 02:56 <a href="http://www.tkk7.com/canonical/archive/2011/02/07/343919.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>l构的稳定?/title><link>http://www.tkk7.com/canonical/archive/2009/12/06/304906.html</link><dc:creator>canonical</dc:creator><author>canonical</author><pubDate>Sun, 06 Dec 2009 04:23:00 GMT</pubDate><guid>http://www.tkk7.com/canonical/archive/2009/12/06/304906.html</guid><wfw:comment>http://www.tkk7.com/canonical/comments/304906.html</wfw:comment><comments>http://www.tkk7.com/canonical/archive/2009/12/06/304906.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.tkk7.com/canonical/comments/commentRss/304906.html</wfw:commentRss><trackback:ping>http://www.tkk7.com/canonical/services/trackbacks/304906.html</trackback:ping><description><![CDATA[   l构的稳定性,直观的理解v来,是l构在存在外部扰动的情况下长旉保持某种形式不变性的能力。稳定意味着的扰动造成的后果也?#8220;?#8221;的。在数学中,TaylorU数为我们描l了变化传播的基本图景?br /> <br />  <br /> <div style="border: 1px solid #cccccc; padding: 4px 5px 4px 4px; background-color: #eeeeee; font-size: 13px; width: 98%;"><!--<br /> <br /> Code highlighting produced by Actipro CodeHighlighter (freeware)<br /> http://www.CodeHighlighter.com/<br /> <br /> --><span style="color: #000000;">F(x0 </span><span style="color: #000000;">+</span><span style="color: #000000;"> dx) </span><span style="color: #000000;">=</span><span style="color: #000000;"> F(x0) </span><span style="color: #000000;">+</span><span style="color: #000000;"> F</span><span style="color: #000000;">'</span><span style="color: #000000;">(x0)*dx + 0.5*F</span><span style="color: #000000;">''</span><span style="color: #000000;">(x0)*dx^2 + <img src="http://www.tkk7.com/Images/dot.gif" alt="" /></span></div> <br /> 扰动dx可能在系lF中引发非常复杂的作用q程Q在pȝ各处产生一个个局部变化结果。表面上看v来,gq些变化l果存在着无穷多种可能的分l方式,例如 (F'(x0)-2)*dx + 2*dx^2, 但是Z微分分析Q我们却很容易了解到TaylorU数的每一U都对应着独立的物理解释,它们构成自然的分l标准。某一量下的所有变化汇dq到一Pq对应一个明的整体描述。在抽象的数理空间中Q我们具有一U无所不达的变化搜集能力。变化项可以从基l构中分d来,l过汇d可以对其q行独立的研I。变化本wƈ不会直接D基础l构的崩溃?br />    在Y件徏模领域,模型的稳定性面临的却是另一番场景。一个Y件模型一旦被实现之后Q种U局部需求变更就都会形成对原有基l构的冲凅R一些局部的需求变化可能造成大片原有实现失效Q我们将被迫为类似的需求重新编写类似的代码。此Ӟ软g开发ƈ不像是一U纯_的信息创造,而是宛若某种物质产品的生产(参见从编写代码到刉代?<a >http://canonical.javaeye.com/blog/333167</a> Q。显Ӟ我们需要一U能力,局部变化从基础l构中剥d来,l过汇dq之后再q行l合分析和处理。这正是AOP(Aspect Oriented Programming)技术的价值所在?br /> <br />     <br /> <div style="border: 1px solid #cccccc; padding: 4px 5px 4px 4px; background-color: #eeeeee; font-size: 13px; width: 98%;"><!--<br /> <br /> Code highlighting produced by Actipro CodeHighlighter (freeware)<br /> http://www.CodeHighlighter.com/<br /> <br /> --><span style="color: #000000;">M1 </span><span style="color: #000000;">=</span><span style="color: #000000;"> (G0</span><span style="color: #000000;">+</span><span style="color: #000000;">dG0)</span><span style="color: #000000;"><</span><span style="color: #000000;">M0</span><span style="color: #000000;">+</span><span style="color: #000000;">dM0</span><span style="color: #000000;">></span><span style="color: #000000;"> </span><span style="color: #000000;">==></span><span style="color: #000000;"> M1 </span><span style="color: #000000;">=</span><span style="color: #000000;"> G0</span><span style="color: #000000;"><</span><span style="color: #000000;">M0</span><span style="color: #000000;">></span><span style="color: #000000;"> </span><span style="color: #000000;">+</span><span style="color: #000000;"> dM</span></div>   AOP本质上是软gl构I间的自׃正机制。只有结合AOP技术之后,软g模型才能够重新恢复抽象的本质Q在旉之河中逃离随机变化的R蚀Q保持实现层面的E_性。在q一背景下,建模的目的将不是Z能够跟踪最l需求的变动Q而是要在某个独立的层面上能够自圆其说Q能够具有某U独立存在的完满性,成ؓ思维上可以把握的某个E_的基炏V模型的真实性将因ؓ自nl构的完备性而得到证明,与外部世界的契合E度不再是h值判断的唯一标准?a >http://canonical.javaeye.com/blog/482620</a><br /> <br /> <img src ="http://www.tkk7.com/canonical/aggbug/304906.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.tkk7.com/canonical/" target="_blank">canonical</a> 2009-12-06 12:23 <a href="http://www.tkk7.com/canonical/archive/2009/12/06/304906.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>l构的自x?/title><link>http://www.tkk7.com/canonical/archive/2009/10/07/297381.html</link><dc:creator>canonical</dc:creator><author>canonical</author><pubDate>Wed, 07 Oct 2009 09:10:00 GMT</pubDate><guid>http://www.tkk7.com/canonical/archive/2009/10/07/297381.html</guid><wfw:comment>http://www.tkk7.com/canonical/comments/297381.html</wfw:comment><comments>http://www.tkk7.com/canonical/archive/2009/10/07/297381.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.tkk7.com/canonical/comments/commentRss/297381.html</wfw:commentRss><trackback:ping>http://www.tkk7.com/canonical/services/trackbacks/297381.html</trackback:ping><description><![CDATA[   说到软g建模Q一个常见的是模型应该符合实际需求,反映问题的本质。但是何谓本质,却是没有先验定义的。在成功的徏立一个模型之前,无论在内涵上q是在外延上我们都很难说清楚一个问题的本质是什么。如果将模型看作是对领域l构的一U显式描q和表达Q我们可以首先考察一下一?#8220;合?#8221;的结构应该具备哪些特征?br />    按照l构M哲学的观点,l构h三个要素Q整体性,h转换规律或法则(转换性)Q自w调整性(自律性)。整体性意味着l构不能被简单的切分Q其构成要素通过内在的关p运实现大范围的关联与转换Q整体之所以成为整体正是以转换/q算的第一性ؓ保证的。这U{换可以是共时的(同时存在的各元素Q,也可以是历时的(历史的{换构造过E)Q这意味着l构总要求一个内在的构造过E,在独立于外部环境的情况下l构h某种自给自的特性,不依赖于外部条g卛_独立的存在ƈ保持内在的活动。自律性意味着l构内在的{换Ll持着某种闭性和守恒性,保新的成分在无限地构成而结构边界却保持E_。注意到q里对结构的评判q不是来自外在规范和U束Q而是Zl构内在的规律性,所的不是结构对外部条g的适应性,而是自n概念体系的完备性。实际上Q一个无法直接对应于当前实际环境的结构仍然可能具有重要的价|q在解决问题的过E中扮演不可或缺的角艌Ӏ在合理性这个视角下Q我们所x的不仅仅是当前的现实世界Q而是所有可能的世界。一?#8220;合理”的结构的价值必能在它所适应的世界中凸现出来?br />    在信息系l中Q我们可能经怼问这个模型是否是对业务的准确描述Q是否可以适应需求的变更Q是否允许未来的各种扩展{等。但是如果换一个思维方向Q我们会发现q些问题都是针对最l确立的模型而发问的Q而在模型构徏的过E中Q那些可被利用的已存在的或者可以存在的模型又是哪些呢。每一个信息模型都对应着某种自动推理机,可以接收信息q做一定的推导l合工作。一个可行的问题是,如何才能更有效的利用已有的信息进行推|如何消除冗余q减各U{换成本。我们经常可以观察到Q某一信息l织方式更充分的发掘了信息之间的内在兌Q一个表象是它对信息的用不是简单的局域化的,而是在多处呈Cؓ互相U缠的方式,难以被分解)Q这U内在关联够丰富,以至于我们不依赖于外部因素就可以独立的理解。这U纠~在一L信息块自然会成ؓ我们建模的对象?br />    如果模型?#8220;覆盖能力”不再是我们关注的重点Q那么徏模的思维囑ּ会发生如下的{?br /> <div align="center"><img src="http://www.tkk7.com/images/blogjava_net/canonical/MicroModel.jpg" alt="" border="0" /></div> <br /> <br /> 最l的模型可以׃pd微模型交l构成。模型的递进构造过Eƈ不同于组?Component)的实物组装接口,也不是CAD囄堆叠式的架构概念所能容U的。在Witrixq_中,模型分解和构造表达ؓ如下形式  <a >http://canonical.javaeye.com/blog/333167</a><br />      Biz[n] = Biz[n+1] aop-extends CodeGenerator<DSLx, DSLy>?br />    在Y件发展的早期Q所有的E序都是Ҏ构造的Q其必然的假设是【在此情况下】,重用不在考虑范围之内Q开发可以说是一个盲目试错的q程。随着我们逐步U篏了一些经验,开始自觉的应用理论分析手段Q【在所有情况下】都成立的一些普适的原理被揭C出来,它们成ؓ我们在广阔的未知世界中跋涉时的向对{当我们的qҎ渐接q领域的边界Q对领域的全貌有一个M的认知之后,一U对自n成熟性的自信很自然的我们导向更加领域特定的分析。很多时候,我们会发C个特化假讑֏以大大提高信息的利用率,推导Z多未被显式设定的知识。我们需要那些【在某些情况下】有效的规则来构成一个完备的模型库。这如同有大量备选的数学定理Q面对不同的物理现象Q我们会从一pd的数学工具中选择一个进行用一栗?br />    <br /> <br /> <br /> <img src ="http://www.tkk7.com/canonical/aggbug/297381.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.tkk7.com/canonical/" target="_blank">canonical</a> 2009-10-07 17:10 <a href="http://www.tkk7.com/canonical/archive/2009/10/07/297381.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>行ؓ聚集http://www.tkk7.com/canonical/archive/2009/07/11/286397.htmlcanonicalcanonicalSat, 11 Jul 2009 13:37:00 GMThttp://www.tkk7.com/canonical/archive/2009/07/11/286397.htmlhttp://www.tkk7.com/canonical/comments/286397.htmlhttp://www.tkk7.com/canonical/archive/2009/07/11/286397.html#Feedback0http://www.tkk7.com/canonical/comments/commentRss/286397.htmlhttp://www.tkk7.com/canonical/services/trackbacks/286397.html   A1 --> B2,  A2 --> B2,  A3 --> B3 ...
我们观察到A1和A2之间, B2和B2之间h某种概念兌? 同时存在某种抽象l构 [A] --> [B].
对于q种情况, 我们可以定义对象 [A], [B], 它们分别?A1和A2的聚? B1和B2的聚合等. 举例来说, 对于如下表格描述, <ui:Col>所提供的信息在映射为html实现的时候将在多处被应用.
<ui:Table data="${data}">
  <ui:Col name="fieldA" label="labelA" width="20" />
  <ui:Col name="fieldB" label="labelB" width="10" /> 
</ui:Table>
q里<ui:Col>提供的信息对应三个部分的内容: 1. 列标?2. 列样?宽度{?  3. 列数?br />
面向对象的常见做法是抽象?UiCol对象, 它作为UiTable对象的属性存? 在生成表? 表列样式和表格数据内Ҏ被使用. 但是我们注意到面向对象要求多个方法通过this指针形成状态耦合

Q在某种意义上它意味着所有的成员Ҏ在Q一时刻都是同时存在着的。它们所代表着的存在的代h必须被接受(存储I间{)。即使ƈ不同时被使用Q我们仍焉要同时持有所有成员函数指针及

׃n的this指针。实际上, 我们q不一定需要A1和A2同时在场. 在这U情况下, ~译期技术可以提供另一U不同的行ؓ聚合方式.


<table>
  <thead>
    <sys:CompileTagBody cp:part="thead" />
  </thead>
  <cols>
    <sys:CompileTagBody cp:part="cols" />
  </cols>
  <tbody>
    <sys:CompileTagBody cp:part="tbody" />
  </tbody>
</table>

只要<ui:Col>标签的实C针对~译期的cp:part变量q行分别处理, 卛_实现信息的部分析?




canonical 2009-07-11 21:37 发表评论
]]>
信道构徏http://www.tkk7.com/canonical/archive/2009/03/22/261352.htmlcanonicalcanonicalSun, 22 Mar 2009 13:10:00 GMThttp://www.tkk7.com/canonical/archive/2009/03/22/261352.htmlhttp://www.tkk7.com/canonical/comments/261352.htmlhttp://www.tkk7.com/canonical/archive/2009/03/22/261352.html#Feedback0http://www.tkk7.com/canonical/comments/commentRss/261352.htmlhttp://www.tkk7.com/canonical/services/trackbacks/261352.html

    在系l规划中Q多层结构应该内|与具体语义无关的通用信道Q它跨越多个层次Q允怿息透明的通过Qƈ以未预期的方式在不同的层面激发各U相关的行ؓ。在Witrixq_中,q_代码与特定应用中的业务代码处于高度交l的状态,一个特定业务功能的实现往往需要多处业务代码相互协同,q_必须成ؓ某种透明的背景。例如,假设我们~制了一个通用的列表选择控g,它封装的逻辑是从一个实体列表中q行选择
      <app:SelectOne objectName="MyEntity" />
如果现在要求选择时只列出某个cd的实体,则调用Ş式ؓ
      <app:SelectOne objectName="MyEntity" extArgs="$bizId=select&amp;$type=1" />
在调用入口处补充必要的信息之后会推动pȝ在遥q的状态空间中应用一个特定的qo条g。这?bizId负责指示q_应用特定的元数据配置Q而其他的参数则由元数据中的逻辑负责处理。^C特定业务代码各取所需Q相互配合,尽可能多的逻辑剥离为通用机制?br />




canonical 2009-03-22 21:10 发表评论
]]>
同构与同态:认识同一?/title><link>http://www.tkk7.com/canonical/archive/2009/02/28/257150.html</link><dc:creator>canonical</dc:creator><author>canonical</author><pubDate>Sat, 28 Feb 2009 08:57:00 GMT</pubDate><guid>http://www.tkk7.com/canonical/archive/2009/02/28/257150.html</guid><wfw:comment>http://www.tkk7.com/canonical/comments/257150.html</wfw:comment><comments>http://www.tkk7.com/canonical/archive/2009/02/28/257150.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.tkk7.com/canonical/comments/commentRss/257150.html</wfw:commentRss><trackback:ping>http://www.tkk7.com/canonical/services/trackbacks/257150.html</trackback:ping><description><![CDATA[   C数学是徏立在{hc这一概念的基之上的。同构是对等价关pȝ一U刻划。简单的可以把它理解Z个系l之间的一U?#8220;保持”q算规则的一一对应关系。在 数学中一个符h代表的是所有能够互相同构的对象。例如整?可以看作是与某个元素个数?的集合可以徏立一一对应关系的所有的集合所构成的整体。所以在 数学中,如果我们解决某个特定的问题,它同时也意味着我们解决了一pd怺{h的问题?br />     同构关系对于认知可以起到本质上的化作用。如果通过一个推理链条,认了A == B == C == DQ则可以直接从概念上推导?A == D, q一关系有可能被直观理解Q而不需要理会中间的推理步骤。(注意C上元素两两徏立同构关pȝ时候可能要采用不同的对应手D,因此上面的等式ƈ不是q_ 的。)另一斚wQ我们可以确定一个模型元素M,  系l简化ؓ A == M, B == M, C == M, D == M。只要理解了元素Mq解了{h的其他元素? <p>    Witrixq_中PDM定义作ؓ基础的结构模型,它同时映成为数据库表,以及hbm, java, meta{多个代码文Ӟ此外q对应于U定的WebObject名称和BizFlow文g名称Q相应的报表文g目录{。我们只要理解了pdm模型Q即可? q推理自然的掌握各个层面上对应的l构。这意味着只要知道实体名称Q就知道如何通过Web讉Kq个对象Q知道数据在数据库中对应的数据库表,而不需要知? 后台是如何读取前台提交的参数以及如何执行保存数据指o的。不仅仅是在模型驱动领域Q在pȝ设计的各个方面,我们都应该尽量充分的利用当前的信息通过推理 得到pȝ其他部分的结构,而不是通过手工兌或者判断在E序中动态维持这U对应关pR例如在flow-cp机制中,biz的id, action的id{都Ҏstep配置的id推导得到Q这样在工作列表跌{的时候就可以Ҏ规则推导转页面对应的链接Q而不需要手工编写页面重定向 代码?/p> <p style="text-align: center;"><br /> <img src="http://www.tkk7.com/images/blogjava_net/canonical/mapping.jpg" alt="" border="0" height="262" width="262" /><br /> </p> <p><br />  <br />     同态(homomorphismQ关pȝ对于同构关系Q只单向映射的可行性,它是一个舍弃属性的q程。同态作为最基础的认知手D之一Q它不仅仅是用一 个符h|换一l元素,而是同时保留了某U全局的运关p,因此同态映像可以构成某U独立的完整的研I对象。通过同态映,我们可以在不同的抽象层面上研 I原pȝ的一个简化版本。例如meta中的layout是一U典型的领域特定语言(DSL)?br />     userName userTitle<br />     emailAddress<br /> <br /> 每一个字D表CZ一个可能Q意复杂的inputor或者viewer, 字段之间的前后关pLqC最l显C页面上昄内容的相对关pR当viewerҎ需求发生改变的时候,q不影响到layout层面上的关系Q因? layout可以保持不变。如果我们在pȝ中把问题分解为多个抽象层面上Q多个观察视角上的同态模型,则可能实现更高的软g复用E度?br />     在Witrixq_的设计中Q很多细_度的标{N定义为tpl文本D,q样q_只要理解某一层面上的交互关系Q实际应用中可能出现的细节在标签内部q行局 部处理,不会H破原始设计的Ş式边界,不会影响到原先设定的Mpȝl构。例如BizFlow中的tplsD,action的sourceD늭?br />     上世U?0q代以前Q生物学家做梦也惌不到h无限复杂性的生物遗传q程Q竟然可以被抽象为ATGC四个抽象W号的串联。生命竟然不理会各种已知的或? 未知的物理化学作用,被抽象的三联码所驱动。一U抽象的本质g成了生命世界的本原。在软g的世界中Q可以被识别的抽象元素绝不只是语a本n所提供的那? 机制?/p> <img src ="http://www.tkk7.com/canonical/aggbug/257150.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.tkk7.com/canonical/" target="_blank">canonical</a> 2009-02-28 16:57 <a href="http://www.tkk7.com/canonical/archive/2009/02/28/257150.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>cd化:形而上学的信Ԓhttp://www.tkk7.com/canonical/archive/2009/02/21/255974.htmlcanonicalcanonicalSat, 21 Feb 2009 11:43:00 GMThttp://www.tkk7.com/canonical/archive/2009/02/21/255974.htmlhttp://www.tkk7.com/canonical/comments/255974.htmlhttp://www.tkk7.com/canonical/archive/2009/02/21/255974.html#Feedback2http://www.tkk7.com/canonical/comments/commentRss/255974.htmlhttp://www.tkk7.com/canonical/services/trackbacks/255974.html       中国人的传统哲学认ؓ世界是普遍联pȝQ事物之间存在着福怾的辩证{化关pR而古希腊人强调个体意识,以两分法看待世界Q他们将世界看成是孤立的物体l成Q原子论Q构成,然后选择一个孤立物体(q背景Q,开始研I它的各属性,接着属性泛化,构成分类的基。西方语a中大量抽象概念都是从作ؓ属性的形容词直接{化而来Q例? white --> whiteness 。而中文中很少有精的cd定义Q而多半是富有表现力的Q隐L的词语Q例如我们不谈论抽象的白Q而只说雪白,没有抽象? size Q而只说具体的大小?

       亚里士多徯为铁球在I气中下落是因ؓ它具?#8220;重?#8221;Q而木块在水中漂Q是因为木块具?#8220;L?#8221;。这U将一切原因归lؓ事物内在属性的传统在一定程度上妨碍了西方h认识到背景的存在和作用,但得他们可以把问题化?

       古希腊h对于cd的热h于他们对于永恒的qh。静态的亘古不变的世界才是他们的思想栖息的场所。具体的物体是易逝的Q多变的Q只有抽象的cd才是永恒的存在,也只有抽象概念之间的关系才是永真的联pR而具体实例之间的兌在某U程度上被认为是不重要的Q甚x不可靠的?



       具有某一属性的所有物体定义ؓ一个集合,q一做法在上世纪初被发现会引起逻辑悖论Q动摇了整个数学的基Q它l不像表面上看v来那么单U。但定无疑的是Q通过cd来把握不变的事实是一U非帔R要且有效的认识策略。面向对象语a名词? 念,从引入类定义以及cM间的l承关系开始,q符合西方一贯的作风。? Ruby q种实例间关pȝ动态语a首先由日本h发明Q可能也不是偶然的。虽然现在大安在玩高科技了,可实际贩卖给你的多半仍然是包ȝ病的传U方。文化可能造成认知上的一U偏执,在技术领域这一现象q没有被清楚的意识到?

 



canonical 2009-02-21 19:43 发表评论
]]>
从编写代码到刉代?/title><link>http://www.tkk7.com/canonical/archive/2009/02/15/254784.html</link><dc:creator>canonical</dc:creator><author>canonical</author><pubDate>Sun, 15 Feb 2009 10:21:00 GMT</pubDate><guid>http://www.tkk7.com/canonical/archive/2009/02/15/254784.html</guid><wfw:comment>http://www.tkk7.com/canonical/comments/254784.html</wfw:comment><comments>http://www.tkk7.com/canonical/archive/2009/02/15/254784.html#Feedback</comments><slash:comments>2</slash:comments><wfw:commentRss>http://www.tkk7.com/canonical/comments/commentRss/254784.html</wfw:commentRss><trackback:ping>http://www.tkk7.com/canonical/services/trackbacks/254784.html</trackback:ping><description><![CDATA[<p>    软g开发作ZU工E技术,它所研究的一个重点就是如何才能有效降低Y件品的研发成本。在q一方向上,lg技术取得了I前的成功。它所提供的基本图景是 像搭U木一样从无到有的l装出最l的产品。在某种意义上,q是对现代徏{工业的模仿和致敬。新材料Q预制gQ框架结构,q些建筑学的q展在Y仉域被一一 复制Q徏{工C的民工自然也成ؓ了程序员们学习的h。毕竟,在组件的世界中码代码Q基本上也是一U?#8220;搬砖”的行为?/p> <p>     值得庆幸的是QY件开发作ZU智力活动,它天生具有一U?#8220;L工化”的們֐。信息品有着与物质世界品完全不同的抽象本质。在物理I间中,建?00 栋房屋,必须付出100倍的努力Q老老实实的q上100遍。而在概念I间中徏?00栋房屋,我们却可以说其他房屋与第一栋一模一P加点q移旋{变换? 可。一块砖填了地基׃能用来盖屋顶Q而一D写好的代码却可以在M可用的场合无损耗的被用。一栋徏好的房屋发现水管漏水要大动干戈,而在完成的Y件中 补个局部bug却是菜一。在抽象的世界中有效的进行生产,所依赖的不应该是大q?苦干的堆砌,而应该是发现某种可用于推导的原理Q基于这些原理,输入 信息可以立刻转换为最l的l果Q而不需要一个逐步构造的q程。即我们有可能超组装性生产,实现某种cM于数学的原理性生产?a mce_href="/blog/325051">http://canonical.javaeye.com/blog/325051</a><br /> </p> <p>    代码复用是目前Y件业中鼓吚w低生产成本的主要口号之一。但是在lg技术的指向下,一般所复用的只是用于构建的砖块Q而ƈ不是某种构造原理。即使在所有信 息已l确定的情况下,我们仍然不可能从需求立d到可执行的品。很多代码即使我们在惌中已l历历在目,却仍焉要一行行把它们誊写下来。当我们发现p? l中已经没有Mlg值得抽象的时候,仍然留下来众多的工作需要机械化的执行。代码复用的理想国距L们仍焉常的遥远?/p> <p>     子例E?subroutine)是最早的代码重用机制。这像是将昨天已经完成的工作录制下来,在需要的时候重新播放。函?function)相对于子 例程更加强大。很多代码看hq不一P但是如果把其中的差异部分看作是变量,那么它们的结构就可以l一了。再加上一些判断和循环Q很多面目E异的东西? 实是存在着大量׃n信息的。面向对象技术是一ơ飞跃性的发展。众多相关信息被打包C个名UͼcdQ中Q复用的_度和复杂度都大大提升。派生类从基cȝ 承,可以通过重蝲实现对原有代码的l致调整。不q,q种方式仍然无法满日益增长的复用需求。很多时候,一个名Uƈ不以标定我们最l需要的代码l构Q在 实际使用的时候还需要补充更多的信息。类型参数化Q即泛型技术,从事后的角度看其实是一U明昄解决Ҏ。根据参数动态的生成基类自然可以吸纳更多的变 化。经历了所谓Modern C++的发展之后,我们现在已经非常明确Q泛型ƈ非仅仅能够实现类型共变,而是可以从类型参C引入更丰富的l构信息Q它的本质是一U代码生成的q程?a mce_href="/blog/57244">http://canonical.javaeye.com/blog/57244</a> 认清了这一点,它的扩展非常明显了<br /> </p> <div style="border: 1px solid #cccccc; padding: 4px 5px 4px 4px; background-color: #eeeeee; font-size: 13px; width: 98%;"><!--<br /> <br /> Code highlighting produced by Actipro CodeHighlighter (freeware)<br /> http://www.CodeHighlighter.com/<br /> <br /> --><span style="color: #000000;">   BaseClass</span><span style="color: #000000;"><</span><span style="color: #000000;">ArgClass</span><span style="color: #000000;">></span><span style="color: #000000;"> </span><span style="color: #000000;">--></span><span style="color: #000000;"> CodeGenerator</span><span style="color: #000000;"><</span><span style="color: #000000;">DSL</span><span style="color: #000000;">></span></div> <p>DSLQ或者某U模型对象)相对于普通的cd(Class)Q信息密度要大很多,它可以提供更丰富也更完整的输入信息。而CodeGenerator也不必拘泥于基础语言本n提供的各U编译机Ӟ而是可以灉|应用各种文本生成技术?a mce_href="/blog/309395">http://canonical.javaeye.com/blog/309395</a> CodeGenerator在这里所提供的正是根据输入模型推导出完整实现代码的构造原理?/p> <p>     现在很多人热衷于开发自q易代码生成工Pq些工具也许可以在简单的情Ş下减M些体力工作,但是生成的代码一般不能直接满需求,仍然需要手工执? 大量的删改工作。当代码生成之后Q它成ؓ一U固化的物质产品Q不再能够随着代码生成工具的改q而同步改q,在长期的pȝ演化q程中,q些工具q不一定能? 减少累积的工作量?br /> </p> <div style="border: 1px solid #cccccc; padding: 4px 5px 4px 4px; background-color: #eeeeee; font-size: 13px; width: 98%;"><!--<br /> <br /> Code highlighting produced by Actipro CodeHighlighter (freeware)<br /> http://www.CodeHighlighter.com/<br /> <br /> --><span style="color: #000000;">   修正q程  </span><span style="color: #000000;">==></span><span style="color: #000000;"> CodeGenerator</span><span style="color: #000000;"><</span><span style="color: #000000;">DSL</span><span style="color: #000000;">></span></div> <p>Z改进以上代码生q程Q一些h试图在CodeGenerator中引入越来越多的可配|性,各U变化的可能内置在构造原理中。显然这会造成CodeGenerator的不正常的肿胀。当更多的偶然性被包含在原理中的时候,必然会破坏原理的单性和普适性?<br /> </p> <div style="border: 1px solid #cccccc; padding: 4px 5px 4px 4px; background-color: #eeeeee; font-size: 13px; width: 98%;"><!--<br /> <br /> Code highlighting produced by Actipro CodeHighlighter (freeware)<br /> http://www.CodeHighlighter.com/<br /> <br /> --><span style="color: #000000;">   输入信息 </span><span style="color: #000000;">+</span><span style="color: #000000;"> 一D는于推导的原理 </span><span style="color: #000000;">+</span><span style="color: #000000;"> 修正补充 </span><span style="color: #000000;">=</span><span style="color: #000000;"> 真实模型</span></div> <p>必须存在[修正补充]q一Ҏ能维持以上方E的持久q?/p> <p>     Z摆脱人工修正q程Q将模型调整U_到概念世界中Q我们需要超承机制的Q更加强大的Q新的技术手Dc其实在当前的技术背景下Q这一技术已l是gƲ出了。这是AOP, Aspect Oriented Programming?a mce_href="/blog/34941">http://canonical.javaeye.com/blog/34941</a> <br /> </p> <div style="border: 1px solid #cccccc; padding: 4px 5px 4px 4px; background-color: #eeeeee; font-size: 13px; width: 98%;"><!--<br /> <br /> Code highlighting produced by Actipro CodeHighlighter (freeware)<br /> http://www.CodeHighlighter.com/<br /> <br /> --><span style="color: #000000;">      Biz </span><span style="color: #000000;">==</span><span style="color: #000000;">[AOP </span><span style="color: #0000ff;">extends</span><span style="color: #000000;">]</span><span style="color: #000000;">==></span><span style="color: #000000;"> CodeGenerator</span><span style="color: #000000;"><</span><span style="color: #000000;">DSL</span><span style="color: #000000;">></span><span style="color: #000000;"> <br /> </span></div> <p>l承仅仅能够实现同名Ҏ之间的简单覆盖,而AOP所代表的技术原理却是在代码l构I间中进行Q意复杂的删改操作,它潜在的能力{h于h工调整?/p> <p>     Z实现上述生模式Q需要对~程语言Q组件模型,框架设计{方面进行一pd攚w。目前通用的AOP实现和元~程技术其实ƈ不以支持以上模式?a mce_href="/blog/275015">http://canonical.javaeye.com/blog/275015</a> <br />     q一生模式会如何演化Q也是一个有的问题。按照列理论,我们立刻可以得到如下发展方向Q?/p> <div style="border: 1px solid #cccccc; padding: 4px 5px 4px 4px; background-color: #eeeeee; font-size: 13px; width: 98%;"><!--<br /> <br /> Code highlighting produced by Actipro CodeHighlighter (freeware)<br /> http://www.CodeHighlighter.com/<br /> <br /> --><span style="color: #000000;">    Context0 </span><span style="color: #000000;">+</span><span style="color: #000000;"> DSL1 </span><span style="color: #000000;">+</span><span style="color: #000000;"> EXT0 </span><span style="color: #000000;">=</span><span style="color: #000000;"> DSL0  <br />     Context1 </span><span style="color: #000000;">+</span><span style="color: #000000;"> DSL2 </span><span style="color: #000000;">+</span><span style="color: #000000;"> EXT1 </span><span style="color: #000000;">=</span><span style="color: #000000;"> DSL1  <br />     <img src="http://www.tkk7.com/Images/dot.gif" alt="" /> <br /> </span></div> <p><a mce_href="/blog/33824"> http://canonical.javaeye.com/blog/33824</a></p> <p>Witrixq_中BizFlow可以看作是对DaoWebAction的修正模型,但是它本w具有完整的意义Q可以直观的被理解。在BizFlow的基上可以逐步建立SeqFlowQStateFlow{模型?a mce_href="/blog/126467">http://canonical.javaeye.com/blog/126467</a></p> <p>      现在有些图深挖函数式语言Q利用模式匹配之cȝ概念Q做W号I间的全局优化。但是我们需要认识到通用的机制是很少的,能够在通用语言背景下被明确提出 的问题更是很的。只有在特定领域中,在掌握更多局部信息的情况下,我们才能提出丰富的问题,q作Z定背景下的解{。DSL的世界中待做的和可做的工? 很多?a mce_href="/blog/147065">http://canonical.javaeye.com/blog/147065</a> <br /> </p> <p>      对于E序员而言Q未来将变得来丰富而复杂,它将持箋拷问我们的洞察力。我们不是一行行的编写代码,把需求一条条的翻译到某种实现上,而是不断发明局部的生原理Q依靠自己制定的规则在抽象的I间中不断的创造新的表象?br /> </p> <img src ="http://www.tkk7.com/canonical/aggbug/254784.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.tkk7.com/canonical/" target="_blank">canonical</a> 2009-02-15 18:21 <a href="http://www.tkk7.com/canonical/archive/2009/02/15/254784.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>逆元Q不存在的真实存?http://www.tkk7.com/canonical/archive/2009/02/07/253744.htmlcanonicalcanonicalSat, 07 Feb 2009 14:22:00 GMThttp://www.tkk7.com/canonical/archive/2009/02/07/253744.htmlhttp://www.tkk7.com/canonical/comments/253744.htmlhttp://www.tkk7.com/canonical/archive/2009/02/07/253744.html#Feedback1http://www.tkk7.com/canonical/comments/commentRss/253744.htmlhttp://www.tkk7.com/canonical/services/trackbacks/253744.html

       负数没有直接的几何意义,因此它被认ؓ是对应于不存在的事物。而按照古希腊的逻辑Q不存在的事物是不可能存在的Q因而也是无法被理解的Q更不可能参与到 推理q程中,因此是无意义的,无法被定义的Q? 因此它是不存在的。中国h注重的是q算的合理性,而不是数的真理性,大概在公元前400q左叛_创造了负数和零的概c而在西方直到公元7世纪Q唐代)? 一本印度h的著作中才出现负敎ͼ它被用来表示负债。西方h没有能够创造负敎ͼ他们对负数的接受更迟?5世纪左右。这件事实在一定程度上说明了存在某U深 ȝ困难ȝ我们理解负数概念?br />        在引入负C前,3x^2 + 8 = 4x ?nbsp; 3x^2 + 4x + 8 = 0 q两个方E的l构是完全不同的Q它们需要不同的求解技术,因此也就不可能利用符h象出 a x^2 + b x + c = 0。引入负数才使得我们能够以统一的方式提出问题,q研I用的求解技术?br />       论(Group Theory)是对l构q行抽象研究的数学分支。群的定义包括四条规?br /> 1.    元素之间的运满结合律 (a * b) * c = a * (b * c)
2.    元素之间的运封闭,?a * b 仍然属于该群
3.    存在单位元,卛_所有a, a * e = e*a = a
4.    每个元素存在对应的逆元Qa * a^-1= e
      逆运是非常重要的结构要求,逆元是对负数的一U抽象推qѝ如果没有逆元Q则只能构成半群(semi-group)Q它的性质要少很多?/p>


      目前软g设计中所有的原则都指向组装过E,从无到有Q层层篏q。构件组装的隐喻中所包含的图像是操纵实际可见的积木,是缺逆元概念的?/p>

      考察一个简单的例子Q假N要的产品是三角Ş内部挖去一个五边Ş的剩余部分。有三种生{略Q?br /> 1.    Ҏl需要的产品形态进行三角剖分,使用8个小三角形拼接出来。这U方式比较繁琐,而且最后粘接工序的可靠性和_性值得怀疑?br /> 2.    拿到一个真实的三角形,然后用刀在内部挖Z个五边Ş的洞。这U方式需要消耗一定的人工Q而且也很难保证五边Ş的精性,即我们曄_的生产过其他五角形和三角形。实际上一般情况下我们是逐步锉出一个五边Ş的,q没有充分利用到五边形的对称性?br /> 3.    在概늩间中做一个抽象计?nbsp; (-五边? + (三角? = 所需产品
如果我们能够生一U负的五边Ş和一U正的三角ŞQ则可以立刻得到最l的产品?br />



 
在Y件开发的实践中,我们目前多数采用的是两种方式Q?br /> 1.    采用可视化设计工具通过拖拽操作开发出完整的界面和后台
2.    拯一些已有的代码Q删除掉不需要的部分Q增加一些新的实玎ͼ也可能对已有实现做一些不兼容的修正?br />
在第二种方式?br />            新结构的构?= 已有l构 + 软g之外的由人执行的一个剪裁过E?br /> q个剪裁q程表现Z个时间序列。如果我们对原有l构q行了调_则需要重新关联一个时间序列,而此旉序列q不会自动重播。ؓ了压~以旉为度量单位的 生成本Q我们必d对旉序列的依赖。在旉序列中展开的一个构造过E可以被转化Z个高l设计空间中的一U更加丰富的构造原理,我们最l的观测可以 看作是设计空间向物理I间的一个投影(惌一束光打下来)。这U方式更Ҏ保证E序的正性?br />           旉序列 --[原理转化]--> I间关系


    q样我们可以用第三种生{略Q利用构造原理进行抽象计。如果我们只盯着产品的最lŞ态看Q只是想着怎么把它像搭U木一h建出来,׃可能识别? pȝl构本n所蕴含的对U性。如果我们发Cpȝ内蕴的结构特征,但是却只能通过构造过E中的行动序列来q随它,同样无法实现有效的工作复用。同时因 个行动序列一般处于系l规则约束之外,完全׃h的自觉来保障Q因此很难保证它的正性。现实世界的规范要求q不是模型本w所必须满的,只要我们能够创? 新的l构原理Q在概念I间中我们就可以拥有更多的自由。现在业内鼓吹的软g构造原理多半是参照物理世界中生产具体物质品的生工序Q却没有真正把握信息的抽象本质。掌握规则,制订规则Q才是信息空间中的游戏规则?br />
    物理学中最重要的分析学思想之一是微扰论(Perturbation). 针对一个复杂的物理现象Q首先徏立一个全局的规范的模型Q然后考虑各种微扰条g对原有模型的影响。在扰动情况下Q模型的变化部分往往可以被线性化Q被局 域化Q因而问题得到简化。微扰分析得到的解依赖于全局模型的解而存在,因而这是一U主从关pȝ分解方式。但是如果主体模型是我们已经熟知的物理现象,则我 们关注的重点可以全部攑֜扰动解上Q认为所有特定的物理规律都体现在扰动解中。如果微扰分析得到的物理元素_丰富Q则微扰模型本n可以成ؓ独立的研I对 象,在其中我们同样可以发现某U普适的l构规律?br />     考察如下的构造过E?br />        X = a + b + c
       Y = a + b + d = (a + b + c) - c + d = X - c + d
    对于数学而言Q上q的推导是等LQ但是对于物理学而言QY = a + b + d ?nbsp; Y = X - c + d是有着本质不同的。第一U方式要求打破原先X的构造,而重新的l装其实是有成本的,特别是在X本n非常复杂的情况下。典型的Q如果X是经q测试的功能Q? 重新l装后原先由试保障的概念边界被打破?br />          我们可以从Y = X + dX抽象出扰动模?nbsp; dX = - c + d
M分解模式自然的导出逆元概念?br />
      如果没有逆元Q我们必焉要分解。但是如果发掘了背景q一概念Q在逆元q算下,对背景不是分解让其成为可见的部分Q而是采用q加的,增删的方法对背景l构 q行修正Q则我们有可能在没有完整背景知识的情况下Q独立的理解局部变化的l构。即背景是透明的,知识成ؓ局部的。在Witrixq_中,BizFlow + DaoWebAction + StdPage 才构成完整的E序模型QBizFlow其实是对标准模型的差异描qͼ但是它可以被单独的理解。如果我们从接触E序开始就接受BizFlow, 可能完全不需要了解数据库讉K和前台界面渲染的知识。我们ƈ不是通过在DaoWebAction中设定各U可预见的调用Ş式,而是在BizFlow中? q类似AOP的操作方式直接对标准模型q行修正。这U修正中一个很重要的部分就是删除标准模型中~省提供的功能?br />      WebMVC之前世今?http://canonical.javaeye.com/blog/163196
     Witrix架构分析 http://canonical.javaeye.com/blog/126467


      变化的部分构成独立于原始模型的新的模型,它的l构关系是完备的Q可以独立的理解。在原始模型崩溃的情况下Q它仍然可能保持有效性?br />       从物理学的角度看Q我们所观测到的一切物理现象,都是某种物理作用的结果,也就是物质结构相对于背景状况的一U偏R我们只可能观测到变化的部分Q因此我们对世界的认识其实只是世界的扰动模型而已Q世界的本体不属于科学研I的范畴?/p>

canonical 2009-02-07 22:22 发表评论
]]>
文本?/title><link>http://www.tkk7.com/canonical/archive/2009/01/04/249666.html</link><dc:creator>canonical</dc:creator><author>canonical</author><pubDate>Sat, 03 Jan 2009 16:55:00 GMT</pubDate><guid>http://www.tkk7.com/canonical/archive/2009/01/04/249666.html</guid><wfw:comment>http://www.tkk7.com/canonical/comments/249666.html</wfw:comment><comments>http://www.tkk7.com/canonical/archive/2009/01/04/249666.html#Feedback</comments><slash:comments>1</slash:comments><wfw:commentRss>http://www.tkk7.com/canonical/comments/commentRss/249666.html</wfw:commentRss><trackback:ping>http://www.tkk7.com/canonical/services/trackbacks/249666.html</trackback:ping><description><![CDATA[<div id="1616611" class="blog_content"> <p>    软g技术的发展是一个结构化不断加深的过E,我们逐渐拥有了越来越丰富的结构识? 表达和处理手Dc在q一方向? lg技术最l取得了巨大的商业成功。但是区分同时也意味着隔阂。面向对象技术最基础的概念在?O = C(O), 对象的复?Composition)仍然是对?  然而在来复杂的软g生态环境中,q一图景实现的可能性被大大的压~? 面对层层装造成的Ş态各异的表达方式, 不同来源, 不同目标, 不同q行环境下的信息的交互变得越来越困难。我们逐渐丧失了概念上的简z? 也׃数学世界中的那种IK一切的l一的力? 所谓SOAQSerivce Oriented Architecture)技术试N过补充更多的环境信息,攑ּ状态关联,暴露元知识等方式来突破现有的困境?<a >http://canonical.javaeye.com/blog/33803 </a> q其中一关键的技术抉择是Z文本格式q行信息表达?/p> <p>      在过?0q中Web技术取得了I前的成功,它造就了互联网q一世界上最大的分布式集成应用。SOA从某U程度上说是对这一事实在技术层面上的反思。基? 文本传递的web技术所表现出来的开放性,可理解性和可观性,与封闭的Q难以直接解ȝQ必L有大量相关知识才能正操作的二进制结构相比,q本w就 是革命性的创新。不需要特D的工具可以非常轻易的察看到网늨序的输入输出Q所有交互过E都处在完全透明的检查下Q各U不曾事先规划的文本处理手段都可 以参与到web创徏的过E中。随着速度Q存储不再是我们考虑的首要问题,文本化作ZU技术趋劉K渐变得明确h。但是Q何一U技术思想的成功或p|都不 可能是因为某U单一的原因所造成的,因此有必要对文本化的技术h值做更加l致的剖析?br />    <br />    1. 文本化是一定程度上的去l构化,但是通过q种方式我们获得了对E序l构的更强的控制力。无论我们所兛_的文本片断层层嵌套在大段文本的哪个部分,我们都可 以通过text.indexOf(subStr)来实现定位,通过text.replace(oldStr,newStr)实现变换。而在lgpȝ中,? 们只有通过某种预定的遍历方式逐步递归才有可能讉K到组件内部的l成对象。如果某个组件不按照规范实现或者规范中~少明确的设定,则这一信息兌链条会 断裂。在一些组件系l中Q甚x有规定一U统一的遍历方式,则我们根本无法定义出通用的大范围的结构定?变换手段。即使是在设计精良的lg框架中,受限 制于lg的封装性要求,我们也不可能讉K到全部的信息。当我们以组件设计者意料之外的方式使用q些lg的时候,׃遇到重重障碍。即使所需的只是微的局 部调_因ؓ无法触及到需要修改的部分Q我们也可能被迫攑ּ整个lg?br />    <br />    2. 文本是普适的信道。各U操作系l,各种E序语言所h的最基本的能力就是文本处理能力,对于文本格式的约定是最Ҏ达成p的。虽然对于机器而言Q理解基 于地址定位的二q制数字可能更加直接Q但是所有的应用E序都是׃h来负责编Ӟ调试Q部|Ԍl护的,如果人可以不借助Ҏ的工具就可以明确了解到系l内? 生的q程Q则pȝ的构建和l护成本׃大幅下降?br />    <br />    3. 文本表述形式上的冗余性增Zpȝ的概늨定性和局部可理解性。在二进制格式中Q经常出现的是根据相对地址定位Q这要求我们完整理解整个二进制结构,才能 够逐步定位到局部数据块。同Ӟ二进制格式中也经怋用一些外部的信息Q例如某个位|处的数据ؓ整型Q占用四个字节等。这L信息可能只能在文说明里? 刎ͼ而在数据体中没有M的体玎ͼq限制了独立的理解可能性。与此相反,文本格式l常是自说明式的Q例如width:3.5px, q提高了pȝ的可理解性,特别是局部可理解性。即使我们对pȝ只具有很的知识Q一般也能根据数据周围的相关信息q行局部操作。一般很Ҏp够定位到? D的局部数据区Q安全的跌众多未知的或者不被关心的l构. 一个程序新手也可以在很短时间内靠着q蒙带猜, 实现xml格式的word文g中的书签替换功能,而要搞清楚word的二q制格式,q独立编制出正确的替换功?昄׃是一两周的工作量可以解决的了. q其? 可理解性的差异是存在着数量U上的`沟的.<br />    <br />    4. xmlq种半结构化的文本格式规范的兴v, 以通用的方式ؓ文本描述引入了基本的形式U束, 实现了结构表辄均一? C语言中的?Macro)本质上就是一U文本替换技?它的威力在于没有预定义的语义, 因此可以越其他语法成分, 破除现有语法无法跨越的限? 但是它的危险性在于缺乏与其能力相适应的Ş式约? 难以控制. 而在xml格式规范? 不同语义, 不同抽象层面的节点可以共存在同一个Ş式体pM, 可以用通用的方式进行定?校验, 转换{? Witrixq_在动态xml斚w发展了一pd技? 为文本处理引入了更多应用相关的规? 增强了文本描q的抽象能力和表达能?  <br />    <br />    5. 文本作ؓ描述(description)而不是执行指?execution). C语言的源代码与机器码基本上是一一对应? x代码本n所表达的就是指令的执行q程. 而在Web应用领域, HTML语言仅仅是声明界面上需要展C? 但是如何d现是由通用的解析引擎负?它ƈ不是我们x的重? 描述需要结合诠?解释)才能够生实际的q行效果, 才能对现实的物理世界产生影响.q在某种E度上实际上是gq了执行q程. 一U描q可以对应多U诠? 例如同样的元数据在前台可以用来生成界?在后台可以用于生成数据库, q行数据有效性校验等. 在特定的应用领域?执行引擎可以是通用? 可以独立于描q本w不断演? 因此一U领域特定的描述,它所承蝲的内容ƈ不是固化? 而是可以随着执行引擎的升U不断增强的. 例如, 在Witrixq_? FlowDSL本n所做出的流E描q是E_? 但是随着程引擎不断改进,不断引入新的功能,所有用DSL的已实现的应用都同步得到升. <a >http://canonical.javaeye.com/blog/275015</a> <br />    <br />    6. Text = Process(Text) q个不动点在Unixpȝ中得C充分的应? 多个程序通过道(Pipe)l合在一? 可以完成相当复杂的功? 一个更加丰富的处理模型?XML = Process(XML). 文本描述很自然的支持多趟处理, 它得我们可以充分利用全局知识(后箋的处理过E可以用前ơ处理过E收集的全局信息), 可以同时支持多个抽象层面(例如DSL的不断动态展开). Witrixq_中的~译期运行技术实际上对应于如下单规? ~译期运行生文本输? 对输出文本再ơ进行编? 通过q一递归模式, 可以单的实现动态解析与静态描qC间的q. 模板(Template)技术是h关键性作用的文本生成技? out.write("<div>");out.write(value);out.write("</div>");q种 API拼接方式昄不如<div>${value}</div>q种模板生成方式直观且易于? 在Witrixq_的tpl模板语言? xml的规范性得在多趟~译q程中我们一直可以维持某UŞ式约? <br />    <br />    7. 不是所有的情况下都应该使用文本. 普元EOS中所鼓吹的XMLȝ之类的技术是我所极力反对? <a >http://canonical.javaeye.com/blog/33794</a> </p> </div> <img src ="http://www.tkk7.com/canonical/aggbug/249666.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.tkk7.com/canonical/" target="_blank">canonical</a> 2009-01-04 00:55 <a href="http://www.tkk7.com/canonical/archive/2009/01/04/249666.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>关于代码生成和DSLhttp://www.tkk7.com/canonical/archive/2008/11/23/242084.htmlcanonicalcanonicalSun, 23 Nov 2008 03:57:00 GMThttp://www.tkk7.com/canonical/archive/2008/11/23/242084.htmlhttp://www.tkk7.com/canonical/comments/242084.htmlhttp://www.tkk7.com/canonical/archive/2008/11/23/242084.html#Feedback0http://www.tkk7.com/canonical/comments/commentRss/242084.htmlhttp://www.tkk7.com/canonical/services/trackbacks/242084.html
   在应用开发中Q有些领域是非常适合于用代码生成技术的。例如根据领域模型生成ORM(对象-关系映射)描述Q或者根据接口描q生成远E调用代?存根 (Proxy/Stub){。因为它们实际上只是对同一信息的不同技术Ş式或者不同技术层面的同义反复而已。这U生成最理想的方式是动态进行,可以随时保持模型的有效性。RoR(RubyOnRails)框架中ActiveRecord技术便是一个成功的范例Q它甚至提供了动态生成的DAO函数Q减了一pd的包装调用过E?br />
   代码生成更加深刻的应用是完成高层模型向低层模型的转化Q这一q程往往是非q_(non-trivial)的。在Witrixq_中通过代码生成来支持领域抽象,可以用非怽的成本跨结构障,自定义的领域模型嵌入到现有的技术体pM。这其中我们的主要工作是解决了生成代码与手工书写代码之间的有效隔d动态融合问题,保代码生成可以反复的以增量的方式进行,同时支持最l粒度处对生成的代码q行定制调整?br />
   举一个简单的例子Q假讄在需要开发一个三步审批的程Q每一步的操作人可以录入意见,可以选择通过或者回退Q可以选择下一步操作的具体操作人,pȝ自动记录操作旉Q每个操作h可以查看自己的操作历史等。虽然在现有技术体pM实现q一功能需要不代码,但是在业务层面上描述q一功能q不需要很多文字,实际需要提供的信息量很。显Ӟ建立领域模型是比较适合的做法,可以定义一UDSL(Domain Specific Language)来描q这一模型?br />
   <flow_cp:SeqFlow>
     
<step id="draft" userField="draferId" dateField="draftTime" waitStatus="drafted" />
     
<step id="check" userField="checkerId" dateField="checkTime" opinionField="checkOpinion"
                   waitStatus
="sent" />
     
<step id="approve" userField="approverId" dateField="approveTime"
                opinionField
="approveOpinion" waitStatus="checked" passStatus="approved" />  
   
</flow_cp:SeqFlow>

   以上功能涉及到多个操作场景,实现的时候需要补充大量具体信息,其中很大一部分信息来自于背景知识,例如昄样式Q界面布局Q前后台通信方式{。以上模型可以进一步抽象ؓ如下标签
   <flow_cp:StepFlow3/>

  在不同应用中复用以上程逻辑的时候可能需要局部修正,例如
   <flow_cp:StepFlow3>
      
<step id="check" userField="checker" />
   
</flow_cp:StepFlow3>

   更加复杂的情形是DSL本n提供的抽象无法满_部需求,而需要在局部补充更多模型之外的信息Q例如物品接收单审批通过后自动导入库存等?br />  
   在Witrix中,代码生成不是直接产生最l的输出Q而是在编译期生成基础模型Q它与补充描q通过extends子q行融合q算之后产生最l输? q种融合可以实现基础功能的新增,更改或者删除。典型的调用形式?br />

  
<biz-flow>
       
<extends>
         
<flow_cp:StepFlow3>
           
<step id="check" userField="checker" />
          
</flow_cp:StepFlow3>
       
</extends>
       
       
<action id="pass_approve">
         .
       
</action>
   
</biz-flow>

q里的操作过E可以看作是BizFlow extends SeqFlow<FlowConfig extends StepFlow3Config>Q与泛型技术非常类|只是需要更强的局部结构控制能力?br />     按照U列理论http://canonical.javaeye.com/blog/33824 Q我们可以定义一个DSL的列,整个抽象q程?br />
     Context0 + DSL1 + EXT0 = DSL0
     Context1 + DSL2 + EXT1 = DSL1
       

    在目前一些通用语言中,也有一些所谓内嵌DSL的方案,可以提供比较z的业务描述。但是仅仅徏立DSL描述是不充分的,从列理论的观点看,我们必须提供一UDSL的补充手D,能够在细节处补充DSL模型之外的信息,实现两者的自然融合。同时我们应该可以在不同的抽象层面上独立的进行操作,例如?DSL1和DSL2的层面上都可以通过cMl承的操作实现局部调_q同时也包括在不同的抽象层面上都能对模型q行合法性校验?br />    


canonical 2008-11-23 11:57 发表评论
]]>
AOP on XML Taghttp://www.tkk7.com/canonical/archive/2008/07/07/212933.htmlcanonicalcanonicalSun, 06 Jul 2008 16:12:00 GMThttp://www.tkk7.com/canonical/archive/2008/07/07/212933.htmlhttp://www.tkk7.com/canonical/comments/212933.htmlhttp://www.tkk7.com/canonical/archive/2008/07/07/212933.html#Feedback0http://www.tkk7.com/canonical/comments/commentRss/212933.htmlhttp://www.tkk7.com/canonical/services/trackbacks/212933.htmlhttp://canonical.javaeye.com/blog/34941 AOP使我们可以通过非R入性的方式动态修?#8220;L”已经构徏好的E序Q而不需要事前有大量的设计准备。原则上?q种技术思想是可以在ME序语言基础上进行表辄Qƈ不是只有java, C#q样的面向对象语a才允许AOP操作. Witrixq_中所应用的部分技术与AOP有些cMQ只是大量的l构调整表现为xml生成和xml变换Q在具体的用方式上也有一些微妙的差异?a >http://canonical.javaeye.com/blog/126467

  相对于通用E序语言Qxml语言其实是AOP技术的一个更加合适的形式载体?br /> 1. xml格式Ҏ的规范性确保了在最l的逻辑_度上,E序l构也是可识别的Q可操纵的(在这一点上非常cM于函数式语言Q。而所有的命o式语a(imperative language)中,函数内部的结构都是很N用统一方式q行描述和定位的?
   <ns1:loop>
     
<rpt:Row/>
   
</ns1:loop>

2. xml节点的坐标可以采用xpath或者css选择W等通用方式q行描述Q而一般程序结构无法达到xml格式q样的均一性,其中的坐标定位方式要复杂得多?br /> 3. xml节点上可以增加Q意属性,不同的属性可以属于不同的命名I间(namespace)Q这些属性可以辅助AOP的定位机制。而一般程序语a中如果没有Annotation机制, 则定位只能依赖于函数名和cdQ函数参数只有类型没有名UͼQ而类名和函数名随时可能因Z务变化而调_不是专ؓ定位而存在), 由此构徏的切Ҏq符是不E_的?br />  
<ui:PageTable pager="${pager}" cache:timeout="1000" />
4. xml节点的增删改查显然要比字节码生成技术要单和直观得多?br />    

   AOP技术难以找到应用的一个重要原因在于很多h机械式的它定位ZU横切技术,认ؓ它的价值完全在于某个确定的切面可以插入到多个不同的切点Q实现系l的横向分解。而在实际应用中,业务层面上很具有可抽象的固定的共同性,我们所q切需要的一般是对已有程序结构进行动态扩展的一U能力。横切是AOP的一U特D的应用Q但不是它的全部。相对于l承(inheritance){依赖于概念诠释的结构扩展机ӞAOP所代表正是对程序结构空间进行Q意操U늚一U能力。AOP可以为基l构增加功能Q改变原有功能实玎ͼ也可以取消原有功能实玎ͼ它不需要把所有的扩展逻辑按照树Şl构q行l织Q不要求在基l构中ؓ扩展~写Ҏ的代码。这U自ql构扩展能力在Witrixq_中被发展?#8220;实现业务代码与^台基架构之间的动态融?#8221;?br />
   在Witrixq_的实际应用中QAOP的切点匹配能力ƈ不是十分重要。一般情况下我们主要通过整体l构规划来确保控制点意义明确且相寚w中,因此不需要额外通过切点匚wq行业务功能的再l织Q不需要再ơ从杂ؕ的程序逻辑中重新发现特D的控制炏V例如在Witrixq_的Jsplet框架中所有后C件响应都通过objectName和objectEvent参数触发Q在触发后台事g响应函数之前都会调用bizflow文g中的beforeActionDc?br />    在bizflow文g中,aop操作是明指定到具体函数的,使用模糊匚w在一般情况下只会佉K题变得不必要的复杂化。例如扩展actQuery函数
   <action id="aop-Query-default">
    
<source>
       通过自定义标{抽象出多个Action之间的共用代?br />       
<app:DoWorkA/>
    
</source>
  
</action>

   
   在Witrixq_中结构组装主要是通过自定义标{ֺ和extends子来实玎ͼ它们都依赖于xml格式的规范性?br /> 1. 通过在custom目录下实现同名的自定义标{,卛_覆盖Witrixq_所提供的缺省标{֮玎ͼq里所依赖的ƈ不是复杂的匹配过E,而是自然直观的映过E?a >http://canonical.javaeye.com/blog/196826
2. 所有的xml配置文g支持extends操作Q它允许定制两个h业务含义的xml节点之间的结构融合规则。例?lt;biz-flow extends="docflow">?br />
   实际使用? AOP技术的一个应用难点在于状态空间的理问题。一般interceptor中所能访问的变量局限ؓthis指针所携带的成员变量,以及函数调用时传入的调用参数。interceptor很难在状态空间中创徏新的变量Q也很难d在其他地Ҏ产生的状态变量。例如对于如下扩?A(arg1); B(arg2); C(arg3); =?Ax(arg1); B(arg2); Cx(arg3); 因ؓ原有的调用序列中没有传递额外的参数Q因此A和C的扩展函C间很隑֮现共享内部变量x。在TPL模板语言中,tpl本n是无状态的Q状态变量通过外部?thisContext对象l一理。通过q种行ؓ与状态的分离Q结合灵zȝ变量作用域控制机Ӟ可以以比较简单的方式实现扩展函数之间的信息共享?br />


canonical 2008-07-07 00:12 发表评论
]]>
M分解而不是正交分?/title><link>http://www.tkk7.com/canonical/archive/2008/05/26/202801.html</link><dc:creator>canonical</dc:creator><author>canonical</author><pubDate>Sun, 25 May 2008 16:41:00 GMT</pubDate><guid>http://www.tkk7.com/canonical/archive/2008/05/26/202801.html</guid><wfw:comment>http://www.tkk7.com/canonical/comments/202801.html</wfw:comment><comments>http://www.tkk7.com/canonical/archive/2008/05/26/202801.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.tkk7.com/canonical/comments/commentRss/202801.html</wfw:commentRss><trackback:ping>http://www.tkk7.com/canonical/services/trackbacks/202801.html</trackback:ping><description><![CDATA[    说到分解Q很多h心中的意象大概只有正交分解。正交分解无疑是最重要的一U分析方法,它也是所?#8220;分而治?#8221;思想最常见的实现策略。但是正交分解一般潜在的假定是分解后的子部分是大致均衡的Q它们是相对h独立价值的Q可以彼此脱ȝ立发展。这是分解后实现pȝ解耦的重要原因?a >http://canonical.javaeye.com/blog/33885</a> 但是物理学中另一U重要的分析学思想是微扰论(Perturbation). 针对一个复杂的物理现象Q首先徏立一个全局的规范的模型Q然后考虑各种微扰条g对原有模型的影响。在扰动情况下Q模型的变化部分往往可以被线性化Q被局域化Q因而问题得到简化。微扰分析得到的解依赖于全局模型的解而存在,因而这是一U主从关pȝ分解方式。但是如果主体模型是我们已经熟知的物理现象,则我们关注的重点可以全部攑֜扰动解上Q认为所有特定的物理规律都体现在扰动解中。如果微扰分析得到的物理元素_丰富Q则微扰模型本n可以成ؓ独立的研I对象,在其中我们同样可以发现某U普适的l构规律?br />     Witrixq_中系l化的应用主从分解模式,通过cMAOP的技术实C业务模型与^台技术的自然l合?a >http://canonical.javaeye.com/blog/126467</a> 最q我们的一个品的新版本即在全国范围内部|Ԍ如何有效的控制众多相q的二次开发版本,同时保ȝ本的快速升U,是在架构层面必须解决的问题?a >http://canonical.javaeye.com/blog/73265</a> 在Witrixq_中,各部|版本ƈ不是直接修改ȝ本源代码得到Q而是差异化代码攑֜单独的目录中q行理Q由pȝq行q_负责差异化定制代码与主版本代码q行动态融合,实现部v版本的客户化。在q一q程中,pȝ模型本n支持逆元l构臛_重要Q否则某些多余的元素无法通过差异性描q去除,则将出现局部模型失效的情况?br />     Witrixq_定义了特D的_custom目录Q它的内部目录结构与defaultroot目录相同Q系l^C先用该目录下文件所提供的功能实现。同时定义了pȝ参数global.app_id和global.default_app_idQ它们分别用来区分当前程序版本以及程序主版本代码。例如当global.app_id=beijing,global.default_app_id=main的时候,pȝ中装载ui.xmlq个标签库时l历如下q程Q?br /> 1.    装蝲q_内置的标{ֺQ文件\径ؓ /_tpl/ui.xml.<br /> 2.    Ҏglobal.default_app_id讄Q装?_custom/main/_tpl/ui.xml, 其中定义的标{֮现将覆盖q_~省提供的标{֮现。对于那些不需要特D定制的标签Ql用^台提供的~省实现?br /> 3.    Ҏglobal.app_id讄Q装?_custom/beijing/_tpl/ui.xml, 其中定义的标{֮现将覆盖产品ȝ本的标签实现?br /> <br /> 基础q_中对于代码动态融合定义了_的融合策略,通过~译技术检查扩展标{接口与缺省实现的接口相兼容,由此保代码扩展后不会破坏主版本中的已有调用代码?br />     在基q_的实CQ很多实C码都是类?br /> <div style="border: 1px solid #cccccc; padding: 4px 5px 4px 4px; background-color: #eeeeee; font-size: 13px; width: 98%;"><!--<br /> <br /> Code highlighting produced by Actipro CodeHighlighter (freeware)<br /> http://www.CodeHighlighter.com/<br /> <br /> --><span style="color: #000000;">          </span><span style="color: #0000ff;"><</span><span style="color: #800000;">df:WhenAllowFinishWf</span><span style="color: #0000ff;">></span><span style="color: #000000;"><br />             </span><span style="color: #0000ff;"><</span><span style="color: #800000;">df:FinishWfButton </span><span style="color: #0000ff;">/></span><span style="color: #000000;"><br />           </span><span style="color: #0000ff;"></</span><span style="color: #800000;">df:WhenAllowFinishWf</span><span style="color: #0000ff;">></span></div> <br /> q样的类似废话的标签调用。但是通过q些标签的标讎ͼ我们立了系l的逻辑l构Q标定了pȝ中可以被安全替换的逻辑片断? <img src ="http://www.tkk7.com/canonical/aggbug/202801.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.tkk7.com/canonical/" target="_blank">canonical</a> 2008-05-26 00:41 <a href="http://www.tkk7.com/canonical/archive/2008/05/26/202801.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>不完全的计算http://www.tkk7.com/canonical/archive/2008/03/16/186614.htmlcanonicalcanonicalSun, 16 Mar 2008 07:04:00 GMThttp://www.tkk7.com/canonical/archive/2008/03/16/186614.htmlhttp://www.tkk7.com/canonical/comments/186614.htmlhttp://www.tkk7.com/canonical/archive/2008/03/16/186614.html#Feedback0http://www.tkk7.com/canonical/comments/commentRss/186614.htmlhttp://www.tkk7.com/canonical/services/trackbacks/186614.html   o.someFunc()                  o.onEventA();
    sub1.someFunc();      ==>     sub1.onEventA();
    sub2.someFunc();              sub2.onEventB();
如果把对象看作是函数+状态的集合Q则对象l装的关pd际上是函数集合之间的一U组装关pR当具体的事件发生的时候,触发对象上定的响应函敎ͼ此时在各个层面上所实际发生的计才能被定下来?br />




canonical 2008-03-16 15:04 发表评论
]]>
WebMVC之前?今生http://www.tkk7.com/canonical/archive/2008/02/18/180551.htmlcanonicalcanonicalMon, 18 Feb 2008 14:02:00 GMThttp://www.tkk7.com/canonical/archive/2008/02/18/180551.htmlhttp://www.tkk7.com/canonical/comments/180551.htmlhttp://www.tkk7.com/canonical/archive/2008/02/18/180551.html#Feedback0http://www.tkk7.com/canonical/comments/commentRss/180551.htmlhttp://www.tkk7.com/canonical/services/trackbacks/180551.htmlhttp://canonical.javaeye.com/blog/33824

   1. 外部视角Q原始的servlet规范提供了一个简单的面向IO的程序响应模型。一ơ前台访问由一个特定的servlet负责响应Q它从request中读取输入流Q在全局session中保持时状态,向response中写入输出流。在此基上,JSP提供的模板概늿转了E序和输出文本之间的相对CQ简化了文本输出q程。至此,q种整体的程序模型基本上只是规范化了外部pȝ讉KWeb服务器的响应模型Qƈ没有对后台程序的具体实现制定明确的约束条件。因此在最_野的后台实CQ读取参敎ͼ业务处理Q生成页面等处理步骤是纠~在一LQ很隄解,也很N用。每一个后台页面都是一个不可分析的整体?br />
<%
   String paramA 
= request.getParameter("paramA");
   ResultSet rsA 
= 
%>
   result 
= <%=rsA.getString(0%>
   String paramB 
= request.getParamter("paramB");
   ResultSet rsB 
= 
<%
   rsB.close();
   rsA.close();
   conn.close();
%>


2. 自发分离Q在复杂的程序实践中Q我们会自发的对业务处理代码和界面代码进行一定程度的分离。因为我们可以直观的感受到这两种代码的稳定性ƈ不匹配。例如不同业务处理过E生的l果都可以用一个html表格来展玎ͼ而同一个业务处理过E生的l果面可能l常发生变化。一般我们們֐于将业务代码写在面上方Q而界面代码写在页面下方,q用一些原始的分解机制Q例如include指o。这U分L随意的,~Z形式边界的。例如我们无法表达被包含的页面需要哪些参敎ͼ也难以避免全局变量名冲H。需要注意的是,分层的一般意义在于各个层面可以独立发展,它的隐含假定是各层面之间的交互是规范化的Q只使用定的数据结构,按照定的方式进行交互。例如业务层和界面层通过标准的List/Map{数据结构交互,而不是用具有无限多U样式的Ҏ的数据结构?在弱cd语言环境中,实体对象的结构和Map是等L).
<%
   List header 
= 
   List dataList 
= 
%>
<%@ include file="/show_table.jsp" %>


   3. 规范分离QJSP所提供的useBean和tag机制Q即所谓的Model1模型Q是对程序结构分ȝ一U规范化。业务代码封装在javacMQ一般业务函Cweb环境无关Q即不用request和response对象, 允许单元试。tag机制可以看作是对include指o的增强,是一U代码重用机制。tld描述明确了调用tag时的U束关系。调用tag旉要就地指定调用参敎ͼ而include面所依赖的参数可能是在此前Q意地Ҏ定的Q是与功能实现分ȝ。此外tag所使用的参数名是局部对象上的属性名Q从而避免了对全局变量的依赖。很遗憾的是Qjsp tag所装的仍然是原始的IO模型Q对E序l构~Z_的定义,在概念层面上只是Ҏ本片D늚再加工,难以支撑复杂的控件结构。早期jsp tag无法利用jsp模板本n来构造,无法构成一个层层递进的概忉|象机Ӟ更是让这U孱q重用模型雪上加霜。在其位却无能谋其政Q这直接造成了整个j2ee前台界面抽象层的概念~失Q以致很多h认ؓ一U前台模杉K用机制是无用的。在Witrixq_中所定义的tpl模板语言Q充分利用了xml的结构特点,l合~译期变换技术,成ؓWitrixq_中进行结构抽象的基本手段。实际上Qxml能够有效表达的语义比一般h所惌的要多得多?br />
 <jsp:useBean id="myBiz" class="" />
  
<% List dataList = myBiz.process(paramA) %>
  
<ui:Table data="<%= dataList %>" />

  
  4. 框架分离Q在Model1模型中,面中存在着大量的粘l性代码,它们负责解析前台参数Q进行类型{换和数据校验Q定位特定的业务处理c,讄q回l果Q控刉面蟩转等。一U自然的x是定义一个全局的程序框Ӟ它根据集中的配置文g完成所有的_结性操作。这也就是所谓面向action的WebMVC模型。这一模型实现了服务器端业务层和界面层在实C的分,但是对于外部讉K者而言Q它所暴露的仍然是原始的自动机模型Q整个网站是一个庞大的自动机,每次讉K都触发一个actionQ在action中可能更改自动机的状态(作ؓ全局状态容器的session对象或者数据库Q。struts作ؓ面向action框架的先驱,它也很自然的成ؓ了先烈。struts中所引入的FormBean, 链接理{概念已l在实践中被证明是无益的。一些新兴的框架开始回归到通用的Mapl构Q直接指定蟩转页面,或者利用CoC(Convention Over Configuration)~省映射.
public class RegisterAction extends Action {
    
public ActionForward perform (ActionMapping mapping,
                                  ActionForm form,
                                  HttpServletRequest req,
                                  HttpServletResponse res)
{
    RegisterForm rf 
= (RegisterForm) form;
    
    
return mapping.findForward("success");
}

  
5. 横向延展Q分层之后必然导向各个层面的独立发展Q我们的视野自然也会扩大到单个页面之外,看到一个层面上更多元素之间的相互作用.在面向对象语a大行光的今天,l承(inheritance)无疑是多Ch首先惛_的程序结构组l手D.后台action可以很自然的利用java语言自n的承机Ӟ配置文g中也可以定义cM的extends或者parent属性.但是对于前台面一般却很少有适用的抽象手D,于是便有力于前台面的对象语a化:首先前台页面采用某U对象语a表达Q然后再利用对象语言内置的结构抽象机Ӟ攑ּ界面的可描述性,其转化为某U活动对象,在我看来是一U错误的方向Q而JSF(JavaServerFace)规范却似乎想在这个方向上走远QJSF早期设计中存在的一个严重问题是延箋了面向对象语a中的状态与行ؓl定的组l方式.q造成每次讉K后台面都要重徏整个Component Tree, 无法实现面l构的有效缓存.而Witrixq_中的tpl模板语言~译出的l构是无状态的Q可以在多个用户之间重用Q?br />
  6. 相关聚合Q对象化首先意味着相关性的局域化Q它q不{h于对象语a? 当面对一个大的集合的时候,最自然的管理手D便是分l聚合:紧密相关的元素被分配到同一分组Q相x被局域化到组内.例如Q针Ҏ个业务对象的增删Ҏ操作可以看作属于同一分组. struts中的一个最佛_跉|使用DispatchAction, 它根据一个额外的参数调用请求映到Action对象的子函数上.例如/book.do?dispatchMethod=add. 从外部看来,q种讉K方式已经越了原始的servlet响应模型Q看h颇有一些面向对象的样子Q但也仅仅局限于样子而已QDispatchAction在struts框架中无疑只是一U权宜之计,它与form, navigation{都是不协调的,而且多个子函C间ƈ不共享Q何状态变量(即不发生内部的相互作用)Qƈ不是真正对象化的l织方式Q按照结构主义的观点Q整体大于部分之和.当一l函数聚集在一L时候,它们所催生的一个概念便是整体的表征Qthis指针QWitrixq_中的Jsplet框架是一个面向对象的Web框架Q其中同属于一个对象的多个Action响应函数之间可以׃n局部的状态变量(thisObjQ,而不仅仅是通过全局的session对象来发生无差别的全局兌Q?a >http://canonical.javaeye.com/blog/33873 需要注意的是,thisObj不仅仅聚集了后台的业务操作,它同时定义了前后C间的一个标准状态共享机Ӟ实现了前后台之间的聚合.而前台的add.jsp, view.jsp{页面也因此通过thisObj产生了状态关联,构成面分组Qؓ了更加明的支持前台面分组的概念,Witrixq_提供了其他一些辅助关联手D.例如标准面中的按钮操作都集中在std.js中的stdPage对象上,因此只需要一条语句stdPage.mixin(DocflowOps);卛_为docflow定制多个面上的众多相关按钮操作Q此外Witrixq_中定义了标准的url构徏手段Q它保在多个页面间跌{的时候,所有以$字符为前~的参数将被自动携带.从概念上说这是一U类gcookieQ但却更加灵z,更加面向应用的状态保持机Ӟ

  class DaoWebAction extends WebContext{
     IEntityDao entityDao;
     String metaName;

     
public Object actQuery(){
       
       thisObj.put(
"pager",pager);
       
return success();
     }

     
public Object actExport(){
       Pager pager 
= (Pager)thisObj.get("pager");
       
       
return success();
     }
    }


  7. 描述分离Q当明确定义了Action所聚集而成的对象结构之后,我们再次回到问题的原点:如何化程序基元(对象Q的构徏Q承始l是一U可行的手段Q但是它要求信息的组l结构是递进式的Q而很多时候我们实际希望的l织方式只是单的加和。通过明确定义的meta(元数?Q从对象中分d部分描述信息Q在实践中被证明是一U有效的手段。同L后台事g响应对象(ActionObject)Q同L前台界面昄代码(PageGroup)Q配合不同的MetaQ可以生完全不同的行ؓl果, 表达不同的业务需求?a >http://canonical.javaeye.com/blog/114066 从概念上_q可以看作是一U模板化q程或者是一U复杂的{略模式 ProductWebObject = DaoWebObject<ProductMeta>。当焉于技术实现的原因Q在一般框架实CQmetaq不是通过泛型技术引入到Web对象中的。目前常见的开发实践中Q经常可以看见类似BaseAction<T>, BaseManager<T>的基c,它们多半仅仅是ؓ了自动实现类型检查。如果结合Annotation技术,则可以超类型填充,部分辑ֈMetal合的效果。用meta的另外一个副作用在于Qmeta提供了各个层面之间新的信息传递手D,它可以维pd个层面之间的共变(covariant)。例如在使用meta的情况下Q后C码调用requestVars(dsMeta.getUpdatableFields())得到提交参数Q前台页面调用forEach dsMeta.getViewableFields()来生成界? 则新增一个字D늚时候,只需要在meta中修改一处,前后台即可实现同步更斎ͼ自动l持前后台概늚一致性。有的是,前后台在分离之后它们之间的关联变得更加丰富?br />
8. 切面分离: Meta一般用于引入外部的描述信息Q很直接改变对象的行ؓl构。AOP(Aspect Oriented Programming)概念的出CؓE序l构的组l提供了新的技术手DcAOP可以看作是程序结构空间中定位技术和l装技术的l合Q它比承机制和模板机制更加灉|Q也更加强大?a >http://canonical.javaeye.com/blog/34941 Witrixq_中通过cMAOP的BizFlow技术实现对DaoWebAction和前台界面的行ؓ扩展Q它可以在不扩展DaoWebActioncȝ情况下,增加/修正/减少web事g响应函数Q增?修正/减少前台界面展现元素。当前台发送的$bizId参数不同的时候,应用到WebObject上的行ؓ切片也不同,从而可以自然的支持同一业务对象h多个不同应用场景的情况(例如审核和拟Ӟ。在BizFlow中定义了明确的实体化q程Q前台提交的集合操作被分解为针对单个实体的操作。例如前台提交objectEvent=Remove&id=1&id=2,会调用两次<action id="Remove-default">操作。注意到AOP定位技术首先要求的是良好的坐标定? 实体化明定义了实体操作边界Qؓ实体相关切点的构造奠定了基础?a >http://canonical.javaeye.com/blog/33784

9. 背景消除Q在Witrixq_? (DaoWebAction + StdPageGroup + Meta + BizFlow)构成完整的程序模型,因此一般情况下q不需要承DaoWebActionc,也不需要增加新的前台页面文Ӟ而只需要在BizFlow文g中对修正部分q行描述卛_。在某种E度上DaoWebAction+StdPageGroup所提供的CRUD(CreateReadUpdateDelete)模型成ؓ了默认的背景知识。如果背景信息极泄漏,则我们可以在较高抽象层次上进行工作,而不再理会原始的构造机制。例如在深度集成hibernate的情况下Q很会有必M用SQL语句的需求。BizFlow是对实体相关的所有业务操作和所有页面展现的集中描述Q在考虑到背景知识的情况下,它定义了一个完整的自给自的程序模型。当我们的徏模视角{UdBizFlow模型上时Q可以发展出新的E序构造手Dc例如BizFlow之间可以定义cMl承机制的extends子Q可以定义实体状态驱动的有限自动机,可以定义不同实体之间的钩E关p(实体A发生变化的时候自动更新实体B上的相关属性)Q也可以定义对Workflow的自然嵌入机制。从表面上看QBizFlowg回归C前后台大杂烩的最初场景(甚至更加严重Q它同时描述了多个相关页面和多个相关操作Q,但是在分分合合的模型建立q程中,大量信息被分解到背景模型中,同时发展了各U高U结构抽象机? 保了我们注意力的关注点始终是有限的变化部分。而紧致的描述提高了信息密度,化了E序构造过E?a >http://canonical.javaeye.com/blog/126467
  <bizflow extends="docflow"> <!-- 引入docflow模型Q包括一pd界面修正和后台操作 -->
<biz id="my">
     
<tpls>
       
<tpl id="initTpl">
          
<script src="my_ops.js" ></script>
          
<script>
            stdPage.mixin(MyOps); // 引入多个面上相x钮对应的操作
          
</script>
       
</tpl>
     
</tpls>
    
</biz>
  
</bizflow>





canonical 2008-02-18 22:02 发表评论
]]>
关系模型与ORMhttp://www.tkk7.com/canonical/archive/2008/01/06/173154.htmlcanonicalcanonicalSun, 06 Jan 2008 11:04:00 GMThttp://www.tkk7.com/canonical/archive/2008/01/06/173154.htmlhttp://www.tkk7.com/canonical/comments/173154.htmlhttp://www.tkk7.com/canonical/archive/2008/01/06/173154.html#Feedback3http://www.tkk7.com/canonical/comments/commentRss/173154.htmlhttp://www.tkk7.com/canonical/services/trackbacks/173154.html    
    通过idQ伴随一个匹配计过E)来进行间接关联对于保证模型的一致性是非常关键的。在ORM中恢复了对象的强兌其实会造成很多潜在的复杂性。例如ؓ了维护对象层面结构的一致性,在更新父子关pȝ时候,我们需要同时调?child.setParent(parent); parent.getChildren().remove(child); 当关联结构更加复杂的时候,q里所需要的l护工作是随之增加的。不q,在ORM中,对象的Ş态是暂时性的。在ORM的一ơsession的操作过E中Q对于对象状态的修改可以是不一致的。例如我们可以只调用child.setParent(parent); 而不需要同?nbsp; parent.getChilren().remove(child); 只要我们在此ơsession操作中,不需要同时用到parent.getChildren(). q种兌的暂时性对于很多ORM应用来说是必不可的?br />    
    对象模型中可以直接表辄l构关系比关pL型要丰富一些,例如l承关系Qmany-to-many, one-to-list{。但是所有这些都不是真正本质性的差异。抛弃概念诠释,基类与众多派生类之间的关pd本上可以{h于一lone-to-one关系。而当兌对象本n的重要性凸现出来的时候,当我们无法把它约化ؓ对象上的一些附属特性的时候(例如数组的下标)Q我们必然要建立相应的关联对象,而这正对应于关系模型中的中间兌表。中间关联表上增加额外的字段是一个自然的扩展q程Q而对象模型上做这L扩充往往表现为Ş态上的重大的不兼容的变化Q例如从getManyToManyEntity() -> getToManyRelation(), q实际上意味着q里的对象Ş式是偶然的,化的?
   
    在原始的关系数据库模型中Q所有的表之间的C是^{的Q所有字D之间的C是^{的Q主键和外键在参与数据关联时和其他字D늚处理方式一_。这U概念上的均一性和普遍性往往被认为是理论的优之处。但是现实世界是复杂的,发展的方向就是逐步识别Z同之处,q找然的表达形式这些不同表辑և来。均匀的关pL型是对称性最高的Q最化的模型。在面对物理U束Ӟ它隐含的假设是集合之间很发生相互作用,单表Q表单到数据表之间的映射Q和M表是最q泛的情c试着惌一下关pL型,在思维中一般我们只能看C个数据表Q当考虑到多个表的时候,因ؓq些表之间没有明的可区分性,因此它们的意象是模糊的。只有明意识到主键Q外键,主表Q从表,字典表,事实表,U度表这些不同的概念的时候,当对U性出现破~的时候,我们思维中的模型才能够丰富化h?br />    
    关系模型理论应用到数据库具体应用中时Qƈ不需要死守关p范式教条,它们只是描述了某U极端化的对唯一性的q求。面对具体应用的时候,理论本n也在不断丰富化。我q不把现实应用中必然需要增加冗余字D늜作是关系理论失效的结果。从关系完全分解Q到关系完全不分解之_我们可以建立大量的模型。徏立冗余字D늚时候,我们存在着大量可能的选择Q到底哪一U选择是最优的Q理论方面仍然可以给我们以具体的指导。理论在各种不同U化E度的关pL型中都可以给我们以直观的。数据仓库理Z建立的snowflake模式和star模式Q强调了针对主题域的允许部分冗余的关pd解。这里实际上是强调了表之间的不同性。不再是所有的表都处于同一C。Fact Table和Dimension Table之间的区别被识别出来Qƈ被明处理。在我看来,q是原始关系模型的一U自然发展,它也是关pL型理论的一部分。理Z应该是单一的,而是提供一个模型列,在不同的复杂性层ơ上Q我们可以根据理论的指导选择具体的实现模型?br />    
    关于ORM http://canonical.javaeye.com/blog/111500
    关系模型中的所谓关pL在用时L定义的,所有徏立关pȝ方式在某U程度上都是{h的,也是外在的。而在ORM中主键与外键之间的关联被独立出来Q成为模型内|的部分。这在很多时候简化了数据查询的结构构造过E?br />     在ORM中主键因为缓存的存在而显Z其他字段的区别。ORM的用得数据存储的分解{略得到扩充。ƈ不是所有的表的更新频度都是一致的Q而且表中的数据量大小也不同。字典表一般较,而且很少更新Q可以安全的复制。在整个数据存储框架中,ORM作ؓ独立的技术元素参与数据存储过E,通过主键提供~存服务Q生了新的数据分布模型Q提供了新的性能优化契机?br />



canonical 2008-01-06 19:04 发表评论
]]>
代码之外的结?/title><link>http://www.tkk7.com/canonical/archive/2007/12/15/167994.html</link><dc:creator>canonical</dc:creator><author>canonical</author><pubDate>Sat, 15 Dec 2007 11:46:00 GMT</pubDate><guid>http://www.tkk7.com/canonical/archive/2007/12/15/167994.html</guid><wfw:comment>http://www.tkk7.com/canonical/comments/167994.html</wfw:comment><comments>http://www.tkk7.com/canonical/archive/2007/12/15/167994.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.tkk7.com/canonical/comments/commentRss/167994.html</wfw:commentRss><trackback:ping>http://www.tkk7.com/canonical/services/trackbacks/167994.html</trackback:ping><description><![CDATA[    我在各种场合一直都在强调结构问题是独立的,在程序语a之外存在着独立的,可研I的Q富有成效的l构问题?a >http://canonical.javaeye.com/blog/147424 </a>在这个方向上更进一步,我们注意到所有的代码q不是天然出现的Q而是׃h所~制的,因此代码世界内部q不构成闭的,自的某个世界。代码中的结构问题ƈ不是׃码本w完全解决的Q即在代码之外仍然存在着技术上可研I的l构问题?br />     我们在编制代码的同时也在~制着大量的说明文。这些文描qC代码片断之间的相互关p,描述了代码未来的扩展方向Q描qC代码之间的可能的交互方式Q同时也描述了针对现有代码实现的很多具体U束。例如我们在文档中约定某个量要在10?0之间Q但在代码中却不一定显式进行了判断。针对代码结构的很多具体U束条g和相x描q可能只在文中体现Q只在程序员的头脑中存在Q而ƈ不一定忠实的在代码结构中得到表达?br />     我在设计领域基本持有一U物理实在论Q即某种技术相关的U束应该在技术世界中通过技术手D得到表达。只是这里的技术手D却不一定指在应用中加上特定的代码实玎ͼ虽然我们在代码实C更直接的表达设计要求无疑是需要提倡的。ؓ了在E序中有效的l护l构相关性,我们q不一定需要抽象出所有可能重用的代码Qƈ不一定需要确保某一概念在程序中只有_的唯一的表达。程序中难以直接_表达的弱兌Q仍然可以通过开?设计工具{技术手D得到有效的l护。我们需要保证的是代码世界中知识的自恰性,而自恰性ƈ不等于唯一性?a >http://canonical.javaeye.com/blog/33788</a><br />     在Witrix中我们采用一U物理模型驱动的开发方式,<a >http://canonical.javaeye.com/blog/29412</a> 由pdm模型出发Q自动生成hibernate的hbm文gQjava实体c,元数据meta文gQ前台Action注册文g{。生成的配置文g通过syncWithModel标记与模型保持着E_的关联。所有配|文仉支持手工修改Q开发工兯别syncWithModel标记Q当pdm模型发生变化的时候,工具自动变化信息同步到各个配置文g中。注意到q里q不是采用一个统一的元数据模型的方式,各个配置文g所表达的信息在一定程度上是重复的Q也可能是不一致的。例如后台数据库允许保存100个字节,但是前台meta中我们可能配|只允许录入20个字节。根据不同应用场景的需要,我们可以在各个层面对每个配置文gq行独立的调? 当然,在一般情况下q不存在q种需要。整个开发过E中Q信息表辄自恰性ƈ不是在应用程序代码中得到定义?而是因ؓ开发工L存在而在技术上得到保证的。放松模型之间的唯一匚w要求Q我们可以得到更加丰富,更加灉|的Y件结构。实际上我认为RoR(RubyOnRails)采用直接映射的ActiveRecord的方式虽然有效保证了pȝ变动中知识的一致性,但是如果不允许在各个层面上都能够自然的定义某U偏,它在复杂应用中的价值就要打上大大的折扣?br /> <br /> <img src ="http://www.tkk7.com/canonical/aggbug/167994.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.tkk7.com/canonical/" target="_blank">canonical</a> 2007-12-15 19:46 <a href="http://www.tkk7.com/canonical/archive/2007/12/15/167994.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>l构的独立?/title><link>http://www.tkk7.com/canonical/archive/2007/12/10/166820.html</link><dc:creator>canonical</dc:creator><author>canonical</author><pubDate>Mon, 10 Dec 2007 15:57:00 GMT</pubDate><guid>http://www.tkk7.com/canonical/archive/2007/12/10/166820.html</guid><wfw:comment>http://www.tkk7.com/canonical/comments/166820.html</wfw:comment><comments>http://www.tkk7.com/canonical/archive/2007/12/10/166820.html#Feedback</comments><slash:comments>1</slash:comments><wfw:commentRss>http://www.tkk7.com/canonical/comments/commentRss/166820.html</wfw:commentRss><trackback:ping>http://www.tkk7.com/canonical/services/trackbacks/166820.html</trackback:ping><description><![CDATA[   设计考虑的是最l需要什么,最l我们要提供的调用接口是什么,我们所直接需要的某个有h值的Q直接存在的Q直接可以接触的l构是什么,而不是它所依据的原理是什么,不是它的具体构造过E或者构造方法是什么。比如说我们在程序中完全不需要内|Mapq一l构Q因为它可以通过列表{结构组合构建出来,但是很显ӞMapq一概念的直接存在对我们来说是方便的Q是l济的,是有效的。我们在思考的时候ƈ不需要考虑它是采用List实现q是采用Set实现Q或者Q何它本n的构造结构。这一概念在我们的思想中成为某U原子化的东ѝ?br /> <br />     那么Q我们到底需要构建哪些概念,才能够最方便的基于这些概念应对万千应用系l的开发呢?q是我们需要在l构I间作出探烦的?q里的思维方向不是把系l推向某U纯_化Q某U极致的单化Q而是让它更加物理化,揭示出更多的层次Q更加关切在物理U束情况下如何实现灵zL的最大化。一U概念在物理上如果被证明能够在很多场景下成ؓ不变的基元,则它便是有h值的Q是可以q行物理诠释的?br /> <br />    很多Z惯于接受语言存在的现实,接受设计后的l果Q但是作为程序语a设计者,他们又是如何工作的?他们是否真的是从Ua的数学关pL演得到所有的语法特征Q还是他们预先已l在心中讑֮了应该出现的语法特征Q然后去L它的数学表达Q只是借此清除思维中潜在存在的矛盾性呢Q?br /> <br />     语言中存在的所有特征是l过全局考虑的,是清除了所有概늚矛盾冲突的。但是在现实中,我们偶然构造的l构却可能是局限于当下的信息构造的Q因此它们相会的时候,可能会出C协调Q可能会出现l构障碍。例如同h关闭操作Q有些h命名为close, 另一些h命名为destroy. 可能一个具有额外参敎ͼ另外一个没有。这里可能需要一Uadaptor接口的封装,也可能用ruby那种method-missing的动态判断。对于更加错l复杂的l构问题Q其解决Ҏ׃是那么显然的了,但这q不意味着我们无办法可惟뀂究竟设计何U结构边界才能最化l构融合时所要付出的代h呢?l构被识别ƈ表征出来以后Q是否允许它在一定范围内有所变ŞQ在变Ş中我们需要保持的拓扑不变量是什么?l构动态调整的时候,我们是否需要定义调整的物理代hQ是否能够定义某U动力学Q?br /> <br />    我所阐述的只是在计算机理Z从数学视角向物理视角的{换,它不是必然给你提供某U超当下的能力Q而是提供一U不同的眼光看待所有的一切。视角变换后Q我们发C一些新的命题,而在原先的视角下在我们的话语体系中原本是无法表达q些命题的。串行程序假设了只有1颗CPU, 而函数式语言假设了可以有无限多个CPU, 你不觉得1xI之间缺点什么吗。我们可以创造一些东西把1xI之间的I白补齐Q概늩间是q箋的?br />  <br /> <br /> <img src ="http://www.tkk7.com/canonical/aggbug/166820.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.tkk7.com/canonical/" target="_blank">canonical</a> 2007-12-10 23:57 <a href="http://www.tkk7.com/canonical/archive/2007/12/10/166820.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>关于抽象性的一些说?/title><link>http://www.tkk7.com/canonical/archive/2007/12/09/166520.html</link><dc:creator>canonical</dc:creator><author>canonical</author><pubDate>Sun, 09 Dec 2007 14:25:00 GMT</pubDate><guid>http://www.tkk7.com/canonical/archive/2007/12/09/166520.html</guid><wfw:comment>http://www.tkk7.com/canonical/comments/166520.html</wfw:comment><comments>http://www.tkk7.com/canonical/archive/2007/12/09/166520.html#Feedback</comments><slash:comments>5</slash:comments><wfw:commentRss>http://www.tkk7.com/canonical/comments/commentRss/166520.html</wfw:commentRss><trackback:ping>http://www.tkk7.com/canonical/services/trackbacks/166520.html</trackback:ping><description><![CDATA[<p>    没有人否认抽象的意义Q但是抽象是否就是抽象到无穷大,q是个可以明定义的问题Q也是数学领域正在解决的问题。在我们的思考中没有明确定义何处是边界, 没有明确的限Ӟq便是导向无IL一U思维方式Q它和现实中是否真的允许消耗无限多的资源,创徏无限多的对象无关。当我们认ؓ自己明白了终极的意义Q明? 了一U推向无IL抽象Q这q不是理解了世界的全部,我们仍然要明白如何解决一些更加小范围Q但是却又普遍发生的事情? <br /> 例如现在我的pȝ中只需?0个相互依赖的U程Q如果我们定M10q个数字Q显然我们可以发展一U这个领域特有的高效的一些算法结构。而抽象到通用语言 中的时候,昄我们只能假设U程数是L大,或者是充分大的Q而无法充分利?0q一领域信息Q因此在q个意义上我说通用语言不是有效的? <br /> 说到10q个定的数字,不过是一U极端化的比喅R我常说概念是连l的Qƈ不是非此卛_的,因此q不是从一U普遍情况到一U最Ҏ的情况之间不再有其他? 况了。在q中间环节,存在着非常深刻的复杂的物理事实。但是这些事实却又是某种有限性向我们揭示出来的。(请不要把q里的有限性理解ؓ术中的10以内Q? <br /> <br /> 现在来一个理论推演吧Q? <br /> 1. Mpȝ都在一定约束下q行Q即它们需要符合某些约束条? <br /> 2. 通用语言描述了某些结构,但是q些l构是充分通用的,能够应用到尽可能q泛的领域的 <br /> 3. U程?10q个U束q䆾ҎQ显焉用语言是不会考虑q个U束。实际上目前在通用语言设计中,无限资源假定基本都是默认的? <br /> 4. 我们承认某些现实的约束通用语言是不会考虑? <br /> 5. 在最Ҏ的,明显不会考虑的约束以及非帔R用Q一般通用语言必然考虑的约束之_是否存在着更多的,非^凡的l构? <br /> 6. 假如10q以内我们所有的g都只能支?0个内核,在我的品研发中假定10个线E有问题吗。难道我在开发的时候就不再需要抽象了吗。我在其他方面仍然是需要徏立抽象的? <br /> 7. n个抽象约?1个具体约束,以及 n个无限约?1个有限约?仍然是有效的抽象形式。原谅我在这里又使用了有效一词,它真的很隄解吗? <br /> 8. 不是在我们的思维中存在着具体的或者有限的物理?意味着q种思维是不抽象? <br /> <br /> 函数式语a或者Q何一U其他我们已知的与Turing机等L语言Q它们在某种数学的含义上说是"没有差别?。但是在我们的实际用过E中Q显然我们是 能够感受到它们之间的l构差异的。否则那些不断发明新的函数式语言的h的大脑都q水了吗Q在具体使用中,L人偏好这个语a,有h偏好那个语言, L某种情况下应用某个语a会方便一?另一些麻烦一些。难道在所有函数式语言中开发类似ErLang解决的那些程序结构都是一h便的吗? <br /> <br /> 有些人的是无论啥都逃不出函数式语言的思想。但是假如现在限定你必须使用java语言来开发商业应用,N你Ş工吗Q如果你不用函数式语言Q你所? 的工作就不是E序工作了?你所解决的难道不是程序结构问题了吗?现在是有一个结构问题要解决, 它是和语a无关? 语言提供了就可以直接? 语言没有提供我们可以写代码构? N除了语言直接体现的结构之? E序本n无法构造Q何具有通用价值的l构了吗Q?/p> <p> 我在说到函数式语a的时候,基本的态度只是说不要太沉迷于一U特D的抽象方式Q应该多看看别的视角。在不同的情况下存在着做事情的不同的最优方式。思维中不要只允许永远Q而容不下现在? <br /> <br /> 非此卛_Q天下唯?是我们思维中经帔R入的一个误区。现在计机领域所谓的理论主要是基于数学视角的Q没有考虑物理世界因ؓ我们观察的有限性,因ؓ资源 的有限性所造成的种U约束,此外数学中目前也没有考虑到物理世界真实的各种复杂性的存在。在我们惛_一U计机理论的时候,囑փq于单化Q这U简单化? 认ؓ是优的全部。其实我们应该思维更加开放一些? </p> <img src ="http://www.tkk7.com/canonical/aggbug/166520.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.tkk7.com/canonical/" target="_blank">canonical</a> 2007-12-09 22:25 <a href="http://www.tkk7.com/canonical/archive/2007/12/09/166520.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>关于语言有效性的一些澄?/title><link>http://www.tkk7.com/canonical/archive/2007/12/09/166472.html</link><dc:creator>canonical</dc:creator><author>canonical</author><pubDate>Sun, 09 Dec 2007 09:19:00 GMT</pubDate><guid>http://www.tkk7.com/canonical/archive/2007/12/09/166472.html</guid><wfw:comment>http://www.tkk7.com/canonical/comments/166472.html</wfw:comment><comments>http://www.tkk7.com/canonical/archive/2007/12/09/166472.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.tkk7.com/canonical/comments/commentRss/166472.html</wfw:commentRss><trackback:ping>http://www.tkk7.com/canonical/services/trackbacks/166472.html</trackback:ping><description><![CDATA[    数学上的有效性与物理中的有效性是不同的,例如对于密码学问题,如果通过ID法破解密码成功时Q经q这些密码加密的数据已经q了有效期限Q此时我们在数学上定义穷举法不是一U有效的破解Ҏ。但是物理层面上我们说只要一U方法比另一U方法能够更快的解决问题Q我们就说第一U方法比W二U方法有效,而无论密码被破解的时候该密码是否已经q了有效期限?br /> <br />     我所表述的论题ƈ不是说特定的领域l构无法在某个特定的通用语言中有效实现。我惛_多hҎ的话语都有些误解?br /> <strong>如果我们认ؓ一U通用语言是比较稳定的,则它一般选择只内|一些通用的不带有领域特定含义的概? 而缺乏领域知?或者说因ؓ通用语言故意的摒弃领域依? 它在处理领域相关的问题的时候ƈ不是有效?q种有效性不是数学含义上?而是可以q行物理度量?</strong> <br /> 现在ErLang寚w信领域h良好的支持,你可以说它对于通信领域的结构是有效的。但是显然在ErLang中编写界面就不如面向对象语言得心应手。在ErLang中实现界面结构的时候,它对于界面结构的表述׃是那么符合我们直观的Q对我们的实现过E来说就不是那么l济的。因此在界面l构的实CQ目前我们可以说ErLang相对于面向对象语a而言是不那么有效的。也怽会说ErLang做XX发展之后怎见得就更差。但是如果允许引入未来这一h无限可能性的因子Q我们基本上无法针对现实的情况作出判断。例如我们目前ƈ无法证明q义相对论相对于牛顿力学是更加精的Q如果允许在太阳星系中增加越来越多的隐蔽的摄动星体的话。按照库恩的U学革命论,每一个科学时代都h着自己的科学范式,它Lh着充分的自我辩护能力。范式的更新意味着格式塔的崩溃。回֎Ԍ哥白刚提出日心说的时候,q不是在计算_ֺQ计简z性上真的q胜托勒密的地心_只是日心说的哲学隐喻撼动了h心?br /> <br />     我说<strong>实际上现在的通用语言也是无法有效承蝲Domain Specific Structure?/strong>Q这q不是意指在通用语言中无法针对特定应用作出特定扩展来支持特定的结构,而是说Domain Specific Structure是Q意多的,作ؓ通用语言它不应该把越来越多的l构内置在语a?q不是很多h对ruby的希冀?Q这么做对它来说首先是不l济的。同时某些特D的l构在一定的场景下是有用的,但是把它抽象出来扩展到通用领域的时候,会出现有效性的丧失。例如现在我的系l中只需?0个相互依赖的U程Q如果我们定M10q个数字Q显然我们可以发展一U这个领域特有的高效的一些算法结构。而抽象到通用语言中的时候,昄我们只能假设U程数是L大,或者是充分大的Q而无法充分利?0q一领域信息Q因此在q个意义上我说通用语言不是有效的?br /> <br />     传统上数学用的一UD范式是:当n于无穷大的时候,偏差于无穷。现在物理学Ҏ学的一U常见要求却是:当n限定在有限数量范围的时候(例如10以内Q,我们如何才能量减少偏差。这要求对小h数学q行深入的研IӞ它所h的物理内涵也是不同的?br /> <br />     在物理的视角下,我们所兛_的不是世界在l极的意义上能否分解为函数的复合Q不是要导向一U宗教式的顶CD拜,而是要尊重自己所直接感受到的Q充分利用我们因为在q个世界上存在而获得的直观意象Q发掘自q直觉Q这h们才能在无限复杂的世界上借助有限的信息做出选择?br /> <img src ="http://www.tkk7.com/canonical/aggbug/166472.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.tkk7.com/canonical/" target="_blank">canonical</a> 2007-12-09 17:19 <a href="http://www.tkk7.com/canonical/archive/2007/12/09/166472.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>关于通用语言能力的一些澄?/title><link>http://www.tkk7.com/canonical/archive/2007/12/09/166375.html</link><dc:creator>canonical</dc:creator><author>canonical</author><pubDate>Sat, 08 Dec 2007 16:16:00 GMT</pubDate><guid>http://www.tkk7.com/canonical/archive/2007/12/09/166375.html</guid><wfw:comment>http://www.tkk7.com/canonical/comments/166375.html</wfw:comment><comments>http://www.tkk7.com/canonical/archive/2007/12/09/166375.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.tkk7.com/canonical/comments/commentRss/166375.html</wfw:commentRss><trackback:ping>http://www.tkk7.com/canonical/services/trackbacks/166375.html</trackback:ping><description><![CDATA[    我在前面的文章中列D了大量物理学相关的例子来试图说明采用物理视角的必要?但是可能因ؓ物理事实大家不熟?l果直接被无视了. 在本文中我想有必要D一个Y仉域的例子。只是在实际思考的q程?我主要还是基于物理概念进行推?<br />     <br />     首先我所?#8220;<strong>现在的通用语言</strong>”Q它q不意指“<strong>现在x来所有通用语言之合?/strong>”Q而是?#8220;<strong>目前正在被用的某一U通用语言</strong>”Q这U差别便体现了我所的不同的价D和不同的视角。不是一U覆盖一切的全称判断Q而是在特定物理约束下的物理实体?br />     <br />     现在无论我们设计什么大型系l,一般L要优先考虑微内核设计。但是很昄Q如果我们的~程控制能力极强Q强大到不现实的地步Q,我们可以把所有的代码实现Z个大的整体。一个整体的好处是勿用质疑的Q否则Linux Torvalds׃会有信心和Tanenbaum PK。但即是Linux, 随着pȝ来庞大,在内怸也补充了很多模块理{略。我q不把这U情늜作是一U现在技术能力不C所造成的结果,而是把它看作是在现实的物理约束下所促成的一U必然的选择?br />     <br />     按照cM的逻辑Q我认ؓ在通用语言层面不应该导入越来越多的特征Q实际上也不可能把所有可能的l构方式都内|在语言中(q种不可能不是数学意义上的不可能Q。这会破坏一U语a的纯z性,使得它极隄护和发展。ؓ了扩大通用语言的有效应用范_一U显然的方式是在语言中定义一些支持结构再ơ抽象的机制Q通过可插拔的方式实现与domain相关的知识的融合。rubyq样的语a提供了大量的元编E机? Witrixq_中tpl模板语言也发展了一pd~译期结构构造技? 但是昄它们都不能说是结构抽象技术的l极形? 目前我对所有通用语言所提供的结构抽象和l构l装能力都是不满意的,因此在Witrix中发展了一些领域特定的l构融合手段.例如Ҏ"l承"关系的结构诠?l承可以看作是两个一l集合之间的覆盖关系), 我们扩展了extends的结构操作方? 定义了广义的extends子. q些特定的结构关pȝ前在领域特定的BizFlow语言中体? 它们在通用语言中是难以惌? 而把它们攄在通用的语a中也是不合适的(q种复杂的结构融合操作如果不能结合领域知识进行直观的理解, 必将导向一U思维的؜?. q就是我所?现在的通用语言无法有效承蝲Domain Specific Structure"的含? q种说法其实cM?集合论是无法包容所有数学结构的". 我们在集合论中只研究最普遍的关p?而特定的l构在特定的学科中研I? <br />     <br />     关于ErLang的例? 我的原意是用来说明结构问题是独立?它是<strong>和具体语a无关</strong>?卛_于消息传递发生数据关联的轻量q程模型q一l构不是和ErLang语言l定? 为此我特意加了一D说?"q里不是要证明某U语a中无法描q这些结构,而是说结构是客观存在的,它ƈ不是要在基础语言层面得到充分解决?.<strong> 即在语a层面我们q不解决q个l构问题, 它仍然客观存在着,我们仍然可以用其他的技术手D去定义,去解? 解决了这个结构问题就必然会带l我们h?而无论我们用何U实现语a</strong>.<br /> <br />     "什么原因,什么样的约束条?D了现在的通用语言是无法有效承载消息传递发生数据关联的轻量q程模型". q一命题q不是我原文中论点的合理推论.我ƈ不是要说某一U特定的领域l构无法在一U特定的通用语言中得到支?而是说如果我们认ZU通用语言是比较稳定的,则它一般选择只内|一些通用的不带有领域特定含义的概? 而缺乏领域知?或者说因ؓ通用语言故意的摒弃领域依? 它在处理领域相关的问题的时候ƈ不是有效?q种有效性不是数学含义上?而是可以q行物理度量? 现在也有很多为ErLangq不是真正的通用语言,它是针对通信领域q行了特定结构调整的, 是内|了领域特定l构? 而目前在ErLang上徏立GUI的努力也q不是成功. <br />     <br />     在前文中我D了一个例子试图说?"在限定的物理U束下,我们的选择范围会大大羃?. "比如说我现在有无I多U方式从北京跑到上vQ但是如果限定只允许?升汽油,那么我们的选择p乎于0". q里q不是要说明加上物理U束之后,我们便没有Q何选择?而是说物理约束对无穷多的可能方式起了<strong>限定选择</strong>的作? 它最l造成我们在具体的物理场景下可能只有非常有限的选择. 例如现在允许?00升汽? 有多种q输方式可以满我们的要? 如果允许1000升呢? 但是如果不考虑所有物理约? 我们是否能够证明? 飞机和拖拉机的运输能力是完全一致的, 因ؓ它们都能从北京开C? <br /> <br />     我的观点是结构问题是独立存在?它具有自w的价? 研究它也需要徏立特定的价D. 一个结构可以体Cؓ语言上的某种语法特征, 也可以通过框架{实? 或者表Cؓ某种设计模式,某种~程技? 我们在思考结构问题的时候ƈ不是从特定语a的机制出发的, 当语a不直接支持的时候我们可以发展特定的实现技术支持它. 在未来的日子里某个结构可能被证明h普适的价?它会被吸收到某个通用语言中成为所有程序的支撑l构, 但是更多的结构永q都不会q入通用语言, 而是居留在某个特定的领域. 通用语言的发展ƈ不是完全Z抽象的数学分析而进行的, 它可以从更加丰富的物理世界中吸取营养. 当一U结构进入通用语言的时? 它所带来的绝对不只是一l数量关p?而是同时带来一pdl过实践验的物理诠释. <br /> <br />     我所谓的领域q不是指业务领域, 而是l构领域, 一个可以定义特定结构的物理场景. 一个特定的l构仍然可以支撑着L多的具体应用. 例如CRUD操作可以作ؓ数据理模型. BizFlow作ؓ界面和单实体的交互模?<br /> <br />     函数式语a为我们提供了一U具体的技术工? 但是在现实的开发中, Z有效的处理结构问? 昄我们需要多U视角的l合, 而不是把所有可惌的图景都U化为函? 我们对世界的体验是多样化? q就是我所?世界比函数的集合要复?的含? <br /> <img src ="http://www.tkk7.com/canonical/aggbug/166375.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.tkk7.com/canonical/" target="_blank">canonical</a> 2007-12-09 00:16 <a href="http://www.tkk7.com/canonical/archive/2007/12/09/166375.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>对语a与结构的说明http://www.tkk7.com/canonical/archive/2007/12/08/166187.htmlcanonicalcanonicalFri, 07 Dec 2007 18:51:00 GMThttp://www.tkk7.com/canonical/archive/2007/12/08/166187.htmlhttp://www.tkk7.com/canonical/comments/166187.htmlhttp://www.tkk7.com/canonical/archive/2007/12/08/166187.html#Feedback7http://www.tkk7.com/canonical/comments/commentRss/166187.htmlhttp://www.tkk7.com/canonical/services/trackbacks/166187.html    首先请不要轻易怀疑我的知识水q뀂当然如果L法聚集v_的注意力来理解别语中的细节,我也无话可说?br />    容纳他h的观点就意味着不要d自己的话语体pM试图扑ֈ反例. 一个hL受限于他的知识范_因此他也l常在自q知识范围内篡Ҏ解别人的意见。我从未说过 "一个具体的问题是现有的通用语言无法描述?. 我说的是"现实开发中所需要处理的l构问题q不是在语言层面得到充分解决?, "现在的通用语言也是无法有效承蝲Domain Specific Structure?. h意我对定语和动词的选择。其实我已经举了大量的例子来q行说明Q但可能因ؓ大多Ch不是物理背景,对相关的内容不熟悉,所以直接无视了。这也很对,W合物理学的_?br />
   可能大多Ch都知道函数式语言和命令式语言都是和图灉|{h的,因此它具有某U终极能力,怀疑它无异于怀疑我们世界存在的基础。但是请注意Q这U等h是数学性的。它潜在的要求是无限的能量和旉消耗。如果在限定的物理约束下Q我们会发现我们的选择范围会大大羃。所以我?函数式语a和命令式语言的计能力相同,但是在具体的情Ş下它们的描述能力是不同的". 比如说我现在有无I多U方式从北京跑到上vQ但是如果限定只允许?升汽油,那么我们的选择p乎于0。飞机和汽R的运输能力是相同的吗。物理学的一个基本精在于一U物理性的U束是始l存在的。而事实上Q我们在实际工作中也L在各U有限的物理条g下工作?br />
   也许有些U区分是无关紧要的,我们只关心某U终极的东西。但是物理学中有着太多的例证,说明在有限约束下Q整个系l呈现出完全不同的性质。在通信领域我们都知道Shannon定理Q它的物理诠释是在有噪声的信道上可以有效的进?strong>准确的信息传递。但是这一诠释只能在有限的数学_ֺQ远大于我们实际需求的_ֺQ上成立, 在绝对准的数学意义上,q是不可能的事情?br />
   你觉得现在的通用语言做v领域相关的东西来很方便吗Q这是我所谓无法有效承载的含义。在q里我也没有否认"未来的牛语言可以L搞定目前N"的可能性?br />
   因ؓ所有的软g设计最l都要落实到某种代码实现上,所以怎么会有什么神U的软gl构是现有的语言无法描述的呢。但是ErLang中U高q发Q支持错误恢复的E序l构是在其他语言中能够轻村֮现的吗。很多h不是在潜意识中认为ErLang的成功是函数式语a排他性的成功吗,不是认ؓ命o式语a无论如何实现不了ErLang的程序结构的吗。很昄Q在命o式语a中是无法直接实现ErLang中的E序l构的,否则它就变成了函数式语言Q但是所有发生在ErLang世界中的事实都一样可以发生在命o式语a的世界中。ErLang语言的编译器可以是用命令式语言实现的,在终极的意义上,语言之间能有什么区别呢Q?br />
   我说"实际上现在的通用语言也是无法有效承蝲Domain Specific Structure?, q还有另一层含义。通用语言设计L要考虑到内|结构的某种通用性,设计时能够凭依的信息较少Q因此不可能直接刉某U复杂的领域相关的结构。而目前已知的通用语言中提供的l构抽象的手D也不够强大Q实际上我认ZQ何语a都不会强大到内置所有结构,也无法提供所有的l构抽象手段Q, 相当于是把领域结构问题推l程序员解决。这如同C语言把内存管理推l程序员解决一栗现在ruby比较行不就是因为它能够动态处理很多结构问题吗Q但是它现在所作的一切就是够的了吗。难道二十年之后再来看这个语aQ不能够发现它存在着巨大的改q空间吗。我们目前在Witrix中通过tpl模板语言Qbizflow extends{机Ӟl合整体框架设计实现了一些与ruby不同的结构构造方法。这些手D都极大的增Z我们面对领域问题时的信心Q也保了我们的领域知识是技术层面上可积累的。但是即使这P我对E序发展的现状就是满意的吗?N不存在更加丰富的l构知识{待我们d现吗Q一般hL习惯接受已经存在的现实,在有限的职业生中把它们当作不变的真理,却没有耐心的去思考如何去改变?br />
  我认为很多结构问题不是需要在语言层面得到解决的,而是应该在独立的l构层(q_Q框Ӟq行解决。这意味着没有必要在语a层面直接内置某种特定的结构,内置某种特定的结构抽象手Dc这基本cM于说不要把集合论扩大到包含所有的数学关系Q请在别的学U分支中q行研究。需要注意的是,我所谓的领域知识不是特定的业务知识,而是从业务知识中可以分析得到的某U更加通用的普适的l构知识Q甚x可以使用数学q行_描述的?br />
  C软g发展的时间还很短Q与数学和物理学q样深刻的学U相比,它无疑是相对q稚的,是待成长的,是更加的不完的。在E序构徏的基本问题上q没有抽象出什么可以实际操作的_规律。这是所谓Pattern在Y件业行的部分原因:我们希望用这U半形式化的方式捕获某种思考的l果。但是Y件真的除了基于抽象数学的全局的全U性的证明之外Q不能够在局部进行某U更加复杂,更加严}的分析吗?br />
   我们说结构问题是独立的,q也意味着它和具体的实现语ah某种意义上的分离性。通过一U语a书写的结构可以在另一U语a中得到表达。我们可以徏立语a中立的技术结构。一U所谓的l构在概念上h某种定的Ş态,我们可以q具体的语a来理解它。例如我?面向对象的承关pMl构观点上看是两个一l集合之间的覆盖关系". 在java中我们可以直接用语a提供的承机Ӟ而在C语言中我们就需要徏立某U结构体Q手动维持所有的指针兌。而在Witrixq_中,我们从承的l构诠释出发Q定义了更加复杂的extends子Q这需要利用java语言~制特定的parser来实C。但是显Ӟ在思考的时候我们所有的思维指向是结构本w,而不是Q何通用语言的语法?br />
   在物理学中,通过摄动分析我们可以清楚地意识到Q同样一个物理现象对应的数学模型可以是众多的Q但是在特定的参数区我们会选择某种特定的数学表qͼq确定其中的待定参数?br />
   delta函数是物理学家狄拉克引入的,在Schwatz引入分布概念建立q义函数Z前,物理学家们已l用这一函数工作了很多年。后来Abraham Robinsen利用数理逻辑ҎQ徏立了非标准分析,通过模型论的Ҏ_定义了无I小的概念,从更加直接的角度了delta的合理性。但是在物理学家看来Q这些数学又有什么区别呢Q物理学只是按照物理的诠释进行工作,具体的数学只是它可选的工具而已?br />
   物理的真理ƈ不是蕴含在数学中的,它需要我们独立的探烦Q从与数学不同的观点q行思考,验,最l我们才能做出真正的发现。广义相对论可以采用Riemman几何q行描述Q但是它的物理诠释却是Einstein提出? 没有Riemann或者Hilbert发现了广义相对论。另外一斚wQ因为Einstein的工作触发了对于微分几何的更加深入的研究Q靠着物理直觉的导引,我们这一数学分支推进C难以惌的深度?数学是无法涵盖物理学?. q不是说最l物理学无法采用数学语言q行描述Q而是说在q一发展q程中,所有思想的推动来源于物理学的l验Q来源于我们在这个物质世界上所q行的反复验证。不是在一个封闭的屋中,整天摆弄各种数学W号Q我们就能够发明所有的物理公式所对应的数学。实际上Q现在学术界普遍承认Q没有物理学的推q,很多数学的进展是不可能发生的?br />
   物理pL天都在演着Feynman路径U分, 但是所有h都知道这是没有什么严格的数学依据?目前q无法定义\径积分的收敛?但是所有hҎ避而不? 只要形式演算合法,物理预测W合实验, 合理性的证明只是数学家们的事? 在量子场Z所采用的重整化(Renormalization)Ҏ不过是回避无I大问题的一UŞ式手D?我们仍然无法在数学层面对所有的演算都给予合理化解释. 在更多的物理分支中工作,你就会发现物理学家的胆子不是一般的大。也许在未来我们能够发现q些物理q程背后数学机制的精定? 但也许最l我们也无法扑ֈ合适的定义方式. 但这对物理学家来? q不是很大的打击.因ؓ指引我们的是物理直觉Q是独立于数学的物质世界的意象?br />
   我所惌论的不是某种l极意义上的可能性,不是l对概念之间的冲H,而是在物理现实的U束下,我们如何才能有效工作的问题。我已经反复表述了自q观点: "l构是可抽象的,是具有独立意义的。这是Witrix所提出的面向结构的设计视角。不是强调对象的所谓业务含义,不是某种通用语言Q例如rubyQ的灉|的语法结构。在q之间存在着厚重的具有物理意义的可以q行l构分析的技术层". 也许有h觉得我说的这是废? 但是当系l化的执行一U思想的时?׃揭示出未预料到的可能? 整个Witrixq_单的说v来就?面向l构的列分?/strong>", 但是如何扑ֈ合适的技术Ş式来体现q一思想,却绝对不是一件^凡的事情. "在Witrix中我们实现的代码重用E度和程序整体结构控制能力是越了目前所有已知的公开技术的。这不是什么哲学,而是我们在残L商业竞争中得以生存的资本".http://canonical.javaeye.com/blog/126467

   在我看来Q计机领域充斥着U数学的深沉遐想和从工程实践而来的轻d识,q没有注意到物理学所能带来的不同的同hȝ视角。我常说Q好好学习物理是必要的,因ؓq个世界q比你想象的要复杂的多?br />



canonical 2007-12-08 02:51 发表评论
]]>
关于函数式语a的一些说?/title><link>http://www.tkk7.com/canonical/archive/2007/12/06/165900.html</link><dc:creator>canonical</dc:creator><author>canonical</author><pubDate>Thu, 06 Dec 2007 14:12:00 GMT</pubDate><guid>http://www.tkk7.com/canonical/archive/2007/12/06/165900.html</guid><wfw:comment>http://www.tkk7.com/canonical/comments/165900.html</wfw:comment><comments>http://www.tkk7.com/canonical/archive/2007/12/06/165900.html#Feedback</comments><slash:comments>1</slash:comments><wfw:commentRss>http://www.tkk7.com/canonical/comments/commentRss/165900.html</wfw:commentRss><trackback:ping>http://www.tkk7.com/canonical/services/trackbacks/165900.html</trackback:ping><description><![CDATA[    我的观点q不是什么具体的E序l构问题不能用函数式语言处理.我所要表q的是这和函数式语言中能否加入结构解决Q意复杂问题无兟뀂ؓ什么所有的问题不能在集合论中解冻IZ么要有独立的数学学科。物理学所有的定律都用数学表qͼ是否意味着物理学的真理蕴含在数学之中?br />     我说<strong>?/strong><strong>际上现在的通用语言也是无法有效承蝲Domain Specific Structure?/strong><em><strong>?/strong></em>其实与以下说法是cM?br /> <strong>数学是无法涵盖物理学的,现在的已知的数学工具是无法有效承载尚未得到充分探索的领域的物理的</strong><br />     我说<strong>我所兛_的不是语a层面的问?/strong><em><strong>?/strong></em>q类g?strong>不要把所有物理问题都推到数学层面去解?/strong>?br />     我们应该研究独立的结构,应该建立单独的hD和方法论。不要谈及一个技术进展的时候就说某某语a好,不是一说到DSL的优点就要去抱ruby的大ѝ此外,我的观点也不是去做业务分析,不是d何更好的实现业务到基技术结构的映射?br />     <strong>不是对象的所谓业务含义,不是某种通用语言Q例如rubyQ的灉|的语法结构。在q之间存在着厚重的具有物理意义的可以q行l构分析的技术层?/strong><br />     我想说这个结构层面现在ƈ未得到充分的xQ我们对于结构的问题q不是非常清楚,对程序结构的E_性更是少有经验。我们在Witrix中做了大量的工作Q试囑ց到如下的图景Q?br />    <strong>永远只写代码片断Q而所有的代码片断l合在一起又构成一个可理解的整?/strong><br />    <strong>对背景不是分解让其成为可见的部分Q而是采用q加的,增删的方法对背景l构q行修正Q则我们有可能在没有完整背景知识的情况下Q独立的理解局部变化的l构。即背景是透明的,知识成ؓ局部的?/strong><br /> <a >http://canonical.javaeye.com/blog/126467</a><br />     在Witrix中我们实现的代码重用E度和程序整体结构控制能力是越了目前所有已知的公开技术的。这不是什么哲学,而是我们在残L商业竞争中得以生存的资本?br /> <br /> 号外Q?br />   不要把具体的技术和一U技术思想混ؓ一谈。一U实现L包容了太多的思想。思想错了Q实现对了。实现死了,思想zȝ?br /> <img src ="http://www.tkk7.com/canonical/aggbug/165900.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.tkk7.com/canonical/" target="_blank">canonical</a> 2007-12-06 22:12 <a href="http://www.tkk7.com/canonical/archive/2007/12/06/165900.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>关于函数式语a的只a片语http://www.tkk7.com/canonical/archive/2007/12/05/165664.htmlcanonicalcanonicalWed, 05 Dec 2007 14:09:00 GMThttp://www.tkk7.com/canonical/archive/2007/12/05/165664.htmlhttp://www.tkk7.com/canonical/comments/165664.htmlhttp://www.tkk7.com/canonical/archive/2007/12/05/165664.html#Feedback8http://www.tkk7.com/canonical/comments/commentRss/165664.htmlhttp://www.tkk7.com/canonical/services/trackbacks/165664.html

2. 最q这些年来一U称?范畴"(Category)的东西在计算机理论研I中频频出现。范畴论是从同调代数发展而来的一U较新的代数语言Q但它显然也不是可以解决M问题的灵丹妙药。多一U表达方式当然在某种E度上可以增q我们的理解。但是范畴本w只是研I一U基l构Q它本nq没有承载所有的物理事实Q基于它不可能对所有的规律一|打。不是明白了范畴Q就懂了E序。范畴论是一U基性的语言Q有些h致力于基于范畴论来构建数学的其他分支Q取代集合论的地位。将计算的本质重新归l于范畴论是无意义的Q它不过是对事实的另一U陈q方式。说“函数式语a是基于范?#8221;是无意义的,因ؓq和?#8220;所有现代数学都Z集合?#8221;一栗无法发现新的相互作用关p,所有的概念都只是同义反复。不是一拿v数学Q就扑ֈ了组l?br />
3. 我对函数式语aq没有什么反Ҏ见。它是非帔R要也非常优美的一U技术思想。但是现在一些函数式语言的狂热支持者似乎对函数世界充满了乌托邦式的qLQ一U大一l的世界观让醉,但是它却解决不了现实的问题。所以我说无法认同函数式~程的世界观。作ZU具体的技术工P问题不在于函数式语言是否体现了计的本质Q而在于它是否向我们提供了U手的兵器。现在我要计两个小球相互碰撞的问题Q我可以操vq义相对论,量子力学啥的开始大q一场,也可以用个牛力学小试牛刀Q甚臛_以只用反关pL个等式。但是在l大多数情况下我们都会说q里面的物理是弹性反而不是相对论。在理论分析中我们经怋用^面L假设Q但只要实际兛_的对象不在L包的边缘Q没有h会认为^面L不是真实的物理机制。理论物理不是理想物理。在具体的参数设定下Q我们只会用特定的物理学?br />    对世界的认识q不是非此即彼的。ƈ不是说函数式语言好它永q都好,要把所有对立面都灭掉。也不是说函数式不好Q命令式必然的好,必然的能够解决问题。函数式语言的世界观q分单纯而排他,q是我反对的Q我同样无法认同面向对象的本体论。就像CISC和RISC架构之争一P最l我们在现实的物理约束下Q运行的最好的芯片是两者思想的结合。这是我们面对物理世界的基本态度?br />   
4. 函数式语a中时间是个有的概念。命令式语言中因D句的存在Q得我们可以观到状态的变化Q因此必然要定义旉。而函数式语言是无状态的Q可以是无时间概念(对Lazy Caculation的依赖是否体C深层ơ上Ҏ间概늚需求?Q。有些h认ؓ函数可以看作是相I间中的q移函数Q是与相对论协调的,因而反映了旉的本质等{。相对论主要是解决了物理规律的协变性的问题Q在此过E中它Z认识C时空之间奇异的对U性。但是广义相对论的表qC旉也是可逆的。真正定义了旉之箭的是热力学第二定律。根据Landauer's principle: 擦除(erase)1比特信息Q耗散到环境中的能量至是k*T*ln2, 或者说熵增臛_是k*ln2. q意味着只要我们对眼前的黑板不停的写了擦Q擦了写Q就必然无法回到q去。物理世界是复杂的?br />
5. 如果状态看作是可以附着在某个对象上的标讎ͼ昄状态的存在性便于我们识认概늚唯一性。对象还是那个对象,只是状态标记发生了变化。而如果系l中没有状态,则必然生了一个新的概c这在很多情况下是不必要的负担。状态的存在使得pȝ在局部结构上允许出现非常复杂的变化,函数式编E的拥趸们对此多有诟病。但是从另一个方面上_状态得我们可以基于局部信息处理很多问题而不需要把它扩大化Z个全局匚w问题?br />
6. 函数构成函数g是很完备l一的世界?但是在物理世界中发生的一切却复杂的多。虽然世界可以还原ؓ原子Q但是原子构成分子,分子构成宏观物质Ӟpȝ的基本性状发生了本质性的变化Qƈ不再是统一的Ş式。每一个层面上都会产生独立的结构规律?br />
7. 函数式语a和命令式语言的计能力相同(可以相差一个Q意长度的多项式时_Q但是在具体的情形下它们的描q能力是不同的。我所兛_的不是语a层面的问题,因ؓ语言本n的能力ƈ不以解决现实开发中的所有问题。即现实开发中所需要处理的l构问题q不是在语言层面得到充分解决的,q是我们需要做工作的地斏V?br />    关于现实中的l构问题Q我无意d义什么万能的描述能力。你可以用微分几何,U分几何Q广义变分等{手D去证明圆盘是某U意义下的周长最短的东西Q但是这一切对你发明轮子ƈ无本质上的助益。不q可以说说现实中的结构。这里不是要证明某种语言中无法描q这些结构,而是说结构是客观存在的,它ƈ不是要在基础语言层面得到充分解决的。实际上现在的通用语言也是无法有效承蝲Domain Specific Structure的?br /> A. ErLang大概是目前世界上应用最为深入的函数式语a了。它实发挥了函数式语言无显式状态变量的优势。但是它对程序构建本质上的帮助更多的来源于无׃n的超轻量U进E模型,相当于定制了一般操作系l所提供的基本服务。微软的一个实验性操作系l项目Singularity, 其中也定义了只通过消息传递发生数据关联的轻量q程模型Q它使用C#的一个扩展语aQ额外增加的功能是消息管道上定义的规格状态机Q对消息交互的时I模式进行额外的规约。这里对我们真正有h值的是隔ȝ单元l构?br /> B. AOP是程序结构空间中的定位和l装技术。在Witrix中我们规范化了切点处的状态空_q对AOPq行了偏|处?q种l构调整大大提高了AOP的可用性,使得它成为Witrix中的核心技术手D之一?br /> C. 面向对象的承关pMl构观点上看是两个一l集合之间的覆盖关系。在Witrix中扩展了extends所对应的结构操作,创造了新的l构融合手段?br />

canonical 2007-12-05 22:09 发表评论
]]>
关于[面向集合的框架设计]的一些说?/title><link>http://www.tkk7.com/canonical/archive/2007/12/03/165039.html</link><dc:creator>canonical</dc:creator><author>canonical</author><pubDate>Mon, 03 Dec 2007 15:54:00 GMT</pubDate><guid>http://www.tkk7.com/canonical/archive/2007/12/03/165039.html</guid><wfw:comment>http://www.tkk7.com/canonical/comments/165039.html</wfw:comment><comments>http://www.tkk7.com/canonical/archive/2007/12/03/165039.html#Feedback</comments><slash:comments>2</slash:comments><wfw:commentRss>http://www.tkk7.com/canonical/comments/commentRss/165039.html</wfw:commentRss><trackback:ping>http://www.tkk7.com/canonical/services/trackbacks/165039.html</trackback:ping><description><![CDATA[    我习惯于概念层的推演Q而且所阐述的东西多数是我们创造过E中的副产品Q与业内常见的观念实际上是有着很大差异的。有些h感觉我的文章M明白是因为没有采用类似的视角Q或者还没有独立思考过很多问题。如果只是从业内已经熟知的概念出发试囄解我所写的内容Q显然是不可能的事情。所以我常说know something already known. <br /> <br /> 如果在编制一个新的应用,存在大量代码可能?br /> <div style="border: 1px solid #cccccc; padding: 4px 5px 4px 4px; background-color: #eeeeee; font-size: 13px; width: 98%;"><!--<br /> <br /> Code highlighting produced by Actipro CodeHighlighter (freeware)<br /> http://www.CodeHighlighter.com/<br /> <br /> --><span style="color: #000000;">myFunc(){<br />   </span><span style="color: #0000ff;">for</span><span style="color: #000000;"> each x in set<br />     doSomethingValuable(x);<br />   </span><span style="color: #0000ff;">return</span><span style="color: #000000;"> packedResult;<br /> }<br /> <br /> myOtherFunc(packedResult){<br />   </span><span style="color: #0000ff;">for</span><span style="color: #000000;"> each y in pakedResult<br />     doSomethingOther(y)<br /> }</span></div> <br /> 其实我们真正兛_的是循环内部的某个过E,但是我们l常可以观察到它们被某些通用的或者特定的循环Q集合遍历)操作所包围着。Witrix的设计方式是业务x点,而把所有的汇L作尽量抽象完成。比如现在界面上昄一些字Dc从抽象的操作上?br /> <div style="border: 1px solid #cccccc; padding: 4px 5px 4px 4px; background-color: #eeeeee; font-size: 13px; width: 98%;"><!--<br /> <br /> Code highlighting produced by Actipro CodeHighlighter (freeware)<br /> http://www.CodeHighlighter.com/<br /> <br /> --><span style="color: #000000;">  </span><span style="color: #0000ff;">for</span><span style="color: #000000;"> each field in dsMeta.viewableFields<br />     show field.viewer</span></div> <br /> q一q程在^C码中实现Q它是一个通用的集合操作过E。不同的具体应用只是兛_具体字段的展现Ş式,虽然我们必然需要字D集合,但是它不是我们注意力的重心?br />   如果考虑到字D在界面上展C有一个布局问题Q我们所要修改的是集合内部的l构方式Q?br /> <div style="border: 1px solid #cccccc; padding: 4px 5px 4px 4px; background-color: #eeeeee; font-size: 13px; width: 98%;"><!--<br /> <br /> Code highlighting produced by Actipro CodeHighlighter (freeware)<br /> http://www.CodeHighlighter.com/<br /> <br /> --><span style="color: #000000;">  某种l构循环方式QdsMeta.字段l成的布局集合Q?br />     show field.viewer</span></div> <br /> 抽离出集合,实际上是在最大限度上分离l构问题和内定w题?nbsp;    <br />    l构是可抽象的,是具有独立意义的。这是Witrix所提出的面向结构的设计视角。不是强调对象的所谓业务含义,不是某种通用语言Q例如rubyQ的灉|的语法结构。在q之间存在着厚重的具有物理意义的可以q行l构分析的技术层?a >http://canonical.javaeye.com/blog/60758 </a> <a >http://canonical.javaeye.com/blog/126467</a><br /> <br /> <img src ="http://www.tkk7.com/canonical/aggbug/165039.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.tkk7.com/canonical/" target="_blank">canonical</a> 2007-12-03 23:54 <a href="http://www.tkk7.com/canonical/archive/2007/12/03/165039.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>从指针到引用http://www.tkk7.com/canonical/archive/2007/12/02/164717.htmlcanonicalcanonicalSun, 02 Dec 2007 14:14:00 GMThttp://www.tkk7.com/canonical/archive/2007/12/02/164717.htmlhttp://www.tkk7.com/canonical/comments/164717.htmlhttp://www.tkk7.com/canonical/archive/2007/12/02/164717.html#Feedback2http://www.tkk7.com/canonical/comments/commentRss/164717.htmlhttp://www.tkk7.com/canonical/services/trackbacks/164717.html     指针是对地址的符号化。它所带来的第一大好处是使得我们摆脱了对l对地址I间的依赖。如同NewtonW一定律所阐述的:物理规律与所发生的惯性坐标系无关。同P数字I间中发生的的事件与所处的l对地址也是无关的。在W号化的方向上更q一步,如果我们专注于指针的兌语义Q而放弃指针的指针q样的؜杂概念,׃得到h独立价值的引用(Reference)概念.
    从表面上看v来,数字I间只是一个无限g展的一l地址I间Q每一地址处只能存放一个有限大的L数|g它的几何学是贫瘠的。但是因为在软g设计中,一般是不考虑d旉的。这意味着在拥有指针的情况下,我们可以“立刻”讉K到数字空间的L遥远的地斏V这U超时空的信息传递过E得我们可以利?#8220;引用”概念L的构Z个多l的表示I间。在面向对象的技术背景下Qx.y.zq样的Ş式表C暗C着x,y,z是同时存在的。当z发生变化的时候,通过y.z和x.y的信息传|x对象本n也发生了某种变化?br />     随着web技术的行Q独立的状?地址I间的存在性逐渐成ؓpȝ不可回避的假? "同时?的物理约束越来越难以l持. 相对定了物理现象的定域? 在数字空间我们一直忽视了?但有的? |络上的传输时g却迫使我们重新发C"引用"形式下必然存在着的物理过E? 引用本n只是标记了某U信息关? q不一定意味着同时性约? q发~程领域的所谓的Future对象是对传统引用概念的一U有扩?
   result = obj.callMethod(args) ==>  future = obj.callMethod(args)
future对象可以被自׃? 只有当实际访问到它的属性的时? 才会触发时序U束. 


canonical 2007-12-02 22:14 发表评论
]]>
面向集合的框架设?/title><link>http://www.tkk7.com/canonical/archive/2007/11/25/163048.html</link><dc:creator>canonical</dc:creator><author>canonical</author><pubDate>Sun, 25 Nov 2007 15:37:00 GMT</pubDate><guid>http://www.tkk7.com/canonical/archive/2007/11/25/163048.html</guid><wfw:comment>http://www.tkk7.com/canonical/comments/163048.html</wfw:comment><comments>http://www.tkk7.com/canonical/archive/2007/11/25/163048.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.tkk7.com/canonical/comments/commentRss/163048.html</wfw:commentRss><trackback:ping>http://www.tkk7.com/canonical/services/trackbacks/163048.html</trackback:ping><description><![CDATA[    判断和@环是E序中最基本的语句结构。而在vonNeumann体系架构下,循环是对集合q行操作所需的基本步骤。一个有的事实是,函数式语a所宣称? 生力的来源很大E度上在于集合操作的便捷性。在数学中我们通过张量分析Q泛函分析等可以清楚地意识到集合之间的相互作用是可抽象的Q是可以独立理解的, x们可以在不涉及具体基元结构的层面上独立的定义q执行集合运。如何将q种概念独立性在框架层面展开是一个非常深ȝ命题?br />     在基元结构上应用基础操作p(d)q一微观场景一般情况下是容易理解ƈ实现? 但通常E序中所定义的大量边界是Z集合变量? 因此很多代码都是包和解包操? 在层层嵌套的循环l构深处我们才能发现真正h业务价值的基元l构. 集合操作提升到pȝ层,减少或简化在应用层需要显式编制的循环l构是框架设计层面需要考虑的问? <br />     一个最基本的方法是量定义通用的同构操? 避免构造中间集? 例如前后C间通过json{通用协议交换复杂l构的对? 避免定义Ҏ的中间处理过E? 一个与之相配合的重要技术手D|通过cL询语?描述方式)直接构造特定的集合. 例如prototype.js中提供的$$('div div.myclass').each(op)q样的处理方式显然要比在循环q程中基于特定条件过滤要方便的多. 而在AOP操作中切点的集合定义方式也是其提供的核心价g一. 与集合操作相适应的一U代码风格是式设计(stream), q正是jQuery试图鼓吹的主要h?虽然我个为它有些走极?. 式设计的核心结构实际上?x += dx, 它不需要集合是一ơ性构造的, 便于支持一U逐步部分修正的概忉|? <br />     Z支持集合的隐式构? 我们需要以通用的方式定义元素到集合的组装规? 在Witrixq_的前台js框架中我们定义了q立的htmllg到复合查询条件的拼接规则, 定义了由每个htmllg的数据校验函数到整个form的数据校验函C间的l装规则, 定义了由单个htmllg提交参数到整个form提交参数之间的组装规? 在Witrixq_的标准界面上, 框架本n的编制基于js.query.buildCondition(frmQuery), js.validate.validateForm(frmUpdate), ajax.addForm(frmUpdate){少量集合操作进? 在不同的应用场景? 我们只需要关心每一个字D如何显C? 提交哪些属? 而由pȝ负责它们自动组装ƈ在后台进行分z? 面向不同的应? 框架代码不需要做ZQ何修? 保了系l结构的可重用? <br />    Witrixq_的后台处理模型中定义了实体化q程, DaoWebActionZCRUD{原子操作定义了扚w提交, 数据导入导出{复合的甚至是嵌套的集合操作. 在不同的应用? 我们通过修改bizflow文g?lt;action id="ViewDetail-default">, <action id="Update-default">{针对单实体的业务规则即可适应不同的业务场? 而不需要ؓ特定的应用重复编刉合处理过E? <br />     面向集合+通用l装规则是Witrixq_设计中采用的基本设计手法之一, 它得我们在一般应用中只需要考虑单实?单字D늭基元l构上发生的特定业务, 大大化了pȝ构造过E? 但是也需要认识到从个体到集合的扩?p(d) -> P(D) )是非q_? 集合比个体的单加和要更多, 为此架构中需要保留对集合边界的识别能? 例如需要允许在数据导入完成之后执行特定的业务规则而不是仅仅针Ҏ一数据行执行业务规? <img src ="http://www.tkk7.com/canonical/aggbug/163048.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.tkk7.com/canonical/" target="_blank">canonical</a> 2007-11-25 23:37 <a href="http://www.tkk7.com/canonical/archive/2007/11/25/163048.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>Witrix架构分析http://www.tkk7.com/canonical/archive/2007/09/23/147641.htmlcanonicalcanonicalSun, 23 Sep 2007 15:53:00 GMThttp://www.tkk7.com/canonical/archive/2007/09/23/147641.htmlhttp://www.tkk7.com/canonical/comments/147641.htmlhttp://www.tkk7.com/canonical/archive/2007/09/23/147641.html#Feedback0http://www.tkk7.com/canonical/comments/commentRss/147641.htmlhttp://www.tkk7.com/canonical/services/trackbacks/147641.htmlhttp://canonical.javaeye.com/blog/33824
 

Witrix架构??字Ş态,其中定义了三条主要的分界U?
1. 览器和服务器之间通过语义l构明晰的URL形成两分l构?a _fcksavedurl="http://canonical.javaeye.com/blog/99122">http://canonical.javaeye.com/blog/99122
2. pȝ前台臛_台存在一条预制的非R入的信道. 它维持了一U无害的可扩展结? 具体的说,pȝ从前台js到后台处?对于所?为前~的参数是自动传递的,没有识别出的层将自动把这些参C递下?pȝ通过q一信道实现退化过E。在 我以前的文章中曾l指Q?每一U可退化Ş式都对应存在一U非侵入性的可扩展设计?a _fcksavedurl="http://canonical.blogdriver.com/canonical/993807.html">http://canonical.blogdriver.com/canonical/993807.html
3. Witrix内置了对于CRUD模型的支持, 而BizFlow通过cMAOP的方法对CRUD模型q行了扩展。这使得Witrix的模型驱动部分ƈ不是仅仅针对单表或者单实体的维? 而是可以实现特定的业务逻辑和CRUD逻辑的؜?

    q三条分界线分别规范了基状态空_对已有知识的重用以及面向未来的可扩展性。在q种大的宏观l构下,Witrix应用了如下技术手D?
1. 对象化。Witrix中的Jsplet框架以对象的名义提供了对后台的状态和行ؓI间q行分解的基手段?http://canonical.javaeye.com/blog/33873。Witrix 依托于Jsplet对象实现相关性的局域化, 而不需要像一般面向action的框枉L接访问http sessionq一全局状态空? 前台发送的objectName参数同时在系l的不同层面标定了WebAction响应函数, Biz配置, DataSourceMeta元数? Hibernate实体{一pd相关概念, 使得它们构成一个统一的整?
2. 标准化。与REST架构风格cMQDaoWebAction规范化了后台响应事g。DaoWebAction上支持的标准事g有Query, ViewDetail,Add, Update, Remove{? 它们构成一个完整的CRUD模型。与REST不同的是QDaoWebAction提供了一个空的响应事件BizAction。它相当于是CRUD模型中的 零元操作。在BizFlow模型下,它将被扩展ؓ一个操作子I间Q从而实现对于CRUD模型的超。而在REST模型下所有的扩展操作必须依附于一个已l? h固定语义的Method上,例如POST. http://canonical.javaeye.com/blog/99122
3. 实体化。在Witrix中充分发掘了ORM技术的能力, 使得单一业务对象上可以聚集到某一范围内的所有相关结构信? http://canonical.javaeye.com/blog/111500. 同时在DaoWebAction中通过EntityFilter机制实现了单实体化过E? q意味着前台应用可以一ơ性提交多个批量操? 后台框架负责把它们分解ؓ针对单个实体的一ơ确定性操? 在后台实现时只需要考虑单实体的情况卛_. 一个简单的例子是前台提交objectEvent=Remove&id=1&id=2&id=3 , WebAction层会为每一个id对应的实体调用BizFlow中的Remove-default操作. 实体化是一个非帔R要的q程, 它我们x的核心成为单实体, 正是因ؓ明确了单实体作ؓ基本的关注点, 我们才可以徏立更加复杂的状态机机制, 驱动pȝ状态变?
4. lg? 前台的tpl模板和后台的WebAction׃n一个thisObj指针, l合自定义标{机? 资源(js/css{?理机制{构成可以重用的lgl构.
5. 偏置的AOP. BizFlow通过一U类gAOP的操作对DaoWebAction提供的CRUD模型q行扩展, 使得模型的能力得到本质性的扩张. q种AOP操作与通常意义的AOP的区别在? ~省行ؓ在默认情况下发生, 除非昑ּ止. 通过q种方式, 反{了base和extension之间的主体地? 此外BizFlow所提供的不仅仅是行为的扩展,它同时提供了对界面的描述. 在前台tpl面中通过<ds:BizViewOps/>{无参数的标{调用来定义嵌入坐标. http://canonical.javaeye.com/blog/34941


     与传l的J2EE相比? Witrix表现出很多变?
1. 不用全局的session, 而是使用局域化的thisObj
2. 不定义service层,其功能分解到BizFlow和Handler中,它们都不负责日常的DAO操作。独立的MDA部分负责所有的实体CRUD(Create Read Update Delete)操作?br /> 3. 不定义页面蟩转规则,在前C用拉模式直接表明跌{目标。结合前台stdPage对象在前台控制蟩转目标。ƈ可以在BizFlow中配|覆盖的规则Q这样就可以针对不同的应用场景定义不同的跌{规则?br /> 4. 不是为每个模? 每个应用场景~制一l新的页?而是大多数模块共用少数几个标准页?
5. 不在与网l无关的service层上定义权限和事务管理。Witrix架构下通过URL明确区分了系l内部和外部, 前台讉K后台时调用者的全部意图是以规范化的形式表达在url中的. 因此权限和事务管理作用在WebObject上在概念上也可以认ؓ是约束直接作用在URL? q与REST风格是统一? 当然我们也可以规范serviceҎ的命名等, 但是昄要求一U随意性消失是有代L, 在URL上我们已l付Z代h,Z么要在service上再付出一? Witrix中Transaction和Auth的配|更加直? 因ؓ规范化了WebObject上的事g响应函数,一般我们也不需要进行特D的配置. Witrixq种设计更加适合于网l这一两分l构的,更加充分的利用这一架构边界所提供的隔L?
6. 不在面中用实体的字段名,而是大量通过元数据表辄序意图?a _fcksavedurl="http://canonical.javaeye.com/blog/114066">http://canonical.javaeye.com/blog/114066

   一般J2EE多层架构下,所谓的架构分解主要是对E序U向的分解,但是E序l构斚w是没有横向分解的。而witrix架构的一个核心就是横向存在着 CRUD模型和Biz的分解。在pȝ的所有实现过E中Q所有CRUD操作都剥dMDA模型中,而不需要Q何代码编制。典型的, witrix后台代码一般写在handler中,命名为handler而不是service是因为handler中负责的内容和j2ee传统上的 service有所不同Q一般serviceL要负责某个实体的CRUD操作Q大量的findxxx代码。一般提倡的最佛_跉|实现某个通用的基c,所 有service都承该基类获得CRUD能力。但是在Witrix架构中,Ҏ没有q一需要。Handler只要完成自己特定的功能,它不q求操作概念 在其本n的完整性。没有CRUD, handler没有意义。但是handler之所以有意义是因为它提供了CRUD之外的操作。当CRUD成ؓpȝ一U自动进行的背景操作Ӟ我们不再需? 明确意识到它的存在?br />     我们需要认识到我们最l所需要的东西可能不是规整l构? 它可能要求对于某个规整结构进行剪裁ƈ增补附加元素. 但是q样的规整结构不应只存在于我们的惌之中Q相应的剪裁q程应该是可以增量进? 反复q行? 在Witrixq_中, 基本的一U图景变化是: Witrix中不再需要从头开始构造结? 而只要指定当前业务和背景模型之间的差异部? 在Witrix中所写的业务代码是对核心模型的扩展。这不仅仅是概念上的Q而是实际体系架构上精的体现。CRUD作ؓ独立的模型吸收了pȝ中大量的? 化。整个模型内核是采用通用方式借助meta实现功能Qƈ不涉及到特定于业务的cR对于那些我们已l掌握的知识, Witrix提供了超对象?AOP和组仉用的l构抽取手段, 使得知识可以ExU篏.
      数学中存在两U基本的分解方式Q?一U是加性分?(a,b) + (c, d) => (a,b,c,d)Q?另一U是乘性分? (a,b) X (c, d) => (ac,bc,ad,bd)Q?它也对应于张?Tensor)q算. 在群?Group Theory)中,直积对于复杂性的化简臛_重要Q它的重要性要q在加和之上。实际上AOP操作cM于直U分解, 只是它的能力未得到充分的探索? 在Witrix中,biz的作用在感觉上很象是陪集(coset)q算QCURD * biz。不同的biz作用到同LCRUD模型上生不同的操作集合Q而所有bizl成的集合构成独立的整体?nbsp;  
      Witrixq_中作为内核的MDA部分首先是物理模型驱? 而不是逻辑模型或者对象模型驱? 我们通过在物理模型上标注的方法恢复部分对象模型的信息, 但是我们q不试图把整个Y件徏立ؓ模型. 所建立的仅仅是整个E序模型的内? http://canonical.javaeye.com/blog/29412 一般业内鼓吹的所谓MDA成功的关键是要提高抽象层ơ? 但是陪集是更抽象吗?正规子群更抽象吗?它们只是pȝ的指标性表征,使对信息的distill, 是更Ҏ理解的一个侧面而已, 抽象性ƈ不是一个真正的目标。很多时候我们需要的是把pȝ降维到某个子I间中,形成一U可控性?但是q个子空间ƈ不一定是更抽象的?br />       作为基本的代数p,一个本质特征是h逆元。Witrix的MDA中明定义了逆元l构Q即界面上的元素 empty = buttonA + (-buttonA)Q这一分解公式应用到后?OpA = Update * (-Update)  * OpA。假设我们已l徏立了l构X, 现在需要徏立一个与X略有不同的结构Y
       X = a + b + c
       Y = a + d + c = (a + b + c) - b + d = X - b + d
虽然Y的两U构造方式在数学上是{h的, 但在物理上ƈ不等仗第一U方式对原有pȝq行分解后再l装Q而第二种方式没有打破原有的东西,不需要拆分。拆分L可能存在问题的,正如你把所有电脑零 件拆装下来再装上很可能会发现多出几个零g。一般情况下W二U方式的构徏成本要低. 特别是当一切都U缠在一L时? 一U细_度的逆元l构对于一U试N用的l构是非常关键的. 可重用性的障碍不仅仅是来自于无法追加新的功能,很多时候也在于无法屏蔽原先已经提供的功能。目前所有的设计原则都未能适时识别出逆元的重要性。所有的? 计教条其实所指的方向都是加和, 如何分解出更的l元, 如何把它们加和在一? 如何从细部开始进行重新构? 而不是说依赖于现有已lŞ成的宏观l构, 如何q行l粒度的调整. 所谓的AOP技术思考的关键点也在于如何l系l增加功? 很少有h惛_场景是ؓpȝ减少功能q把q种概念大规模正式应用的, 虽然说AOP已经在某U程度上h了这U能? 但是真正应用它仍焉要对AOPq行q一步的诠释. 当然Q现在的软g业连基本l构的构造问题都没有完全搞清? 更别提所谓结构稳定性的问题?
     从物理上_Y = X - b + d的分解方式具有特D的意味。如果没有逆元Q我们必焉要分解。但是如果发掘了背景q一概念Q在逆元q算下,对背景不是分解让其成为可见的部分Q而是采用 q加的,增删的方法对背景l构q行修正Q则我们有可能在没有完整背景知识的情况下Q独立的理解局部变化的l构。即背景是透明的,知识成ؓ局部的?      
    Witrix试图提供的一U图景是永远只写代码片断Q而所有的代码片断l合在一起又构成一个可理解的整体。这个整体可以独立理解,不需要额外的l构元素? Witrix架构所q求的是在不完全信息下徏模,不进行整体徏模。整体模?+ 不断变化的局部修?构成 最l模型。^台技术的目标是让一切应该发生的自动发生Q让一切不该发生的无法发生。这一模型的构建ƈ不是trivial的,在概念和实现斚w都要作出很多 的努力?br />      
题外Q?br />      今天中午参加同学的婚C? 席间和一个与同方有些渊源的同学谈到ezOne的现? 大致的评语是: 垃圾, 自己Z不用. 听来也让人有些感? 中国原创的技术Lƺ骗的代名词,  q一断言不应L得到证实.


canonical 2007-09-23 23:53 发表评论
]]>
վ֩ģ壺 Ʒ޳aƬ߹ۿٸ | 99ƷƵۿ| ˾޾ƷӰԺ| Ƶ| ŮƵվ| Ʒ޹AVƬý| ҳƵ߹ۿ | Ƶһ| Ļۺ| þҹ³Ƭ| պһ| ѹƵ| һƵ| 91۲޾Ʒ| ҹɫһ| һ | ˳Ƭ߹ۿ| þþþƵ| ۺϾƷ㽶þ| þþƷ˽ӰԺѿ| ޾ƷAAƬ| ޾Ʒר߹ۿ| 59paoɹƵ | Ů͵޾Ʒ| ɫ͵С˵| Ʒ㽶߹ۿ| 99þۺϾƷ| ޹þ| Ѹavһ| 13СϴƵվ| ޳˻ɫ| ޾ƷAAƬѽ| պѸƵ| fc2˳| ۺƵ| ھƷ뿨123| ͵Ƶ߹ۿ99| һëƬѹۿ| ۺϹһ| ֳִִӲƵ | һƷƵ|