PC的blog

@zhuxing

有些年头了，不过写java代码还没超过10年，你呢？

你觉得这样做繁琐，请问如何做才简单？能不能贴出你认为简单的代码？有时候旁观和自己动手做的感觉是完全不一样的。还有，别忘了要把简单留给使用你代码的人，而把繁琐留给自己。

有msn么？咱俩好好聊聊。：-）

@zhuxing

那个反射主要是为了分析@FactoryMethod注释，用意很清晰：减少不必要的编码。状态增加后，程序员只需要增加一个带@FactoryMethod的方法就行了。

申请加入，谢谢。

ID： polygoncell

@zhuxing

我又仔细的考虑了一下，觉得静态方法在这里并不适用，因为我们需要针对不同的状态写出完全不同的逻辑来处理状态。静态方法通常适用于参数实例繁多而逻辑相同的情况。

@隔叶黄莺

这位兄弟挺逗的！呵呵。那个4是怎么得来的？

兄弟没必要这么针对我吧，我没招惹你吧。真的是做个实验，你可以看看我以前的文章。

哦，对了，楼上众位兄弟哪位能够帮我分析一下：我应该有如何处理自己原创的文章的自由吧？ 而且看与不看全凭自愿，为什么有些朋友的反应会这么激烈？最好那些反应过激的朋友能站出来说说你们的想法，大家交换一下意见，谢谢。

@BeanSoft

map没有使用一大团if else，HashMap的代码如下：

public V get(Object key) {
if (key == null)
return getForNullKey();
int hash = hash(key.hashCode());
for (Entry<K,V> e = table[indexFor(hash, table.length)];
e != null;
e = e.next) {
Object k;
if (e.hash == hash && ((k = e.key) == key || key.equals(k)))
return e.value;
}
return null;
}

而且Map已经封装好了，对于我们使用者来说是没有if else的。 现在编码强调的是粒度适度，便于测试，便于阅读。

@zhuxing

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

@Unmi

我也就是这次试验一下这么写，效果不好的话会考虑下次换个方式。

@千里冰封

呵呵，可别超过3个。 对了，你的那个音乐播放器挺不错的。

呵呵，大家的反应很激烈啊！

我这里只是使用一个简单的例子来解释如何使用重构来移除if else，实际应用逻辑当然要复杂很多。

的确有一些程序员觉得一个方法里面使用一大堆if else很方便，其实这只是对他自己方便，别人阅读他的这一大堆if else会很头疼。

我这样重构看似增加了代码量，实则封装了大量的技术细节。

建议大家去读读refactoring to patterns这本书，书中就讲到了一个结对重构（该书的作者和一个程序员）的例子，最开始那个程序员也觉得重构完后，代码量明显增加，他很不爽，但是后来他熟悉了那些模式后才发现他以前的做法是错误的，应该进行这样的重构。

本书的命题是“入门和精通”，网上提供的章节仅仅是入门级别的内容，是为那些完全没有Hibernate基础的同学准备的。 那些已经了解Hibernate的同学一定会觉得这些章节很乏味，这是很正常的，因为你们已经掌握了这些入门级别的内容，再看一遍，自然乏味。但是请你们为那些从来没有接触过Hibernate的同学考虑一下，他们非常需要一个相对浅显易懂的台阶来帮助他们“入门”。这就是我撰写前几章入门内容的初衷。

对于那些已经了解Hibernate的朋友们，请你们静下心来阅读后面深入内核的章节，在这些章节中，我是从构架的角度讲解了Hibernate的几个主要的模块，举例印证，图文并茂，大部分内容源于实际项目。如果通读完全书，还有朋友认为这本书“不怎么样”，那么我作为这本书的作者，在这里诚心诚意的期盼着你们的宝贵意见，对于正确的意见，我将会在本书的后续版本中加以采纳。

不论如何，非常感谢大家对本书的关注。