Java 专业人士必备的书籍和网站列表

摘要：

书籍

每个程序员都会有一些由于经常被当作专业资料参阅而磨坏的书。下列书籍应该是 Java 语言程序员的书架上必备的。书很贵，所以我有意将这份列表弄得很短，仅限于重要书籍。

Thinking in Java (Bruce Eckel)

Thinking in Java, 3rd edition （Bruce Eckel; Prentice Hall PTR，2002 年）
Java 编程思想：第3版 （陈昊鹏 等译; 机械工业出版社，2005 年）
Eckel 的书对于学习如何在 Java 语言环境中使用好面向对象技术极其实用。书中大量的代码样例解释了他所介绍的概念。文字出自一个并不认为 Java 技术总是正确答案的人，所以相当地实用。Eckel 具有多种语言的大量经验，还有用面向对象方式进行思考的扎实技能。本书将这些技能放到实用的 Java 语言环境中。他还在写一本新书，名为 Thinking in Enterprise Java。

Effective Java (Joshua Bloch)

Effective Java: Programming Language Guide （Joshua Bloch; Addison-Wesley，2001 年）
Effective Java 中文版 （潘爱民 译; 机械工业出版社，2003 年）
本书是理解优秀 Java 程序设计原则的最佳书籍。大多数材料从其他的 “学习 Java ” 的书中根本找不到。例如，Bloch 书中关于覆盖 equals() 这一章是我读过的最好的参考资料之一。他也在书中包括了很实用的建议：用接口替代抽象类和灵活使用异常。Bloch 是 Sun 公司 Java 平台库的架构师，所以他透彻地了解这门语言。事实上，他编写了该语言中大量有用的库。本书必读！

。。。。。。

。。。。。。

。。。。。。

这个话怎么说的这么不顺啊，换种说法。芒果软件，是一群技术精英的名字，我们来自四面八方，为了一个共同的前途走到一起，开始了一款软件从创意、设计到开发、测试、上市、销售，以及未来将成为国产软件之骄傲的传奇之旅。。。。。。

我们所说的这段软件，就是XMIND！它是第一款可视化思维工具，也是目前市场上唯一的同类产品。登陆我们的网站可以看到它的介绍和截图：
http://www.mango-software.com/
以及免费下载beta版：
http://www.xmind.cn/

[什么是可视化思维工具？]
很多管理咨询公司和培训公司，以及很多中学和大学的教师，他们在传授一类方法，或开设一门课程，题目可能是“如何提高你的工作效率”。 这类课程80％的内容是很无聊的，学员也不太喜欢，但是有20％的内容是激动人心的。我们发现这激动人心的提高工作效率的方法就是用形象的思维工具帮助思 维。比如很多管理咨询公司和培训公司会开设名为“思维导图”的课程，课上要求学员们用纸和笔把自己脑海中随时冒出来的创意随时记录下来。

记录的方法是在纸的中央画一个椭圆，里面写上中心主题，从这里发散出去想，想到的内容标为分支主题，每个分支主题还可以再发散，字写在线上，线划到 哪儿都要多划一点，这样就促进了自己的思维，这种思维方式比写文章要快很多倍（如果你没试过是无法想象的快），很快你就写满了整张A3纸！

即为别人培训又会做软件的我们就想到用软件来实现这一切！因为软件绘制思维导图，可以大大提高绘图制品的价值，不仅可以自己看，还可以与别人分享， 最重要的是即使修改。如果在纸上绘制的时候把一个分支错误的连接在了另一个分支的后面，就无法修改了，如果是重要的图，就必须重新绘制，但是软件就不怕 了。另外，软件还可以排版，或者将某个思维导图导出成Word/Powerpoint的格式，再进一步利用，这就延长了办公软件的流程，从用户脑子里想的到纸上打印的完全的连接了起来。

