首先分享2个地图链接，清华大学地图flash版，清华大学地图3D版（需要注册）

清华大学经管学院位于清华大学东门附近，临近主楼，所以乘车的朋友到清华东门下车就行了，如果是到西门的话可就远了。这里有一些经管学院的图片，可以帮大家认准地方，不要走错哦！

如果找不到的朋友可以看下面的Google地图：

查看大图

最近状态貌似不行，想上来扯几句，但是也不知道写什么，于是这里也就有些日子没更新了。让一次次跑来看我的兄弟姐妹失望了，如果有的话。本来想弄几篇技术类的文章来凑数，想想算了，别敷衍了，来这儿的基本对技术也没啥兴趣，还是扯淡比较实际。

最近其实还是有不少开心的事的，特别是今天，我们组长结婚了，他是我的第一个直接领导。一个很好的北京爷们儿，记不清他耐心的为我解答了多少弱智问题，包容了我多少次的SB错误。今天是他大喜的日子，新娘子很漂亮，看着他们交换戒指，我不知道怎么的有一种想哭的冲动，也许是为他高兴吧，真的挺开心的，好人总是有好报的。席间我敬了他们一杯，“老大，祝福你们百年好合：）”。还有，我给家人买到了鸟巢的门票，可以让爸爸带着我妈和奶奶去看看。想想自己能为家里做的太少了，虽然离家很近，但是每周爸妈打电话叫我回家，我总是有一堆鸡巴理由。再有，上周见到了5年多没见的高中同学，她们还是那么漂亮，而我却似乎老了很多，也变了很多。岁月催我老啊，NND的。

最近还会更新一篇和emlog有关的文章，是关于新版本的，我还是那么执着的像个倔驴，因为我真的不想看到emlog死在我的手里，也许它之于我已经不是一堆冷冷的代码。

好了就写这么多吧，象征性的写点，证明我还风骚的活着！

　　还曾记得当初刚开始做网站的时候，利用上了各种的手法去推广自己的网站，因为在搜索引擎这块做得比较多，所以从搜索引擎中来的流量是相当可观的，在流量最高的时候达到了1.5万IP，当时每天上线就是查看统计的情况，丝毫没有意识到当网站大都靠搜索来流量如果某天被K或降权了该如何，正因为在流量很高的时候没有通过开新的其它的网站分流和提升用户粘性的想法，到了流量真的变得很低的时候结果已经不能改变了。

　　除了上面自己所遇到的，我们身边也经常听到某某因为所有的站放在同一个服务器上，所有域名注册信息一致，同一行业百度第一页都是自己的站而导致的K站降权事情多不胜数，当我们在埋怨百度无耻无情的同时其实我们可以做到避免此类事情的发生，在一定程序上可以降低发生的概率，要做到这点就要经常告诫自己记住“居安思危”，永远别把鸡蛋放在同一个蓝子里。

http://deniartru.deviantart.com

我觉得挺好听的，呵呵，

MP3和MV下载地址等网上有发布的时候会第一时间更新的

打开夜的天窗

　　通过《Swing程序的基本设计结构》的分析得知，一个完整的Swing应用程序将由很多组件组合而成，这样做好处是显而易见的。组件是独立的，所以可以独立存在，如同对象一样可以被复用。组件是由领域对象、Action和View组成的。这样做的好处是每一层的任务更加明确，对象更加单纯。领域层封装了各业务的细节（关于领域对象请参照《程序设计不是这么简单》），Action负责指挥各领域对象完成业务操作，View只关心如何更好地与用户交互，对于与用户交互后所发生的一切一无所知。如此便有了应用程序结构的简单模型。

　　我们说过，组件是由不同层的很多对象组合来完成工作的，对象间是相互依赖的，耦合的。这样的程序结构虽然层次清晰，但不易扩展。由于组件对象间高度耦合，对任意一个进行修改将会对其它对象产生影响。更重要的是对象复用比较困难。一个好的应用程序应对扩展敞开怀抱，对修改紧闭大门（开闭原则）。那么如何管理对象的生命周期，以及怎样为对象解耦是我们需要考虑的问题。Spring为我们带来了一个比较好的解决方案，即将对象的生命周期交给容器管理，利用依赖注入使对象解耦。像Spring这样面面俱到的框架功能无疑是强大非富的，它不但可以使用在WEB应用程序中，也可以在桌面应用程序中很好地工作。不过在这个以简为美的时代，对使用者来说，简单高效绝对是重中之重，Rails的成功就是个很好例子。转回话题，为了使应用程序解耦，我们必须开发一个简单的框架来管理对象的生命周期，也就是说我们需要动态地创建对象实例。Java的Reflection机制可以帮助我们达到此目的。（Reflection性能是令人头痛的，也许Javassist、BCEL是个不错的替代方案。不过，在Grape的第一个版本中，我依然使用了Reflection。因为我并没有打算利用Reflection来创建更多的对象，也没有进行ORM，所以性能不是这个版本所要考虑的问题。）我们能过一段简单的配置来了解Swing应用程序的结构。

grape.ui.AppWindow">

　　appWindow是应用程序的主界面，它是由menuBar（菜单）、toolBar（工具栏）、contextEditor（编辑器）和statusBar（状态栏）四个组件组成的。应用程序启动时，框架利用Reflection生成这些组件，并通过appWindow暴露的Setter方法将其注入到appWindow中。

grape.ui.MenuBar">

　　menuBar是由多个菜单组成的（有的可能是二级或多级菜单），上例的菜单栏是由File（文件）、Edit（编辑）、View（视图）、Tool（工具）、About（关于）五个菜单组件组成的。

　　是的，Swing应用程序界面就是这样通过不同的组件组合而成的。还记得吗？每个组件是由View、Action以及领域对象组成的。（注意、这些组合并不是绝对的一对一，很可能一个Action被注册到n个View上，View可会注册多个Action），接下来让我们来看看Action是如何注册到View上的。

grape.ui.menu.MenuItem"> java.lang.String" value="新建"/> grape.action.CreateFileAction"> grape.io.PdfFile"> java.lang.String" value="UTF-8"/>

　　在File菜单下，有个newFile的菜单项用来创建新文件。newFile作为View，并不知道如何创建文件，所以我们为其注册了一个用来创建PDF文件的Action — createFileAction。Action的工作是响应View事件，并根据要求创建文件。Action并不做实际的工作，只是象个领导一样，发命令给手下的员工：“我需要创建一个pdf文件，pdfFile这是你的老本行，交给你去做吧“。于是pdfFile轻松地接过命令，瞬间便将领导要的pdf文件创建好了。领导惊奇地拍了拍pdfFile的肩膀说：”果然厉害，你是怎么做到的？”，pdfFile只是笑了笑说到：“我就是干这个的。”pdfFile是领域对象，负责业务处理的细节，不过，它并不是一个人在战斗。通过继承的File，pdfFile成为了真正的File，通过组合的OutputStrame，它拥有了保存到磁盘的能力。

　　以上就是Grape框架的基本思路和结构，制作它初衷就是希望开发者能够以真正面向对象的思想和MVC结构来进行程序开发，告别以往智能UI的开发方式。以后我将会为大家慢慢展示它的其它特点和思想。

分享收藏