Live a simple life

@rain2sunny
站内发个消息给我，咱们联系联系！

招聘兼职？

@shinewang
你的帖子标题，“拉风”
你的帖子内容，“雷人”
你的跟贴，“镖悍”

证明完毕！

类型初始化 VS 实例初始化 ^_^

1、首先确定是否是你说的缺少依赖的问题
2、简单的插件依赖关系缺少，结合编译错误稍微看一下应该就可以解决了
3、如果真的插件依赖关系比较复杂，可以借助Plug-in Dependencies视图

@蔡超
挺准的^_^

代码搞混了^_^ 不好意思！
已经更新了

关于初始化有两个概念：类型初始化和实例初始化^_^

"但相同的HashCode一定产生相同的index，从而影响产生Hash冲突"
这句话比较有用

内容已经补充完毕，并更新了代码，希望对大家有帮助

下一节内容：为我们的编辑器配置自定义即时校验

下班了，先把源码附上，里面有测试用test.tld

大学最重要是学好基础课：C语言，数据结构，操作系统，有兴趣也把汇编好好学学。
课余时间可以看看java之类的，做点小项目，练练手。


基础课远比后者重要！！！基础好了，什么都好说

补充一副图片

@srdrm
你要的内容补充完了

回答你最后一个问题吧，和SOA没关系，概念包装

马上发布的6系列算是真正支持SOA，采用的是SCA、SDO规范


别被忽悠了

不要只观察规则的jsp内容对应的document是怎样的
也要看看不规则的（不符合jsp语法的）jsp内容对应的document是怎样的

这很重要！！！直接影响后面你定制的行为是否健壮！！！

@Jack.Wang
看书（当然要是好书）和经验缺一不可，看书有助于更好、更快的积累有价值的经验，最后写代码的时候，发挥作用的肯定是经验。

想靠自己的实践积累出来一些经典书上面的结论，显然有点高估自己了^_^ 但是实践积累肯定能够更好地理解书本内容，感觉有点不一样了哈

刚写这篇闲侃，比平时吃饭晚了10分钟。 该吃过饭去小超时买烟，眼看着最后一包红双喜被另外一个哥们买去了，剩下的只有中华和几种很烂的烟了。 思考再三，拿了包烂的

赞同楼主观点，包的设计应该是在通用的设计原则的指导下完成

应该以很多个维度来综合地看待这个问题，尽量考虑到各个规则（例如尽量分离抽象和实现，更好的遵循开闭原则....），不要和经典的规则发生冲突～_～

有的人可能更喜欢从技术视角进行划分，例如可能会出现**.factory类型的包，里面放置了供用户调用的工程类；有的人则可能更喜欢从业务角度进行划分等。

大的原则是存在的，具体细节因人而异 ^_^。

路过 ^_^

@linuxer
你说的是一种办法，在很多场景下可以这么做。我写这篇随笔的时候，就想集中精力来看一下一个行为封装伴随的上下文问题...

“大量的运算逻辑可放在浏览器端了”
怎么听着有点悬乎的 ^_^

@tomay
谢谢你的指教

@隔叶黄莺
哈哈。
回到实际，楼主文章中说的主题和异常配置也有点远，觉得楼主好像意在说一个设计模式

过度倒是谈不上。
Eclipse的绝对部分代码都是要给用户来使用或者扩展的，高质量的代码和高超的设计实现是基础，设计模式这个工具被它们用活了。很多时候，在调试代码的时候，顺便撒两眼，都很长见识，设计模式用户很活

看一下Eclipse本身代码，再看一下WTP的源码，差距就出来了～_～

新鲜，改天也玩玩

@隔叶黄莺 @寻道者

一个框架给我们提供了服务的同时，肯定会给我们提供了相应的限制。我觉得，很多时候在决定要使用一个开源框架或者新的方法论（例如AOP）的时候，不但要看到框架的作用，也需要投入很大精力来分析一下框架的短板和限制。当然，是基于我们的需求来分析，如果脱离这一点，那就没有意义了，纯技术去分析一个框架可以当作闲来无事时的消遣～_～

@popoer
挺美好的想法

听说过，而且还定制过它的源码

@隔叶黄莺
“寻道者”和你讲的不是一个层面的问题。“寻道者”讲的是设计模式，你说的框架使用。你这么比，楼主有可能会生气。

@隔叶黄莺
也斗胆接着聊一下你说的那个问题。从抽象层面讲，我们如果想要处理一个行为的变化，一般需要干这几件事情：
抽象变化，封装变化
数据上下文
控制上下文

这种流行框架中的异常处理配置机制就真的好吗，如果用户想进行自定义的控制下文呢（例如搂主文中的）？？？如果数据上下文变化较为频繁呢？？？（当然，这可能是由于起初对需求抽象不够，对已知扩展没有做详细分析）

我们再切换到另外一个角度来看这个问题，任何一个框架肯定就是提供可复用的数据和行为。这种异常处理的配置机制暂且看作框架提供的行为支持吧。 那我可能会问了？我一个业务处理过程本身就包含了异常处理，我干吗再去配啊，而且给我分开了，以后还要维护这个配置文件？？？

这种异常配置的机制有它的好处，也有它的适用场景，再一个那就是取决于开发者的嗜好....

@隔叶黄莺:我只是有兴趣瞎评论一下，错误请指正

更多的公共代码的放置问题，骨架突出的成份小

被揭发之后才贴上去的，有什么意思呀，强烈鄙视此等虚伪。。。 ？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？