作为补齐最后一公里的软件产品，可视化思维工具还是跟其它Office软件有很大的不同，首先，Word和Powerpoint几乎都是以线性的方式组织文字和内容的，这和人脑的结构有很大的不同，因为人类都是以发散的方式思 考问题的；其次，Word和Powerpoint在调整篇章结构上太繁琐也不直观，很多用户都反映，他们在写文章或制作幻灯片之前都先用XMIND列提 纲，以便于谋篇布局，然后再为每个分支填入内容，之后还可以持续优化篇章结构，完全确定了以后，再用XMIND导出成最终需要的格式，修改错别字和最后排 版。

除了绘制思维导图以外，XMIND还包含了很多其它符合人类基本思维方式的图形，我们将这类图形统称为“思维图”。XMIND提供了在线更新的功能，XMIND的用户还可以从芒果软件的网站上源源不断的下载更多的思维图的种类。当然，我们只作最重要的，适合大多数人的，具有个性化的图形还是要靠用户自己用XMIND丰富的个性定制功能自己设计，并提取模版，相互交流。

可视化思维工具的另一大类用途是与他人交流思想。我们有很多客户是大企业的销售经理，他们在向客户演示自己产品和服务的过程中引入了XMIND，并获得了很好的反馈效果。因为它的形状是最适合人脑思维的，所以能表达的信息也最多最精确，也最容易被别人接受。XMIND的图标库也为用户绘制的思维图提供了额外的亮点，图形+图标所具有的表达能力是非凡的。此外，咨询公司和培训公司还辅导学员们利用XMIND帮助记忆和会议记录。最后，XMIND可以将同一个主题的所有思维图整合在一个文件里，因为用户愿意将“晨会计划”、“晨会内容”、“参会人员”和“会议反馈”等主题放在一个文件里，便于发给自己的boss。

上面这些就是可视化思维工具的主要功能，了解一下XMIND 2007就会发现它的功能还远远不只这些。芒果软件的宗旨就是为广大用户提供最适合思维的软件，而XMIND的宗旨就是整理您的思维、发掘您的潜意识、激 活您的创意灵感，最后，帮助您绘制漂亮的图形。让Google去搜索网络吧，我们搜索的是您的大脑！

[谁将会是XMIND的用户？]
XMIND有两类大的用户群：

1。高层经理、白领精英、办公室一族、政府公务员
特征：每日工作用脑量很大，处在现代办公环境中，常常需要计划、决策、记录、创意、演示、与人交流等等，工作节奏很快，工作时间中使用电脑占一定比重。

2。中学生、大学生、中学教师、大学教授
特征：每日学习、工作用脑量很大，常常需要记录、总结、归纳、综合、交流等等，工作、学习繁忙，使用电脑占一定比重。

芒果软件实验室正在研发中的项目Brainy（利用盛行于欧美，风靡于全球的思维导图理论）将会成为未来人类离之不得的全脑思维伴侣，它利用计算机软件技术和全脑思维艺术将人们的大脑和思维带入一个积极、高效的全新领域，Brainy将会在人们日常办公和生活中帮助用户增强记忆、规划写作、促进团队合作和内部沟通，在客户演示、会议记录、个人计划、项目管理、青少年教育等方面更是发挥着不可估量的作用。

Brainy不能取代任何Office 办公软件，却能和当前的Office紧密集成，成为办公软件生态环境中的一员，Brainy存在的目的是为了填补用户的大脑和办公软件制品之间的鸿沟。多数用户可以在五分钟之内上手，并在第一次试用之后就离之不得。尤其对于英文区国家的从小在这种氛围中长大的用户而言更是容易接受这种理念。也正因为如此，芒果软件实验室从成立之初就把国际市场当作最重要的市场来看待。

目前Brainy仍在开发阶段，芒果软件实验室需要有理想有抱负有能力有信心的“四有”技术骨干和创业精英的加盟。我们以Eclipse RCP为产品的运行平台，以测试驱动为产品的开发过程，以大量开放标准和开源软件为降低产品成本的有效手段，以全球第一的思维导图软件为产品的战略目标。

芒果软件实验室在技术上重视重构和复用，在经营上重视产品化和全球化，在管理上重视“团队综合能力”和敏捷开发，实验室还会定期聘请“武林高手”现身讲座，让每位员工每周都有培训的机会，每月都有培训别人的任务，定期参加Code Review，量身订做技术课程。

