假如你有很多算法..

假如你想去某地，有很多种方式和途径。

比如飞机，火车，汽车，步行，或者梦游==

你可以周一坐飞机去，周二坐火车，周三梦游..

现在怎么办？ swith?

 

那么以后某天周一，飞机坏了，怎么坐火车去？

又或者有一天，新出了个诺亚方舟，你怎么乘坐这个呢？

 

可见，要想应付变化，就必须要先考虑好将来要变化的地方。要不然，最后重构到你头大，还不一定能搞定。

 

还是这个旅行的问题，现在我们来重新缕一缕。

现在不只是只有我要旅行了，我的一堆朋友都要来。 怎么办？

 

设计一个超类，统一定义一个旅行的抽象方法，所有想要旅行的人都继承此类，并实现此旅行方法，这样，是不是每个人都可以旅行了呀！

可是，有什么不对的呢？ 旅行的方式很多的，怎么满足每个人的需求呢？

那就把方法的实现放在超类中实现，switch一下，这样，所有人都可以自由自在的旅行了吧。

但是，但是，前面说了，周二没有火车票了怎么办呢，你懂得，天朝的火车票是很神奇的！ 如何在运行时刻知道旅行方式而不是在编译时刻就预定了呢？ 那就设计一个枚举，标记一下每个旅行方法，然后旅行者只需要在运行时指定一下某一个枚举类型就可以了呀！

 

嗯，看上去貌似不错。

 

现在新出了诺亚方舟了，怎么办呢？ 只好修改超类了，对吧。添加一个枚举类型，然后超类中添加一个方舟的分支。

那要是又出火箭了呢，最近又开了船舶的业务... 你的超类是不是越来越胖，最后你不得不面对一个每次维护都头大的‘超级’类！

假如说哈，假如你觉得这样也没有什么，just soso 嘛。 那好，有个旅客比较刁蛮，你懂得，并不是每个人都和我一样善良。

他觉得光坐飞机没有意思，他中间还想坐船，然后再坐坐火车，最后再步行走过去...

先不管这个神人有木有，你的超类还能应付的了吗？ 现在你是不是想诅咒设计这个超类的人吃泡面永远没有调料包了？！

 

面向对象设计的原则是：多用组合，少用继承。

 

而我们的这个超类，明显是用了继承，当然有其好处，但是却使变化变得很难变化。松耦合啊松耦合，都是浮云啊。

 

现在我们来重新缕一缕。

 

我们现在要把旅行方法单独拿出来，不让它继承了，可是，怎么让每个旅行者都可以旅行呢？别担心！

 

我们设计一个接口，只有一个旅行方法。 然后让超类去继承它？ 靠，不是一样么。 我们让超类包含这样的一个接口。然后超类就可以在编译的时候只去调用这个接口就可以了。至少运行时是谁，管他呢，只要是个实现了该接口的不就行了么！

这样，每一个继承自超类的旅行者都有了旅行这个接口，当想要旅行时，只要动态的指定一个实例，然后执行之就可以了。

 

现在，让我们来看看究竟发生了那些变化。

 

当诺亚舟出现的时候，我们怎么应对呢？ 不错，建立一个诺亚舟的类，实现旅行方法，然后只需要让旅行者在需要的时候实例一个诺亚舟的实例就可以了。 那爱折腾的人呢？同样建立一个折腾类，实现旅行方法，然后让旅行者去使用。（有点坏味道啊，先不管了）

 

这样，再出现再多的方式也可以搞定了吧。我们再也不需要去修改超类了，只需要在需要的时候扩展一下接口，然后运行时指定它就可以了。最重要的是，我们的超类保持了其完整性，不再那么不靠谱，可以应对一些变化了。

应对变化并不是不允许有变化，相反，我们喜欢变化，没有变化是一潭死水，变化最突出的特点就是它总是要变化。

所以我们要做的就是如何应对变化，当变化来的时候，我们以最少的变化来应对之。 这就是目的。

 

好了，第一次写一些心得体会，但愿写的比较靠谱。临时想出来的例子，但愿能说的明白~

如有不妥之处，欢迎指正。