代码是从guithub的gist上抄的,单改?jin)改Q原始代码见: http://gist.github.com/66925
q段代码解决的是l典的汉诺塔问题Q通过一根中柱,左׃64个大依ơ叠加的圆盘全部Ud到右柱,要求整个q程中每ơ只能移动一个圆盘,且每个圆盘只能独立占据一Ҏ(gu)子或是叠加在比自w更大的圆盘上?/p>
单分析一下就知道Q这是一个递归问题(FP的英雄特?Q?/p>
很容易发C个patternQ那是UdN(N>1)个圆盘,可以通过以下三个步骤Q?/p>
在解释代码之前,先说说Scala的implicit隐式转换Q这是一个非常powerful的ideaQ当Scala~译器发现类型不匚wQ它不会(x)直接failQ而是试从代码中指定的,在scope内的implicit转换定义Q来替换问题对象或表辑ּ以满类型要求,当然Qؓ(f)?jin)避免歧义,同一时刻Scala需要找到唯一的一个满x件的implicit定义?/p>
我们的代码首先定义了(jin)一个取得友好类名的Ҏ(gu)Q不LI它Q然后定义了(jin)一个正整数的序列,也不LI它?jin),你只需要当作他们是正整数就好,接触qFP的同学应该对此类定义不陌生,接下来定义了(jin)如下3个支持implicit传入参数的方法:(x)
含义分别是:(x)
单说明:(x)Scala用[]表示cd参数Q区别于Java?lt;>Q另外,Scala的类型声明在变量/函数定义之后。Move[_,A,B,C]的含义是通过CQ从AUd圆盘到B?/p>
我们来模拟运行一下,Z(jin)演示效果Q用一个中{复杂的数目Q?个圆盘,从LeftUd到Right?/p>
run[_3,Left,Right,Center]Q对应Move[Succ[_2],Left,Right,Center]Q于是展开成三个MoveQ?/p>
Move[_2,Left,Center,Right]即Move[Succ[_1],Left,Center,Right]
Move[_1,Left,Right,Center]
Move[_2,Center,Right,Left]即Move[Succ[_1],Center,Right,Left]
然后l箋展开Move[_2,Left,Center,Right]和Move[_2,Center,Right,Left]Q得刎ͼ(x)
Move[_1,Left,Right,Center]
Move[_1,Left,Center,Right]
Move[_1,Right,Center,Left]
--------------------------
Move[_1,Left,Right,Center]
--------------------------
Move[_1,Center,Left,Right]
Move[_1,Center,Right,Left]
Move[_1,Left,Right,Center]
q个时候已l全部都匚wMove[_1,A,B,C]Q于是我们很Ҏ(gu)得到以下输出Q?/p>
Move from Left to Right
Move from Left to Center
Move from Right to Center
Move from Left to Right
Move from Center to Left
Move from Center to Right
Move from Left to Right
希望本文能带lScala初学者一些感性认识和启发?/p>
如果你用Firefox或Operaq且看到?a href="http://m.tkk7.com/sean/archive/2007/01/25/96060.html" target="_blank">上一随W?/a>?abbr title="What You See Is What You Get">WYSIWYGq一个词Q你可以看到它下面是用一串点标注出来的,如果你鼠标?zhn)停在上面Q会(x)有工hC?What You See Is What You Get"。HTML源代码是:
<abbr title="What You See Is What You Get">WYSIWYG</abbr>
可惜微Y的IEq不能正renderq个tagQ尽它是标?X)HTML的一部分?/p>
http://www.garrettdimon.com/archives/aspnet-vs-front-end-architecture
该文作者细C(jin)他在使用ASP.NETq行开发的q程中遇到的6点不爽的地方Q主要都集中在前台架构上Q包括大量内联的风格标签、不同浏览器生成不同面代码、失败的标记设计、缺乏语意一致性、服务器端label和客L(fng)label的脱节、服务器端ID和客L(fng)IDp{等。尤其当你想使用标准的CSSQ构建数据结构和表现分离的清晰页面时QASP.NET的一些默认的内部处理可以让你对ASP.NETZq样做完全无语。比较有的是本文后面的回复Q其中有不少与楼d病相怜的|友Q还有来自微软员工的为ASP.NET辩护的声韟?/p>
我一直对MS在很多设计思\和决定上?j)存疑虑Q不明白Z么MS是要自成风格搞自己那一套蹩脚的所?规范"?标准"Q似乎在鼓励大家follow一个ƈ不清晰、多有些杂无章的设计架构Q其实ؓ(f)?jin)方便它实现更cool?abbr title="What You See Is What You Get">WYSIWYG开发工兗就拿今天来_(d)本来我们目定义好所有模块都按BO和UI分开QBO里面的类和UI里面的类各施其责Q原则上UI依赖BOQ而不是反q来Q按照我的理解和期望QW(xu)indows.Forms命名I间应该是由UI层来依赖Q而非BO层。很昄Q因为我们的form都放在UI层,肯定是依赖Windows.Forms?jin),而我们尽可能把所有业务逻辑代码攑ֈBO层。但是ؓ(f)?jin)?f)时实C个文本文件Ş式的logQ因为我们的业务逻辑代码都在BO层,所以ؓ(f)?jin)记录有意义的logQ我们的log逻辑自然而然只能攑֜BO层。但是一个基本的获取E序q行路径的方法属于System.Windows.Forms.Applicationc,让我们不得不using System.Windows.Froms。这其实q好Q我们也怸应该强求Windows.Forms一定就是只针对UI上的应用。问题是你每天都在面对类似的情况Q每天都或多或少在和.NET API和框架其他部分在打架Q当你?NET的API旉久了(jin)Q自然而然你就被它带到它的那一套思\中,你的设计也就自然而然跟着它走?jin),业务逻辑和UI逻辑交织在一P当你回过头来x层次理清理顺已经成ؓ(f)Mission:Impossible。因为抛开MS推荐的方式,自己实现一套自认更清晰的架构,相较"官方"的blueprint设计Q代价实在有些高?/p>
所以虽然我没有真正开发过ASP.NETQ尤其是2.0版,但我很能理解他们遇到的尴?/p>