思想为箭，芒果做弓。一群充满激情和个性的年轻人正试图通过他们的努力去改变人们的思维方式，乃至改变整个世界。

加入我们，你一定会大开眼界！

公司主页：  http://www.mango-software.com

有意者请联系（邮件请包含个人简历）：hr.mangosoft@gmail.com

最近在写一个使用XMPP协议(gtalk和jabber使用的) 即时通讯的客户端，在.net下使用了一个Open Source库ags. 这个库是基于Windows Socket异步方式来做底层架构的。这就存在NUnit的使用问题，

如果按照一般Unit使用过程，在客户端发出请求后，因为异步原因，会不等接收数据的delegate事件被调起，Test函数就会提前退出。

为此到网上海google了一番，均无此法，后来搜到一封网上的英文mail，mail里写了几行好像测试异步访问Web服务器的测试程序，没头没尾看不出究竟干什么的（他们是讨论一个feature问题），但里面几行给了我很大提示，其中有一行

 if (!reset.WaitOne(timeout, true))

这似乎就是我要寻找的提示，嗯用线程同步信号不错，估计可以解决，经过2个小时反复试验终于出炉啦,呵呵!

大体程序如下：

static ManualResetEvent reset;

private const int timeout = 3000;

[TestFixtureSetUp]

public void FixtureSetUp()

{

reset = new ManualResetEvent(false);

}

[TestFixtureTearDown]

public void FixtureTearDown()

{

reset.Close();

}

[Test]

public void TestConnect()

{

。。。。。

msgControl.Connect(connectInfo);

Assert.AreNotEqual("", msgControl.Status);

msgControl.RecvStringEvent += new RecvStringCallback(msgControl_RecvStringEvent);

reset.Reset();

// note for some reason r.AsyncWaitHandle.Wait won't work as expected

// if (!r.AsyncWaitHandle.WaitOne (timeout, true))

if (!reset.WaitOne(timeout, true))

{

if (recvTimes == 0)

{

Assert.Ignore("Timeout");

}

else

{

Assert.AreEqual(8, recvTimes, "not recv 8 times");

}

}

Assert.IsNotNull(message, message);

}

private int recvTimes = 0;

void msgControl_RecvStringEvent(string msgText)

{

recvTimes++;

message = msgText;

if (recvTimes > 9)

{

recvTimes = 0;

reset.Set();

}

}

希望能对编写异步通讯的人有所帮助

GEF源码分析（六） GEF 的EditPart的职能分离 __ 跨国时尚媒体集团广告部门 的故事 二

GraphicalEditPart先生当天安排了部门及会议计划。经过EditPart部门紧张有奏的准备会议讨论的资料，第三天、按时8:30开会。

GraphicalEditPart先生还如往常，准时提前5分钟坐在会议室前边角上。他喜欢部门的小伙子们，虽然这些小伙子们做事情时常有些不周，但是他更欣赏他们的活力和富有创造激情。所以、每每开会时，他更愿坐在旁边听这些小伙子们的意见，“相比较当个威武的军队长官，我更意是一个严格又和蔼的优秀教练”GraphicalEditPart先生常常如此提醒自己不要越俎代庖。

部门干将小李主持会议，简短阐明会议主题和要求后，（为了提高会议效率会议每人最多5分钟发言，最后20分钟讨论时间，5分钟GraphicalEditPart先生做总结）。

小王首先站起发言：“目前我们EditPart部门，虽然，主要任务有明确定义，但是内部的工作流程不明确，没有可依章程。...”。

“是呀，公司目前还没有我们部门的标准操作手册，很多问题都有很大随机性，工作的好坏过于依赖人员本身的工作能力，这十分不利于人员的内部流动以及新人员的补充”我们的GraphicalEditPart"教练"满意的点点头。

小魏起来补充一下：“由于我们内部每个人的做事方法，都是各有一套绝活，流程不一致，经常导致在工作对上下层通知协作出现问题。在水平部门沟通时，也常常不流畅”。这是个大学刚毕业十分活泼的小姑娘。

