葛京的blog

@mikelij
“这样重构法不具普遍意义. 因为它只适合于enumeration. 如果是复杂条件呢. 我个人认为这是design pattern的错误应用.兄弟你中毒了. ”

同意 mikelij。

polygoncell 的代码重构，核心就是从 if-else 改到 switch 再改到 Map，其必要条件是：业务判断条件只包含简单的枚举。假设发生变化的恰恰是判断条件呢？polygoncell 的重构把这种判断条件可变的灵活性舍弃了，所以遇到以上假设的情况时，代码就无可避免的需要作大量更改。而用原来的 if-else，代码就很灵活，更改的地方也很少。

我也同样认为if .... else .. 过多应该进行重构。 我这里没有那么复杂，仅仅是将
判断的集中状态也写出枚举。 语法通过switch....case.... 去判断。 如果再复杂的话我会写出lz第5片的模式。

第三篇中，我有个疑问public abstract class SystemStatePerformer
这里的SystemStatePerformer是抽象类，lz怎么将其实例化了呢
new SystemStatePerformer(LOGGEDIN, getImage("loggedin.gif"))。 是否应该单独写个类继承此类？

HiMagic!
ifelse -> switch -> map

演了一遍，就是HiMagic总结的过程。

5篇有点多，合为一篇看起来比较好。
博主能整理下，把文档和代码打个包，提供下载，更好。～我很懒。

这里用了switch...case的方式，不是if...else变体吗？

那么这个重构虽然形式上去掉了if...else，但代码复杂度反而增加了。

个人觉得前文把int换成enum型就足够了，不必再往后重构。

这样重构法不具普遍意义. 因为它只适合于enumeration. 如果是复杂条件呢. 我个人认为这是design pattern的错误应用.兄弟你中毒了.

这个代码比if 更丑陋 ..... 看了本书 就强用书上的东西 .... 很有问题 .......
博主有团队工作的经历吗 ...每个人都这样写(小提大作)...... 项目就真乱了....
自己研究还差不多 ... 我打赌 你要是真的 遇到了 你还是用 if

@zhuxing

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

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

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

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

@zhuxing

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

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

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

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


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


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

其实我觉得 if else 很漂亮。不过我也不否认模式应用的好处。只是不要过度设计。

@zhuxing

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

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

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


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

@隔叶黄莺

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

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

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

@polygoncell
一、二、三、四、五连着五篇这么投放广告还能是试验呀，俯卧撑超过三个就会死人的，你这样 5*4=20，哎呀，要快差不多7个人了。

@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的。 现在编码强调的是粒度适度，便于测试，便于阅读。

难道 Map 内部实现不是 if-esle 嘛?

计算原理三要素: 顺序、循环与分支

OO 只不过是重新封装了一把.

对于这个简单的问题,觉得ifelse加上应有的注释,好过这么大堆复杂的实现,加上注释的好处也是便于维护和后人的理解,并不比这样实现下来差很多

@zhuxing

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

@Unmi

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

@千里冰封

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

@Unmi
确实,我开始还以为是系统的广告呢,原来是作者自己加的,有点那个了,我想做俯卧撑了

@Brian
写成五篇，可以投放的广告就能多多了。

google 广告太多，影响了我继续看这个系列的心情。

避免过度设计

我支持楼主，他只是用一个简单的例子来说明如何进行重构。对于实际的case，往往复杂的多，一个好的架构开始的时候貌似增加了代码，实际上后面维护起来就舒服很多了，切身体会。

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

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

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

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

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

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

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

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


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

别连放5篇到首页，以免形成视觉污染。

呵呵，看到这里，我明白你是怎么做的老！

我也是if else……黨！

这么写了如果以后代码交给别人维护
要交待得太多了把

在enum中加入多态方法吧。

一篇文章就能写清楚的事情，不需要写5篇吧？简单事情复杂化！

呵呵，一个业务实现的方法是多种多样的，但，当一个业务有简单变的复杂时，回头来看以前写的方法就知道优劣了，平时多锻炼oo也无可厚非,集沙成塔。支持一下。

平时写这些只会让效率更加的低下，业务逻辑封装的时候倒是可以考虑这样的方法，写一个统一调用的接口！就像楼上说的不能为了OO而OO，OO的目的是为了提高效率和减少维护的成本！博主写不的不错，赞一个！

这就像打蚊子,不能只选用大炮的,只要是合适的武器能解决问题就好.

我们写程序的本质是解决问题,如果就是为了OO而OO,反而陷入了OO的泥潭,如果一个简单的逻辑只是因为用多了ifelse,就觉得不好,不够OO,我想就有点钻牛角尖的味道,而不是code的badsmell了.
本人的感觉(粗略看过)如果只看这个问题,是把简单问题复杂化了.呵呵

ifelse -> switch -> map
其实代码无所谓丑陋与否，只不过是心理作祟。关键在于怎样最符合业务逻辑，怎样最适应业务场景。

汗,要是我写肯定也是if esle结构的.

你的做法在某些情况下是非常适合的
但 if else 在某些复杂的业务逻辑中是无法避免的

我在豆瓣上有个swing小组，欢迎加入。

如果有兴趣的话，请到这里讨论这个话题。
http://www.douban.com/group/topic/3604639/



　很不错的一个Tip
　　
https://balloontip.dev.java.net/

基于该库写了个检查框架，用在了我的一个项目中。
　　效果如下
　　
http://www.douban.com/photos/photo/111403280/

你的截图也不是 ubuntun 下的。

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

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

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

谢谢捧场，能用得上就好。

不错...

人家用你管得着吗？