摘要:刚刚看到《动态计算字串表达式值的类》，好像有许多人表示更喜欢解析器形式的求值类。其实我个人倒觉得用反射实现没什么不好，恰恰相反，我觉得这种实现方法很聪明！另外，装配中的脑袋的代码可以稍微修改一下来提高效率，那样再用的话就不会因为反复编译而影响效率了。 言规正传，不知道大家有没有注意我最近在Blog中添加了一个叫ANTLR的连接，它就是一个著名的“编译器的编译器”，不过它实际上是ANother Tool for Language Recognition（ANTLR），它的描述语言可以生成词法分析器、语法分析器与语义分析器，也就是说，我们可以用它来识别加工不同的语言（编译器的编译器）。它同时支持3大类语言的输出：C++, Java, C#（按照生日排序），也就是说，我们可以利用它来用C#生成编译器。ANTLR是免费开源的，而且历史也很久远了，目前的版本是2.7.5，有兴趣的朋友可以在我的Blog的连接中找到网址。 那么，除了用反射轻松的实现计算值之外我们也可以用ANTLR来描述这些数学表达式，下面我附上一个我在看到《动态计算字串表达式值的类》后写的一个语法文件，感兴趣的朋友可以去下载ANTLR来试一试下面的语法哦！： 文件Calc.gheader{ using CharBuffer = antlr.CharBuffer;}options{ language = "CSharp"; namespace = "Cavingdeep.Test.Calc";}/******************************\ Calc Parser \******************************/class CalcParser extends Parser;options{ exportVocab = Calc; buildAST = true;}expr : sumExpr EOF ;sumExpr : mulExpr ( ( SUM^ | NEG^ ) mulExpr )* ;mulExpr : powExpr ( ( MUL^ | DIV^ ) powExpr )* ;powExpr : negExpr ( POW^ negExpr )* ;negExpr : ( NEG^ )* a:atom! { if (#negExpr != null) { AST lastNegNode......[阅读全文]