“为什么大家总是觉得女的职员不好，看多有灵气的一个小姑娘呀，又是个好苗子。”GraphicalEditPart"教练"此时内心中的自我形象简直就是华佗再世，那感觉真有点飘飘然乎，GraphicalEditPart先生不由自主地晃了晃脑袋。

接下来其它人纷纷发言：

“工作经验很难相互交流，积累与提高。很难在部门级对工作流程等进行优化，缺乏专业化。”

“我们经常要和Figure部门一起工作，跟踪操作执行。这很是浪费工作时间，尤其是当某个工作需要很长时间，或者中间经常需要和客户交流反馈一段时间，这样非常影响工作效率。”

“对于客户的问题很难快速根据现有的经验模式形成解决方案，虽然我们公司服务态度和广告质量高于其它公司，但是经常由于反应速度太慢，活被其它公司从中抢了去，销售部门常常抱怨我们部门速度太慢。”

“公司在相应客户需要操作过程中，很难针对客户某个需求重新调整。客户常常抱怨在制作过程中很难做些小的改动。”

……

由于GraphicalEditPart先生管理小师的带领，EditPart部门的会议总是简短有效。1个小时多几分钟大家都把问题简明扼要的表达出来。

小李环顾下四周“最后，由GraphicalEditPart部长总结一下今天的会议”。

一直沉默的GraphicalEditPart先生站了起来，十分精神，也环顾了一下四周，清了清嗓子。

“首先、我要自我检讨一下，这一年多总是忙乱于紧急的小事情当中，很久没有收集大家的建议和反馈了，这十分不利于我们部门的发展。今天大家举出很多目前部门的问题，这些充分反映了大家对部门的业务熟悉程度，我相信，这是因为大家十分关注公司的未来，希望公司越办越好，而不是怨天尤人的牢骚，可能有些领导会觉的这是找毛病对领导不满，在我这里，我今天在一次明确表明，我十方鼓励大家，欢迎大家将一些意见反馈给我，希望大家不仅仅是简单反馈在工作中的直接困难，而且经过自己的思考提炼写成简洁的文书给我，最好发挥自我主动和创造性提出一些变革建议。这些东西将是我们部门及公司潜在的珍贵的财富，同时也是我们部门未来发展方向的一个重要部分。”

“今天的会议大家主要是针对我们部门的问题，希望会后大家再从公司整体考虑这些问题，以及未来扩充EditPart部门会带来什么问题，比如大家可以参考我们当初成立时遇到那些问题，这些问题将来如何避免或减少。”

“按计划，会后，小李，小孙，小丁，小黄还有我，将总结今天会议，同时、制定出未来部门组织变革的策略。在此期间，希望大家踊跃的将自己的想法创意于我们交流。”

“还有一件事情，今天要批评一下小丁同事，现在开会不迟到了，但是，不仅没发言、我看你从开会就一直看前天发的材料，为什么不提前准备，这是耽误大家每个人的时间，下不为例。今后、小李你在部门规章里加一条，部门开会前必须提前阅读理解会议材料，凡违反者，包括我在内一律站到会议室角落站着阅读完资料后，在回会议座位。我的话完了。”

小丁满脸通红，不由地低着头，双手捂住了腮帮，不敢喘气了，恨不得有个地缝钻进去。

“今天会议结束。”小李宣布。

会后根据小孙的会议记录，很快的小李几个人总结出以下的一个鱼骨图。

什么是因果图？

因果图的发明者 Kaoru Ishikawa 是一名管理专家，其最初的目的是改进车间的质量控制工作。正如以下示例所示，因果图还能表达其他环境中的因果关系。

 

由于因果图的形状很像鱼的骨架，所以它又称作鱼骨图。鱼的脊骨上几根最大的鱼骨表示主要的原因类别。
例如，在本例中，主要的原因类别有盎格鲁人/朱特人、丹麦人、萨克逊人和诺曼底人，这些种族群体都想控制英格兰，从而导致了该战争的爆发。

