|
|
| http://bbs.nju.edu.cn/blogdoc?userid=nexttime |
| # posted by nexttime @ 2005-04-27 23:35 评论(0) |
|
 |
 |
有很多时候我们会感动：被曲折爱情、被传奇的经历、等等
终于我发现一个真理，哈哈，就是人都是被自己没做到（或难做到）的事情感动 |
| # posted by nexttime @ 2005-04-19 02:06 评论(0) |
|
|
|
2004年4月，徐本禹回到母校华中农大做了一场报告。第一句话是：“我很孤独，很寂寞，内心十分痛苦，有几次在深夜醒来，泪水打湿了枕头，我快坚持不住了……”本来以为会听到豪言壮语的学生们惊呆了，沉默了，许多人的眼泪夺眶而出。
回看了一下当初的帖子，这段真是TMD说得太煽情了，看得我还是哽咽了一下 |
| # posted by nexttime @ 2005-04-11 00:34 评论(0) |
|
|
|
唉，可不可以再过几年转正阿，ft |
| # posted by nexttime @ 2005-04-09 22:30 评论(2) |
|
|
|
 |
|
 |
发信人: robaggio (Knock knock knockin' on heaven's door), 信区: SoftEng
标 题: AOP及其Java实现机制
发信站: 哈工大紫丁香 (Wed Mar 30 03:19:52 2005), 转信
1引言
传统的编程技术，采用分解的方式将一个软件系统划分为相对较小的、易于分析、理解的模块，如果这些模块仍难以分析、理解，则迭代的将其分解为更小的模块，直到这些模块可以容易的分析、理解、设计与编码。通过对这些模块进行分析，设计，然后使用相应的编程语言实现这些模块，再以编程语言所定义的方式将这些模块组装起来，形成最终的软件系统。例如，面向过程编程中，将系统分解为完成单一功能的函数，并通过函数之间的调用完成复杂的功能，最终形成这个系统。面向对象编程中，通过分析，抽象出一系列具有一定属性与行为的对象，并通过这些对象之间的协作完成系统的功能。
传统的编程技术倾向于按照功能或行为对软件系统进行分割，这个分割的结果是实现某一功能的模块，如函数、过程、类等。但在编程实践中，人们认识到，软件系统中有些行为无法封装在单个的模块中，例如日志记录、事物处理、对上下文敏感的错误处理、性能优化等等。通常这些功能与行为不实现系统的业务功能，但辅助这些功能的实现，并散布在实现系统功能的诸多模块中，从而造成代码的纠结，这使得实现系统功能的模块的代码难于阅读、理解、调试、维护和扩展等，并使得纠结的代码难于复用。如果我们将实现系统业务功能的模块看作系统的纵向分解单元，那么上述分散在功能模块中的功能与行为就形成了一种横向的方面（Aspect），方面与模块形成了横切（Crosscutting），从而造成传统的编程技术无法将方面模块化，造成两种代码纠结（Tangling）在一起。
因此，我们需要一种新的编程思想，对系统中的横切方面进行处理，解决由此造成的代码纠结问题，并使方面可模块化，促进功能模块与方面彼此的复用。
2 AOP简介
面向方面编程（Aspect-Oriented Programming，AOP）就是这样一种区别于传统编程技术的新的编程思想，最初由Gregor Kiczales在施乐的Palo Alto研究中心领导的一个研究小组于1997年提出。AOP正是基于方面与模块形成横切，造成代码纠结这一观察提出的，并提出了一种新的编程思路来解决这一问题。之后，AOP经由几个不同小组的努力在各自的方向上得到了发展，到目前为止，AOP仍处于发展阶段。
2.1 AOP的基本思想
如前所述，造成代码纠结的原因在于传统编程技术中，软件系统中非业务功能实现的代码无法模块化，散布在实现业务功能的代码中造成的。这里，我们引入关注点（Concern）的概念，关注点就是软件系统中需要解决的问题。软件系统的业务功能组成了核心关注点（Core Concerns），也就是软件系统要解决的问题，而诸如日志记录，事物处理等关注点就形成了横切关注点（Crosscutting Concerns），因为，这些关注点散布在核心关注点中，相互形成了横切的关系，横切关注点也就是前面提到的方面这一概念。
有鉴于此，AOP提出的解决方法是对这两种相互横切的关注点分别进行编码，使用传统的编程语言对核心关注点编程，使用面向方面的编程语言对横切关注点，也就是方面进行编程。然后使用一种机制将这两种代码自动混合起来，形成最终的代码。在这里，面向方面的编程语言可以是已有编程语言的扩展（AspectJ，AspectC++，AspectC，AspectC#，Apostle等），或是一种新的语言，设计用于编写方面的代码（Caesar，D2AL，JasCo等）。而将两种代码混合的机制称为织入（Weaving），实现这一机制的工具称为织入器（Weaver）。因此，对方面单独编码，并通过适当的织入机制使两种代码混合，构成了AOP解决代码纠结问题的基石。
2.2 织入机制
如前所述，织入是实现AOP的一个重要机制，织入的实现机制有多种，基本上可以分为两类，静态织入与动态织入。静态织入是指在业务功能代码中的适当位置，比如某段代码执行前，或执行后，将方面中的编码插入，从而形成混合的编码。方面中的编码在程序运行前，已被内联至业务功能代码中，因此，代码可以被优化，从而使织入产生的开销最小化，最终产生的混合代码，其执行速度接近为使用AOP方式编写的代码。但是，静态织入无法做到在程序运行时，根据运行上下文动态的决定插入的方面代码，动态织入则可以做到这一点。动态织入可以在程序运行时，根据上下文决定调用的方面，它们的先后顺序，增加或删除一个方面等。
而根据织入的时间，又可以分为三类，编译时，载入时，运行时。编译时织入可以在编译前进行预处理，将两种代码自动混合，将方面中的代码自动插入到功能模块代码的合适位置处，也可在编译后，对编译后的代码进行操作。载入时织入是在代码载入时，实现代码的织入。运行时织入则在运行时，根据对方法的调用执行适当的方面代码以实现织入。
以AOP的Java实现为例，包括使用反射（Reflection），基于动态代理（Dynamic Proxy）或其它机制的拦截框架，基于元数据（Metadata）的操作，以及类载入时对字节码的操作等。随着AOP应用的进一步推广，相信会有更多新的织入方式出现。
3 AOP实现机制
根据来自于AOSD（Aspect-Oriented Software Development，http://aosd.net）的统计，目前与AOP相关的项目已达近百种，而基于Java的AOP实现机制也有二十多种，以下所列举的是商业上得到成熟应用的几种基于Java的AOP的实现机制。
3.1 AspectJ
AspectJ是目前最完善的AOP语言，由AOP的首倡者Gregor Kiczales领导的一个小组提出并得到发展。AspectJ是对Java编程语言的扩展，通过增加了一些新的构造块支持对横切关注点的模块化封装，通过对源代码级别的代码混合实现织入，是一种典型的使用静态织入的AOP实现机制。AspectJ提供了两种横切实现机制，一种称为动态横切（Dynamic Crosscutting），另一种称为静态横切（Static Crosscutting）。
动态横切是指在程序执行的某一个明确的点上运行额外的，预先定义好的实现，是一种静态实现机制，并非是动态的。为了实现动态横切，AspectJ中引入了四个新的概念：连接点（Join Point），切入点（Pointcut），参考（Advice）和方面（Aspect）。连接点是明确定义的程序执行过程中的一个点，切入点则是指一组相关的连接点，参考定义了在连接点执行的额外实现，方面则是指对横切关注点的模块化封装实现的单元，类似于AOP中的类，由切入点，参考与普通的Java成员声明组成。如前所述，连接点是程序执行中明确定义的点，比如，类接受到方法调用时，方法调用时，属性访问时都是连接点的例子，在连接点处可以执行预定义的额外实现。而要指明在哪些连接点上执行，则需要定义切入点，切入点可以在程序运行时匹配特定的连接点，AspectJ中预定义了一系列标准切入点，包括方法与构造器的调用，接受调用，执行，域的get，set访问，异常处理，实例类型匹配，处于类或方法体中，控制流中，调用者调用方法，类型的初始化与静态初始化，通过这些预定义切入点的组合可以实现自定义的、复杂的切入点。在编译时，方面中的参考将被转化为标准的方法，类代码中匹配切入点的连接点将被转化为一个静态的标记点，然后，这些静态?br> 静态横切是指对已存在的类型定义引入新的方法，属性等，与动态横切不同，静态横切不改变类型的动态行为，而是改变其静态结构，也即导入（Introduction）。通过在方面代码中声明方法，属性，需要继承的超类，接口等，在代码织入时，可以改变应用此方面的类的定义。
3.2 AspectWerkz
AspectWerkz是一个动态的AOP框架，利用对字节码的修改实现方面的织入，并使用Java虚拟机的动态替换字节码的能力实现动态AOP的要求。AspectWerkz没有扩展Java语言，方面、参考、切入点等均使用标准的Java构造块，即类以及方法来实现，并使用XML文件定义这些构造块，此外AspectWerkz还支持使用JavaDoc标记实现的运行期属性定义。AspectWerkz采用了与AspectJ相似的连接点模型，只是支持的连接点种类少于AspectJ，参考的类型一致。
AspectWerkz通过引入一个间接层，方面容器（Aspect Container）以及对字节码的转化，即代码织入实现动态AOP的要求，方面容器管理部署好的类、方面代码，并根据XML文件或JavaDoc注释中定义的方面，参考，切入点等得到连接点处相关的方面信息，并在程序的执行中控制执行流程，在匹配的连接点处执行适当的参考。
AspectWerkz通过类载入层次的适当位置拦截类载入从而实现字节码的修饰。AspectWerkz提供了两种织入模式实现AOP：静态织入以及动态织入。静态织入只在类载入时对字节码作一次性的转化，通过将类的方法实现移入AspectWerkz命名的方法中，将原方法中的代码改写，由方面容器调用适当的参考，并调用前述AspectWerkz添加的方法从而完成代码的织入。导入则由混合类型（Mixin）实现，用于为类增加新的方法，混合类型是一种使用接口与实现类的方式模拟多重继承的机制。AspectWerkz通过修改字节码使被导入的类实现混合类型的接口，并在接口定义的方法中，将控制交给容器管理器，由它来完成对实现的调用。静态织入可以在运行时动态的为切入点增加，删除参考，可以引入新的参考，但是无法定义新的切入点，这需要动态织入。动态织入由两阶段织入完成，分别为类载入阶段与激活阶段。首先，在类载入时，按照静态织入的方法，为需要实现动态织入的类的每个方法添加一个相应的空的方法，匹配连接点的方法除外。然后，在激活阶段，原方法体中的代码将被交换到类载入时新产生的方法中，原方法将实现静态织入时相同的处理，从而方面容器控制流程。前述代码交换是由热交换（HotSwap）实现的，这是JVM提供的API。通过方面容
3.3 SpringFramework
SpringFramework是一个采用了反转控制（Inversion of Control, IoC）策 |
| # posted by nexttime @ 2005-04-02 01:01 评论(1) |
|
|
|
苏福特有个家伙居心不良，总想把我抓进千兆安全组里，我都和老谢说了不去，居然还有这个念头。
那个地方估计忙得不行，整天在linux代码堆里滚，我才不干，虽然￥可能多点，但我不受诱惑 |
| # posted by nexttime @ 2005-03-31 21:41 评论(0) |
|
|
|
|
|
|
对于模式的“十大误解”
作者：John Vlissides 来自：未知
【译者语】现在“模式”这个词真是非常流行。就象任何流行的东西一样，对它的误解也真是不少。甚至在一些发表出来的文章中，也存在着各种各样的误解， 我想这会对读者造成非常糟糕的引导作用。早已想写一篇文章来澄清一些对模式的误解，却又因为水平所限难以成文。恰在此时， 我看到John Vlissides先生的《十大误解》，于是我便乐得当文抄公了。
关于设计模式，下面有十种错误的观点——很多都是很流行的观点。且看Vlissides先生如何拨开这些迷雾。
最近，围绕着模式的讨论日嚣尘上，人们对模式的混淆、惊惶和以讹传讹已经不是一点半点。这也从一个侧面反映出对于主流软件开发者来说，模式是一个多么新鲜的领域——尽管严格说来，它并不是一个新的领域。同时，模式也是一个飞速发展的领域，留下了大片的空白。而且，没错，我们这些模式的支持者也应该受批评，因为我们没有把自己的知识完完全全的教给别人。尽管我们这样想过，但是却没有这样做[BMR+96, Coplien96, CS95, GoF95, MRB98, VCK96]。
因此，我觉得自己有责任来纠正一些模式方面越来越夸张的误解——我常常听到的那些误解都足以形成自己的模式了。甚至连我也曾经想以模式来组成自己的软件结构……后来我才明白：“把所有的东西都变成模式”，这种想法本身就是错误的！总之，请记住，这篇文章不是在给模式社群的人们看的。我想，绝大多数的模式专家都会同意：下面这些都是很常见的误解。但是他们也许不会同意我消除这些误解的方式。
这几年以来，我听到过许多人谈论模式。把听到的这些东西整理一下，对模式的误解大概有三类：对于“模式是什么”的误解，对于“模式可以做什么”的误解，以及对于支持模式的人群的误解。我的“十大误解”都落入这三类之中，所以我就把这些误解都组织起来。首先，我们来看看关于“模式是什么”的误解。
误解之一：“模式是某种场景下某个问题的解决方案”
这个定义来自于Christopher Alexander[AIS+77]，所以如果把它称为“误解”，也许有人会把我目为异端。但是下面这个简单的反例就能让你看清它的缺点：
问题：我获奖的奖券就快过期了，我怎样拿到奖金？
场景：离截止时间只有一小时，可是我家的小狗把奖券给吞了。
解决方案：把狗开膛破肚，掏出奖券，然后飞奔到最近的兑奖地点。
这是“某种场景下某个问题的解决方案”，但它不是模式。还缺了什么？至少缺三样东西：
1. 可重复性。解决方案应该对应于外部的场景。
2. 可传授性。一个解决方案应该可以移植到问题的不同情况上。（绝大多数模式的可传授性都建立在“约束”和“效果”的基础上。）
3. 用来表示这个模式的名称。
确实，很难找到一个令人满意的定义。“模式讨论”邮件列表（patterns-discussion@cs.uiuc.edu）上正在进行的讨论也证明了这一点。难以定义的一大原因是：模式既是一个事物，也是对类似事物的描述。要区分这两者，有一种办法：“模式”这个术语只用来指代模式的描述，同时用“模式实例”来指代模式的具体应用。
但是，术语的定义很可能是白费力气，因为一个定义可能对一个人（比如程序员）有意义，但是对另一个人（比如只能看到书面材料的项目主管）却毫无意义。当然，我不打算在这里提出什么最终定义。但是，任何对模式要素的规定，除了必须包括问题、解决方案和场景之外，都必须提及可重复性、可传授性和名称。
误解之二：“模式就是行话、规则、编程技巧、数据结构……”
我通常把这些误解统称为“蔑视”。如果你试图把某些不熟悉的东西简化为熟悉的东西，产生这种想法是很自然的，尤其是当你没有特别的兴趣去钻研这些不熟悉的东西时。另外，某些人经常拿新瓶装陈酒，然后大吹“创新”、“革命”一类的口号。保持警惕也是好的。
但是，这种蔑视通常不是来自亲身体验，而是来自肤浅的认识和一点点冷嘲热讽的。而且，没有什么东西是真正“全新”的。人们的脑海中一直都存在着各种各样的模式，只不过我们现在刚开始为模式命名、将模式记录下来。
来逐个说明这些看法：的确存在着模式的行话，例如“模式”这个词，例如“约束”，例如Alexander的“无名质量”，等等。但是模式是不能简化为行话的。与其他计算机科学领域相比，模式引入的新术语实在是少得可怜。对于听众来说，好的模式本来就很容易接受。在说明一个模式的时候也许有必要引用问题领域的行话，但是几乎没有必要使用什么特定于模式领域的术语。
没有哪个模式是能让你不假思索就使用的规则（组件则正好相反），同时模式也不仅仅是“编程技巧”，尽管模式中的“方言（idiom）” 部分是特定于语言的。在我听来，“技巧”这个词带有轻蔑的意思，并且过分强调解决方案，而忽视了问题、场景和名称的重要性。
毫无疑问，你也曾经听说过一次创新被接受的三个阶段：首先，它被当作垃圾扔在一边；然后，人们会认为它不具可实施性；最后，大家都明白它的意义时，它也没有意义了——“我们一直都这样做”。现在，模式还没有完全走出第一个阶段。
误解之三：“理解一个，就理解了全部”
一刀切的规则往往是不公平的，而人们对模式却更加一刀切。模式的领域、内容、范围、形式、质量……这个领域大得吓人，只需要随手翻翻PLoP 的书[CS95, MRB98, VCK96]就能看出。不同的人写出不同的模式，而模式的变化甚至比作者还要多。象Alistair Cockburn、Jim Coplien、Neil Harrison 和Ralph Johnson 这样的作者已经超越了最初大量记录不同领域、不同形式模式的阶段。只看几个例子就对模式做一个笼统的结论，这样的结论必定是错误的。
误解之四：“模式需要有工具或方法学的支持才会有效”
在过去的五年中，我记录、使用并且帮助其他人使用模式，还至少帮助完成了一个基于模式的工具[BFV+96]，所以我可以很有把握的说：模式的绝大多数好处都来自于原封不动的使用——也就是说，没有任何形式的外部支持。
在谈到这个主题的时候，我通常会指出模式带来的四大好处：
1. 它们记录了专家的经验，并且让非专家也能理解。
2. 它们的名称构成了一份词汇表，帮助开发者更好的交流。
3. 它们帮助人们更快的理解一个系统——只要这个系统是用模式的方式描述的。
4. 它们使系统的重组变得更容易，不管原来的系统是否以模式的方式设计的。
过去，我一直认为第一项是模式最大的好处。现在我认识到，第二条起码也同样重要。请想一想，在一个开发项目的过程中，有多少字节的信息在开发者之间流动（包括口头的和电子的）？我猜就算没有1G也有好几兆。（在推出了《设计模式》之后，我已经收到了好几十兆给GoF的电子邮件。而且我们所描述的还都是小型到中型的软件开发项目。）由于有如此之大的信息交流量，所以效率上任何微小的提升都能大量节约时间。在这个意义上，模式拓宽了人们交流的带宽。我对第三、四条的评价也在逐渐提高，特别是在项目越来越大、软件生存周期越来越长的今天。
至少在短期内，模式主要存在于大脑中，而不存在于工具中。如果有了方法学或自动化工具的支持，应该还有其他的收益，但是我相信这些都只是蛋糕上的奶油，而不是蛋糕本身，甚至都不能算蛋糕的一层。
* * *
到目前为止，我说到的误解都是关于“模式是什么”的。现在来看看关于“模式可以做什么”的误解。这里有两种不同的风格：夸大其词的和心存疑虑的。
误解之五：“模式可以保证软件的复用性、更高的生产力、世界的和平……”
道理很简单，模式什么都不保证。它们甚至有可能无法给你带来利益。在创造新事物的过程中，模式无法取代人的位置。它们只是带来一种希望，有可能让一个缺乏经验的、甚至是未入门的，但是有能力、有创造性的人尽快获得设计的能力。
人们经常说：好的模式会让读者有“啊！”的回应。实际上，只有当模式恰好拨动了读者的某一根心弦时，他们才会有这样的反应。如果没有，模式就只象森林里普通的一棵树。因此，什么是好的模式？不管它写得有多好，如果不能引起读者的共鸣，它又怎能算是好的模式？
模式只是开发者的工具箱中的另一件工具，对模式寄以过高的期望只会适得其反。准备充分，然后做最坏的打算——这就是防止受骗、消除对抗最好的方法。
误解之六：“模式可以‘生成’整个软件体系”
这个误解与上一个有点相似，不过侵略性稍微少些。
每过一段时间，模式论坛上就会讨论一次模式的生成能力。按照我的理解，“生成能力”是指模式创建最终行为的能力。很多人认为，模式可以帮助读者解决模式本身没有明确提出的问题。我读过的一些书里也有同样的观点。
对于我来说，“生成能力”的关键是模式的可传授性——约束及其解决，或者对于效果的讨论。在你定义、精炼一个体系结构时，这些观察是特别有用的。但是模式本身并不制造任何东西——任何东西都是由人来制造的。而且，模式不可能覆盖体系结构的每个方面。给我任何一个有实际价值的设计，我都能找出其中模式没有涉及的设计问题。也许这些问题不常见、不具可重复性，或者只是还没有以模式的形式记录下来。不管怎样，你都必须负责填补模式之间的空白——用你自己的创造性 |
| # posted by nexttime @ 2005-03-30 22:00 评论(1) |
|
|
|
天涯、科院星空、未名、两全其美、一些野的百合。感到要速度和内容都好确实难寻阿，比不上百合给我的感觉，我现在都不知道哪好，可能还就是继续游荡吧。
继续伤百合…… |
| # posted by nexttime @ 2005-03-27 19:49 评论(0) |
|
|
|
最喜欢你温柔的样子/让我懂得生活的美好/最喜欢你依恋的样子/让我感受自己的重要
如果微风吹乱你的头发/我会为你束起/让你知道我的关心
如果寒风侵袭你的身体/我会紧紧拥抱你/我要我们永远在一起 |
| # posted by nexttime @ 2005-03-25 22:56 评论(4) |
|
|
|
与同学说起，才发现百合的关闭，自己的损失比想象中的还要大，回想当初自编的的注册机、挂战机、上战机、发贴机，真是令人神伤。不过好在这些马甲们也已有贡献，比如在陈主任的事件中、在帮各位朋友顶贴中……
天涯取代不了我心中的百合，那里有着我的成长，我的情与爱（爱情也在那开始，呵呵） |
| # posted by nexttime @ 2005-03-25 21:56 评论(2) |
|
|
|
|