摘要:因为最近关注AOP的人越来越多，所以就阅读了一些关于AOP方面的文章，一篇个人认为比较好的文章是我在CSDN上看到的转载的一篇文章，转载者没有注明出处是哪里，所以我只好将转载网址贴在这里了《AOP及其Java实现机制》。如果您还没有听说过AOP或者还不怎么了解，欢迎首先阅读转载文章然后再继续这篇Blog。 由于目前我对Java的了解不是非常丰富，所以就不对Java方面的AOP作出评论了，但就.NET而言，我觉得AOP在.NET中的实现还是有一定的不理想因素的。 AOP思想 AOP的基本思想是将不同方面（Aspect）的代码分别开来写，达到逻辑清晰，可复用的目的。与OOP不同，AOP的核心是关注点（Concern），它将程序分为核心关注点（业务）与横切关注点（可能有纠结的功能，例如日志、事务等）。AOP并不与OOP冲突，OOP是AOP中实现业务的手段，我们主要用OOP来做核心关注点与横切关注点的实现，然后用AOP将这两种关注点合并产出最终程序。 AOP的实现 目前，AOP会通过织入器（Weaver）将不同方面的代码混合（织入），织入的方式多种多样，一般来说，只要是能够将两段毫不相干的代码混合在一起，那么就可以叫做织入了。不过，目前大多数产品的做法是采用反射、动态代理、元数据等方法来作为AOP的织入方法。我在下面要讲的，就是反驳大多数采用动态代理来作为AOP织入机制的产品，也就是我前面说到的AOP目前来说，至少在.NET中，还是不太理想的。 Aspect# 在.NET下也有不少的AOP框架，其中比较有名的当数Aspect#，但是我在对它进行了一定的使用测试后，发现了至少对我来说，它丝毫没有用处。它的实现机制就是大名鼎鼎的动态代理与反射。对于还不熟悉动态代理的朋友，它说白了就是“代理”模式的动态形态，可以动态的生成某个类的代理。至于代理模式，就是GoF中著名的23个设计模式之一的代理模式，还不明白的朋友赶快翻阅一下《Java与模式》吧！^_^ AOP中的代理模式 你也许会问，我到底对动态代理有什么不满呢？没有，我对动态代理没什么不满，如果使用正确的话，动态代理还是很有价值的。不过，要想作为AOP的万能织入器的其中一种，动态代理就不是那么可靠了。熟悉代理模式的朋友一定都知道代理模式是靠继承（或对“基接口”的实现）实现代理的，那么如果一个类不可以被继承呢？Bingo，这时代理模式就不成立了，也就是说，如果你用Aspect#对一个sealed类进行Mixin的话（混合以便动态增添新功能）那么它就会失败，因为无法创建动态代理。这到底是怎么回事呢？让我们来看看代理模式（在这里更准确的说应该是装饰模式）是如何做到织入新代码的：public class A ...{ public A() ...{} } public interface ILog ...{ void Log(); } public class ProxyForA : A, ILog ...{ public ProxyForA() ...{} void ILog.Log() ...{ //...... } } A a = new ProxyForA(); ILog log = (ILog) a; log.Log(); 就像你看到的上面的代码，动态代理会动态的生成这个Proxy类，并且通过一个Wrapper来将它返回，作为一个A看待，这时看不到ProxyForA存在的你可能会认为真的很神奇，将A的行为扩展了，但当A是sealed类时利用动态代理的弊端就暴露了，因为A是不可以被继承的。这也从另一面证实了一个OO设计原则的重要性：DIP（Dependence Inversion Principle），这个原则基本上告诉我们要以抽象概念做设计，不是以具体，这样，我们就永远都有可能使用代理模式了。关于OO设计原则，我在CSDN上的Blog有一篇总结它们的文章，感兴趣的朋友可以参阅一下^_^ 那么现在让我们来看看AOP中的另一个织入手段，拦截器（Interceptor）。拦截器可以根据一个或多个切入点找到要切入的代码部分然后将横切方面（日志、事务等）代码织入，这个织入手段同Mixin一样，本身没有什么问题，问题出在在Aspect#中也是通过代理来实现织入的，这样就又带来了一个新的问题，什么问题呢？虽然目前.NET下AOP框架产品对于切入点的支持不是很广泛，但这也只是迟早的事，问题还是没有的，真正的问题就出在使用代理模式上面，让我们来看看如何通过代理模式在已有的类成员中实现织入：public class A ...{ public virtual void Do() ...{ //.... } } public class ProxyForA : A ...{ private IInterceptor _interceptor = new LogInterceptor(); public ProxyForA() ...{ ......[阅读全文]

摘要:通常如果使用VS.NET的话会理所当然的使用VSS作为版本管理系统，但是VSS并不像其他版本管理系统那样强大，另外它也是要花钱的。相对CVS是Java上受众较广的一个版本管理系统，免费，功能强大而结构简单。不过不是因为是免费的所以稳定性不好，如果选择一个较稳定的版本的话CVS还是非常可靠的。如果要对比CVS与VSS的话那么我想你一定会更喜欢CVS的。这里就不作比较了，不是本文的目的，本文的目的是告诉你如何在.NET项目下使用CVS管理版本。 第一步就是下载相关软件，以下是需要的软件，全部免费并且开源： CVSNT（http://www.cvsnt.com/），CVS是一个真正的C/S版本管理系统，所以有服务器和客户端的说法。CVSNT是CVS服务器中的佼佼者，要比官方网站的好的多，而且支持多个平台，是目前使用最广泛的CVS（包括客户端）。记住一定要挑一个稳定的版本哦，一般相对旧一些的稳定版本才是真正的稳定版本。 TortoiseCVS（http://sourceforge.net/projects/tortoisecvs），CVS在Windows下的客户端，这个东东做的非常好，与Windows Explorer紧密集成，CVS这么复杂的系统使用这个客户端就简单多了。 本来还有一个产品叫CVS SCC Proxy插件，可以使微软的多个IDE拥有直接访问CVS的功能，但是这个插件不是免费的（虽然也不是很贵），而且目前还有许多功能上的不足以及bug，所以我没有打算采用它。不过插件的集成效果倒是非常的好，在VS.NET中与操作VSS没什么两样，除了CVS本身的功能要比VSS多一些除外。 WinMerge（http://sourceforge.net/projects/winmerge），一个比对与合并的软件，TotoiseCVS可以用它来做版本比较与合并操作。 依次安装，安装好后就可以使用CVS做版本管理了。CVS并不是一个非常直观的软件，使用它还是需要一段过程的，一般相关软件的文档中都有教材告诉你如何使用CVS，这里就不叙述了。以下是TortoiseCVS在使用中的图片。 ...[阅读全文]