主要类别中的较小鱼骨表示主要的原因。例如，在本例中，在萨克逊人这个类别方面，黑斯廷斯战争的主要原因在于公元 1051 年萨克逊王爱德华许诺将王位传给威廉一世。

您还可以在主要原因上添加次要原因。

已存在一个三角图形EditPart，我们想重用它,但是我们还需要增加（或删去）边框可调整的特性，如何保证无需重新建立一个新的EditPart，或者做出丑陋的继承，当功能不断组合后，出现无数子EditPart类?

如何由框架自动完成Undo及Redo功能？

话说在某个跨国时尚媒体集团中国区广告部门（这是一家主营平面广告的广告公司，听说董事长是个年仅办百的老头GraphicalEditor先生，来自赫赫有名的eclipse基金财团），有目前主要有两个子部门EditPart(广告策划部)和Figuer(平面设计部)。

EditPart部长是一位中年充满信心和活力GraphicalEditPart先生。

Figuer部长是一位与部门名同名的广告主设计师美丽青春的Figure小姐。

EditPart部长GraphicalEditPart目前主要肩负着三项任何：

• 处理由其他部门中的Model人员送来各销售部门广告需求；
• 做出具体的平面设计策划交给Figure小姐，由Figure小姐负责画出充满激情的平面广告；
• 读阅客户要求与反馈的Request文书，这些文书是由Tool（情报收集部门）收集客户的反馈及要求，经过专业的整理与分类而成（上篇我们以及探讨过了）

 

由于公司扩大了业务，投入市场的产品种类比以往增加了三倍，EditPart部长工作变得异常繁忙有些快压垮了，感觉自己快成为整日驮着重物年迈的驴子，“是不是自己老了”GraphicalEditPart先生开始常常怀疑自己了。

这天，EditPart部长收到总部一封信：

 

GraphicalEditPart先生：

     首先我代表公司感谢您这些年勤奋出色的工作。我们公司在中国短短三年的营业额增长了四倍，同时EditPart中国部门在此期间获得了公司最有活力部门奖，这些成绩都与您的努力是分不开的。据我们了解，您在EditPart部门这三年中，实施了几项富有创意的制度改革，如成立Tool情报收集部门，推广后大大提高了整个公司EditPart部门业务处理能力。为了进一步扩大业务，公司在未来的两年里将在世界各地尤其是中国增加40%的区域广告部门，正如您所知道目前公司对于EditPart部门的组织规划以及责任制度还有很多不完善之处，这将十分不利于区域部门扩展的计划。故我委托您做出《未来广告部组织的规划》计划书，本月底将邀请您来总部参加组织规划与变革方案的评审会，届时将会对您的计划书进行评审。如通过评审，公司所有广告部将会按照您的计划书进行变革。

                      祝愿世界明天的舞台，因我们而变得更加美好、充满激情与想象

 

                                                                                          CEO GEF

 

“噢！太棒了，这封信来的真是及时，如果再继续如此的话，我要压垮了，只好另谋它职了。嗯，这回我要好好地写这个计划书。这样，身上担子总算有减轻的希望。有上司的赏识，我要一展宏图一番。”GraphicalEditPart不由自主拍了下桌子自言自语后，张开双臂，砰地一下仰靠在椅背上，深深地出了口气，双目轻合工作的压力似乎片刻间消失，顺手戴上了他那十分酷毙的太阳镜，小声打开旁边CD，噢，夏威夷之夜，感觉自己此时就在夏威夷带着墨镜躺在金黄、松软、温暖的沙滩，吹着口哨，热情似火的太阳穿过太阳镜，越过眼皮，将几缕模糊的光芒带入眼中（其实是他那高瓦的吊灯），海风习习（旁边的电风扇），在享受着这片刻宁静天堂感觉，激情创意不断涌出，啊，久违了的感觉。

 

开干！迅速的打开他喜爱的脑图软件 -- Mindjet Manager，记录下脑中的构思，画下如下计划要点：

 

看来GraphicalEditPart先生要大干一场，欲知详情，请听下回分解

般若菩提 2005-12-05 14:01 发表评论

]]>