我可以负责任的讲，我发的时候就注明了！！！ 而且是在文章的最开头和简介中都明确注明了！！！！！！！！！！如果你还有什么疑问，我可以给你他msn，这样可以吗？？？

如果你和我认识，有什么个人意见你可以当面跟我提！！！我博客上也有我的msn，你也可以在msn上面和我讲。这种匿名人身攻击没什么意思的！！！请你自重！！！

原文的作者和我是同事，也是我现在参与的产品主架构师，很长一段时间我跟他学了不东西，非常尊重他

【Eclipse插件开发】引用：使用CommonNavigator开发资源管理器--基础篇
【说明】
引用了组里一个架构师的一片文章，写的很好的（尤其是里面看起来比较抽象、闲侃的部分）！！！


楼上的大哥看到了吗？？？？？？？

@cheneystar
楼上说的很对的！

有些情况下Eclipse就是不编译了，例如自动编译选项开放，但是资源修改保存之后仍旧不编译，查看所有的工程配置，都正常。

我原理远程调试过这个问题，发现资源变化的时候，Eclipse不会去调build job了，具体当时没有细看，大致猜测应该是Eclipse的工作区资源管理状态出了问题。

解决这种问题，就是退出eclipse实例，然后eclipse -clean ..... 看运气了，一般可以解决

类似的影响时间的场景还有不少，需要注意，例如：
1、关于流的使用。是否过于频繁的使用了输入流，例如我们的一个实例状态依赖于底层的文件，而且这个对象被使用的非常频繁，是否每次都需要去读这个文件？？？可能引入一个简单的时间戳，检查一下，需要更新就去读一次文件，然后更新一下实例状态就ok了。还有需要频繁使用输出流输出的场景下，是否考虑过简单的切换成缓冲输出流，就可以提高很多性能呢???
2、IWorkspaceRunnable使用，是否每次都需要锁住整个工作区呢？？？
3、插件启动类启动代码中是否干了过多的不必要的活呢？？？
4、是否过于频繁的去查询Eclipse的扩展注册表呢？？？这可是个很庞大的树性对象啊。。。

等等.................

鼓励一把

java虚拟机对类加载本身就做了同步处理。！！！

同一个类加载器实例不可能对同一类型加载多次
不同的类加载器实例可能会对同一全名类型记载多次，那本质上是不同的类型了，类加载器实例一个很核心的作用就是来维护命名空间

@aaa
不能这么说。
楼主写的可能过于抽象

继续

@xxuu503
1、我的建议是用PDEUnit进行插件开发过程中的单元测试。但是有一个问题，那就是在对ui插件进行测试的时候，也会较为繁琐，目前没有看到什么特别出色的工具。基本上就是启一个workbench或者使用键盘钩子的技术

2、第二个问题当然没有违反分层原则。其实，分层原则很广泛：
基础功能模块和上层具体功能模块分层
模块ui和非ui部分进行分层
具体实现细节中注意分层思想，避免紧耦合

m之上可能有很多个c，针对的场景不一样，v肯定是场景的一部分 ~_~

现在ext真的有点走红了
最近看到不少产品中的web解决方案都用了ext

@mark
图片放上去了

@polygoncell
不知道你写了几年代码了

@polygoncell
我也只是和你打个比喻

继承封装变化....静态能继承吗？
－－－－－－－－－简单工厂（静态工厂方法）和工厂方法的最本质区别

如果你真的有封装变化的需求，那你用工厂方法问题不大。如果现有变化比较少，而且能够预想到的扩展需求不大，就别用工厂方法了...


当然你可能有你特定的需求，而且也没法三言两句说的很清楚。说实在的，你的那个反射...什么什么的... 有点乱～_～


你的代码是在使用工厂方法，但是这个创建过程有点烦琐...不需要搞成这样

“编码中对“可预见性”的代码结构适应，扩展接口预留”
个人觉得这种事情在编码之前还是预先想一点的，至少从整体系统或者重点模块的层面上大致想一下，否则，完全推迟到编码时候再去做，那就有点悬了。除非项目组确实有几个老道的高手，否则......就有点困难了

@BeanSoft
"OSGI 不过又是某些人炒作的新概念 或者说 尚未完善"

不能说单纯的炒作新概念了，毕竟是一种不错的组件化开发理论

尚未完善是真的。包括OSGI到底适应于那些场景等等，现在也都是人云亦云

记得《Java与模式》那本书中，有对java中多次分配的讨论。

# re: 使用重构移除丑陋的if else代码（5） 2008-08-04 18:46 polygoncell
@zhuxing

理论上来说，creation method也是可以的，不过这样一来就导致Performer类和过多的其他类产生耦合（因为处理每一个状态需要用到完全不同的类），我用factory就是为了保持performer干净。要是一定要用creation method的话，performer都可以省了，直接写一个复杂的enum，而每一个enum实例正好就是creation method。


大哥：只能说，俺长见识了！ ～_～

如果简单针对楼主的代码，个人觉得这么重构有点过了。

我提出置疑，针对的是：你用工厂方法模式的理由充分吗？

我想强调两点：
1、再仔细揣摩一下你的需求。是不是用个静态方法（creation method）的方式更合理一些？
2、看一下你周围的工作伙伴，这么写会不会增大代码的负责度？（这个问题的标准是有你的同伴来决定，不能自己判断）


最后强调一下：
在学习模式导向重构的时候，看看最基本的重构技巧是否已经熟悉了。我看你那个getPerformers()方法，就有点难受。为什么要把if语句嵌套的那么深呢？？？