摘要:前段时间经常听说很多关于Subversion的好话，所以我决定也是时候真正体验一下了（我一直都是关注Subversion的哦）。Subversion相对CVS来讲有以下几点优势： 增加了元数据（Meta-data）的版本控制，Subversion有很多设置都是通过元数据实现的。 增加了文件夹的版本控制，没有文件夹的版本控制是CVS中一个很大的不足，这点在Subversion中得到了解决。 支持文件、文件夹的重命名与移动，好处多多，方便多多，不用再描述了吧。 真正的原子提交（Truly Atomic Commits），提交作为一个事务，如果某一受控对象提交失败，那么其他提交的对象也不会有效。这个功能真是一个字：好！同时支持不同仓库（Repository）中受控对象的同时提交。 一些性能上的优化，如分支（Branching）与标签（Tagging）会采用文件夹的受控方式达到优化。 Subversion在使用习惯上与CVS最大的不同之处在我看来就是它的修订号（Revision）的定义了。Subversion中修订号不是针对某个特定的受控对象的，而是针对整个仓库的，你在Subversion中不会说“文件A的第4个修订”，而是“仓库修订4中的文件A”，每一次提交都会导致仓库修订号的增加。更多关于Subversion的介绍请看它自带的文档，这里就不叙述了。 如果你决定使用Subversion，那么你很可能需要下面几个软件（免费开源）： Subversion服务器与客户端（http://subversion.tigris.org），官方版本，我采用的版本是1.1.3。Windows下建议下载安装文件包，因为安装更全面，而且会自动配置环境。 TortoiseSVN（http://tortoisesvn.tigris.org），官方版本，Windows下有两个，一个是常规版本，一个是为VS.NET 2003及更低版本Web项目不支持.svn文件夹的bug所做的非常规版本。非常规版本数据不能与其他版本通用，所以不建议使用，更多信息请看Subversion的相关文档。 SVNService（http://dark.clansoft.dk/~mbn/svnservice/），可选。可以安装一个Windows服务来运行svnserve服务器（Subversion的独立服务器。Subversion可以使用两种服务器，Apache作为服务器或者它自带的svnserve）。 依次安装后就可以使用Subversion了。与CVS同样，Subversion（SVN）分为客户端与服务端，首先你可以用TortoiseSVN建一个仓库（Repository），注意这个操作是在服务端，然后你要选择一种连接到仓库的方法（在客户端），有以下五种： file:///ReposPath/RepoPath，以文件的形式直接访问，最简单的连接方法，不需要服务器，权限由操作系统来控制，如果后台仓库你采用了FSFS（文本）格式的话那么还可以在局域网共享中使用。 http://host/Repos/Repo，如果你采用了Apache作为服务器的话就可以以这种形式访问，权限由Apache设置。 https://host/Repos/Repo，与上一个一样，同时采用了HTTPS加密通信。 svn://host/Repos/Repo，如果你采用了svnserve作为服务器的话那么就可以采用这种形式访问，它是一种基于TCP/IP的访问方式。权限由仓库的配置文件设置。 svn+ssh://Repos/Repo，与上一个一样，同时采用了SSH的加密通信。 有了连接的URL后就可以用TortoiseSVN连接到仓库了，然后你就可以开始真正使用Subversion了。其他的我就不说了，有兴趣可以自己看看文档，推荐首先阅读TortoiseSVN的文档，Subversion的文档复杂度有些高，不宜初学者！...[阅读全文]