GEF源码分析（四） GEF 消息转义 ___ Tool的作用

接着上一节：

我们先解决如下问题：

在界面操作过程中，我们希望面对的是边框调整事件，图形移动事件，或者是编辑文本事件，而不是原始的鼠标和键盘事件？

术语定义：

系统UI事件：        一般由某些计算机人机交互硬件发出信号，并且经操作系统理解后产生的事件，例如：原始的鼠标的移动、点击和键盘的敲击事件等。

UI业务语义事件： 由系统UI事件和其它UI业务语义事件触发，由UI业务代码理解后产生的事件（操作系统不可理解，同时无任何领域的业务语义），如2D图形的尺寸调整，2D图形的点击，2D图形的移动。

（其实不仅限于事件的转义，包括UI的改变，也需要由系统UI语义转换到UI业务语义来使用）

UI业务语义事件在Controller控制中的优点是易于理解、维护和扩充，具体的主要有以下方面：

a.减少系统UI事件判断逻辑部分代码的重复。比如在Controller部分代码无需分步着大量逻辑重复的代码，当鼠标移动时去判断究竟是一个2D图形的尺寸改变，还是一个2D图形的移动，还是一组2D图形的移动，还是2D图形DragAndDrop的动作。

b.Controller部分的代码语义明确。在Controller内部处理代码和接口中直接面对的是UI业务语义，如图形的移动，图形的尺寸改变，这样、代码易于理解、调试等。

b.Controller部分代码无需为系统UI事件保存状态。如2D图形的移动中，如果这些事件直接在Controller中处理，从开始MouseDown,到MouseMove，到MouseUp过程中，在Controller中要集中保留这样众多状态，极易造成Controller代码具体多头职责的症状，从而患上严重的精神分裂:)。

于是乎GEF的FrameWork有给出以下的解决方案：

图A

如上图A：

GEF通过Tools(根interface是Tool)，当然在视图上的Menu和Toolbar是通过Action发出，这个是eclipse的Workbench机制，在此就不讨论了。以下是Tool的类继承树：

图B

从上图B可以看出

从Tool继承的这些类均处理一个或者一类UI业务语义事件，其中需要保留中间状态的子类均以XXXTracker形式出现。

首先这些Tool的实现类通过Tool的接口（上图右边），接收界面来的事件，然后调用内部handleXXX，这样通过内部函数getTargetRequest()[createTargetRequest()]和getSourceRequest()[createSourceRequest()]，把系统UI事件转换为UI业务语义事件叫Request（如图C）。至此Tool会通过调用相关联的EditPart的接口将UI业务语义事件通知到EditPart中。于是在Controller(EditPart)中仅仅需要理解处理Request对象。

图C

下面以ResizeTracker代码为例：

class ResizeTracker

protected Request createSourceRequest() {

ChangeBoundsRequest request;

request = new ChangeBoundsRequest(REQ_RESIZE);

request.setResizeDirection(getResizeDirection());

return request;

}

protected Command getCommand() {

List editparts = getOperationSet();

EditPart part;

CompoundCommand command = new CompoundCommand();

command.setDebugLabel("Resize Handle Tracker");//$NON-NLS-1$

for (int i = 0; i < editparts.size(); i++) {

part = (EditPart)editparts.get(i);

command.add(part.getCommand(getSourceRequest()));

}

return command.unwrap();

}

protected void eraseTargetFeedback() {

if (!getFlag(FLAG_TARGET_FEEDBACK))

return;

if (getTargetEditPart() != null)

getTargetEditPart().eraseTargetFeedback(getSourceRequest());

setFlag(FLAG_TARGET_FEEDBACK, false);

}

protected boolean handleButtonUp(int button) {

if (stateTransition(STATE_DRAG_IN_PROGRESS, STATE_TERMINAL)) {

eraseSourceFeedback();

eraseTargetFeedback();

performDrag();

}

return true;

}

最后还有个问题是

Tool这些事件接口，如何从Viewer传递过来的呢？

我画了一个简要的类图

图D

参照上图，下面罗列重要代码：

