引言： 今天与朋友对Architecture进行了一番讨论，最后这哥们搬出了《The Unified Software Development Process》的资料证明给我看
呵呵，俺不敢妄言UML三巨头的RUP有错，但如果行而上，是不是有迷失自己的危险？！
说实话，对UML和RUP，小朋友我还初...
摘要：俺一向信奉“它山之石可以攻玉 ”。
多年从事计算机的经验告诉我，对待棘手问题最有效率的方式是依赖“它山”（可能有人一辈子也找不到这座山！）。
这种思路可能触及了某些技术疯子的敏感神经。但却是俺的切身体会。
抛开软件不谈，以小朋友我对硬件和一些操作系统使用的精力来看
对待某些问题不能一味死钻牛角尖。
殊途同归是老夫到现在还能搞定一些别人反复试......
摘要：
发了好几篇关于lisp的文章，但是一直苦于手头没有一个合用的lisp解释器，于是狠一狠心，决定自己写一个，一来是为了配合前几篇入门教程，二来也算是打发无聊的时光吧。
花了不到两天时间，写出了一个lisp解释器的雏形，遵照惯例，我给它起名叫lisp48，意思就是48小时内写出的lisp，当然，你也可以把它理解为只完成了48%的lisp。其中还有很多bug，很多语句还不能正常工作，不过我想这应......
Use your head,Out of the Box--对RUP的一点思考今天与朋友对architecture进行了一番讨论,最后这哥们搬出了«the unified software development process»的资料证明给我看
说实话,对uml与rup,小朋友我还初在似懂非懂的阶段. 【程序编程相关:微软.NET手持设备开发工具包基础篇(转】
呵呵,俺不敢妄言uml三巨头的rup有错,但如果行而上,是不是有迷失自己的危险?！ 【推荐阅读:微软.NET手持设备开发工具包基础篇(转】
为了让研发的相关人员能在一个统一的平台上进行交流,就有了uml与rational的unified software development process. 【扩展信息:微软.NET手持设备开发工具包基础篇(转】
uml这种东东给我带来对软件研发的思考,首先是从不同的角度去分析软件的合理性,但每个人有每个人的角度,从自己的角度去看问题,得到不同的结论.
如果对这种交流方式求一个极限,两个人如果水平相当,并且能够面对面的去交流,是否还需要用uml?！当然如果记录交流的结果用于本别人交流还是需要uml的.
所以uml与rup只是记录与交流开发思路的手段,用来描述与规范看问题的角度与结论,但不等于能替你思考.
但一切事务的本质还是发现问题,分析问题,解决问题.
uml与rup能够促进对软件的研发的正确理解与交流.apple以前有句广告词:“use your head！”
...
下一页 摘要：对象去耦（object decoupling）
代理（proxy）模式和状态（state）模式分别提供了供你使用的代理类(surrogate class)；正真干活的那个类被代理类隐藏了。当你调用代理类的一个方法的时候，代理类只是简单的调用实现类（implementing class）所对应的方法。这两种模式非常相似，实际上，代理（proxy）模式只是状态(state)模式的一个特例。
......