大家主要以下两方面

一、创建这些关键事件处理链的过程（注意图上的粗体文字）；

二、消息从SWT中Canvas实例传递到Tool过程（图D中注释标签的顺序）；

class GraphicalEditor

public void createPartControl(Composite parent) {

createGraphicalViewer(parent);

}

protected void createGraphicalViewer(Composite parent) {

GraphicalViewer viewer = new ScrollingGraphicalViewer();

viewer.createControl(parent);

setGraphicalViewer(viewer);

configureGraphicalViewer();

hookGraphicalViewer();

initializeGraphicalViewer();

}

protected void setGraphicalViewer(GraphicalViewer viewer) {

getEditDomain().addViewer(viewer);

this.graphicalViewer = viewer;

}

class EditDomain

public void addViewer(EditPartViewer viewer) {

viewer.setEditDomain(this);

if (!viewers.contains(viewer))

viewers.add(viewer);

}

class GraphicalViewerImpl

public void setEditDomain(EditDomain domain) {

super.setEditDomain(domain);

// Set the new event dispatcher, even if the new domain is null.  This will dispose

// the old event dispatcher.

getLightweightSystem()

.setEventDispatcher(eventDispatcher = new DomainEventDispatcher(domain, this));

}

private final LightweightSystem lws = createLightweightSystem();

class ScrollingGraphicalViewer

public void setEditDomain(EditDomain domain) {

super.setEditDomain(domain);

// Set the new event dispatcher, even if the new domain is null.  This will dispose

// the old event dispatcher.

getLightweightSystem()

.setEventDispatcher(eventDispatcher = new DomainEventDispatcher(domain, this));

}

class LightweightSystem

public void setEventDispatcher(EventDispatcher dispatcher) {

this.dispatcher = dispatcher;  //在此Shapes例子中是DomainEventDispatcher

dispatcher.setRoot(root);

dispatcher.setControl(canvas);

}

protected void addListeners() {

EventHandler handler = createEventHandler();

canvas.getAccessible().addAccessibleListener(handler);

canvas.getAccessible().addAccessibleControlListener(handler);

canvas.addMouseListener(handler);

canvas.addMouseMoveListener(handler);

canvas.addMouseTrackListener(handler);

canvas.addKeyListener(handler);

canvas.addTraverseListener(handler);

canvas.addFocusListener(handler);

canvas.addListener(SWT.MouseWheel, handler);

……

setEventDispatcher(getEventDispatcher());

}

class EventHandler

implements MouseMoveListener, MouseListener, AccessibleControlListener, KeyListener,

TraverseListener, FocusListener, AccessibleListener, MouseTrackListener,

Listener

{

…

public void keyPressed(KeyEvent e) {

 //在此Shapes例子中是DomainEventDispatcher

getEventDispatcher().dispatchKeyPressed(e);

}

…

public void mouseDoubleClick(MouseEvent e) {

getEventDispatcher().dispatchMouseDoubleClicked(e);

}

…

public void mouseMove(MouseEvent e) {

getEventDispatcher().dispatchMouseMoved(e);

}

public void mouseUp(MouseEvent e) {

getEventDispatcher().dispatchMouseReleased(e);

}

…

}

这样、在图A中Request发送到EditPart机制做了简要的探讨。

学习了Tool产生Request的机制，可以帮助我们调试GEF，同时如果在大家自己的程序中需要有新的UI交互类型，也可以试着建立自己的Tool类产生新的Request，这样在自己的EditPart产生对应的Command,这样就可以处理实现新的UI交互类型。

在下一篇我们探讨一下有关图A中的EditPart如何产生Command，以及执行Command问题。

包含GEF的Editor创建时序图

以eclipse网站上例子A Shape Diagram Editor为例

GEF如同其他的一些framework一样，是一个复杂庞大（有点夸张）的，当我们想使用驾驭它时，就必须全面的理解其整体构架及其运作过程。这需要我们的毅力和敏锐。旅途开始了….

GEF主要的任务是针对2D图形编辑操作，如下图。

为了使GEF能够广泛的用于种类繁多2D图形编辑领域，GEF就必须建立一个严格的易扩充/易组合/易重用的MVC框架（当然这种分解细化功能对象的方法思想，我们可以用在其它的地方，其它领域、其他语言如C#上）。

那么如果设计 这个 严格的MVC框架(对于Model是严格的独立，它不依赖与View和Controller) 以及 此框架 如何 达到 易扩充/易组合/易重用 的特性。下面我按照自己拙劣的思路，以麻雀之眼度鸿雁之志啦

对于MVC中

View部分：GEF理所当然要使用自家的东东Draw2D。利用Draw2D的Figuer作为自己的View。

Model部分：往往内部包含了千差万别、不可预知的商业信息。因此、GEF框架应该尽量减少约束（在下面将详细说明约束）。

Controller部分：EditPart/Draw2D的Figure/Model这三个树状对象模型，在EditPart中将建立了与其对应的Draw2D的Figure/Model结点 建立一一关联的关系。

这样产生的构架如下：

思考：

为什么Controller要同View一样采用树状结构呢？

当Controller以树状的形式存在，这样便于功能分解（这个道理有点像 在类设计中 复合优于继承 一般）

这样每一结点的Controller(即EditPart) 仅需要处理

• 自身逻辑功能
• 管理子Controller
• 必要时通知父Controller

尤其当用户需要在图形界面编辑界面中，需要使用多种不同UI行为规则的2D元素（例如不同的形状块，不同行为的连线等）组合来完成工作时（例如类似Visio这样的界面），这种构架的优势就显露无疑。

未完待续….(下面要探讨如何产生上述三个树状模型等。)

GEF学习笔记（一） eclipse的GEF相关项目说明

首先、感谢八进制的辛勤劳动和奉献。这几天开始对GEF发生兴趣，八进制的GEF系列对我学这些的帮助很大入门很快。自己也就顺手把周末学习的东西记录下来。帮助后来学人。我会把这几天所学陆续写出希望大家支持。目前、正在为八进制例子发愁，我对NodePart增加了ResizeEditPolicy，但是不知为何鼠标拖动时有个灰色的区域在随着变化，但鼠标释放时，NodeFigure的尺寸不发生变化，是否是因为在refreshVisuals中固化了Size，代码学习中….

eclipse的GEF相关项目说明。

各项目的简介：

Draw2D：建立了2维的图形库(树状图形部件Figure)，负责显示2维的图形展示。

GEF：     （Graphical Editing Framework）建立标准的MVC构架，代码利用Draw2D作为自己的View部分，主要代码实现复杂的树状(于Model分别对应)      的控制器。实现的框架具有很高的可复用等特性，例如：将图形部件功能分解为多个EditPolicy，这样使用者可以通过installEditPolicy接口来定制，以及扩充自己的某一功能特征。

EMF:      （Eclipse Modeling Framework）首先在一个轻量级项目以及项目初期开发，Model常常采用拥有Property的Java对象来简单明了表示【即 Plain Old Java Objects (POJOs)】。EMF定义了一套Ecore元模型，使得Model具有易于维护、易于扩充、易于数据交换等特性的Model Framwork。因此、在实际中大型的项目中往往会采用Draw2D＋GEF＋EMF的方式来实现整体的MVC模式。例如：ROSE的最新版本 IBM.Rational.Software.Architect就是采用了这种构架。

GMF：    （Graphical Modeling Framework ）使用了GEF和EMF，建立了两个之间的桥梁框架，同时实现了一些领域上的典范应用，如UML图，甘特图，脑图等。（项目正在进行中这些功能还未完备。可以用来参考以实现自己的一个标准的GEF＋EMF的应用）。

各项目依赖关系：

如上图：使用者可以有以下几种用法：

EMF: Model管理层

Draw2D: 二维图形展现

Draw2D ＋ GEF: 二维图形的简单编辑模块

Draw2D ＋ GEF ＋ EMF： 二维图形的编辑模块

Draw2D ＋ GEF ＋ EMF ＋ GMF：基于GMF提供的图形编辑功能之上扩展