从微波炉谈面向对象

微波炉功能简单，可以按食品分裂加热，可以手动控温，将来也有可能在外面添加触摸屏（如现在的洗衣机一样）。外设功能逐渐比较多，我们需要把这些杂七杂八的东西统一在一起，这样facade模式就派上用场了。

其实对于一些外设功能，我们是不是可以封装一下，这样用户说要加热，我们就do一下加热，对于要停止加热，我们也do一下stop。看到这里命令模式又派上用场了。反正的是do，对于怎样do让居然的功能去做吧。

将来用户执行一个功能，如果能告知执行的结果那就好了。比如加热鸡，如果加热好了，可以提示一下来个语音。如果是高级的微波炉能发个短信提醒一下也是超好呀！这样MVC就派上用场了。

我们刚说的高级功能的微波炉，想想她有哪些功能，她有显示屏，有语音提示，可以发短信等待。如果鸡加热好了，一方面要语音提示“呀呀！鸡好了，快来吃！”，一方面显示屏上，蹦出一只熟鸡跳呀跳，还有文字，“我是一只，熟了的鸡，呀呀，什么时候赶紧来吃！”，一方面发短信给老婆叫她回来调味（主要是我不会调味，呵呵）。一个对象发生变化，需要将这些变化通知给多个对象，那不简直就是观察着模式吗？

对于加热这一功能是有一定步骤的。比如可以简单分为加热前，加热中，加热后等若干步骤的。需要加热的东西如粥，米饭，鸡等都要遵循这个步骤的。对于一个操作，俺某些固定的步骤去执行，这不是模板模式的体现吗！

唉，刚说的对于需要加热的东西如粥，米饭，鸡等都要遵循相同的步骤，在每一步骤中有一些相同的，比如加热前开火，加热后关火等，但是还有些不同，比如煮粥的时候，火候要控制好平稳，对于加热鱼温度要小一点，而热猪手温度要适当大一点否则不好吃。我们在不改变操作的前提下，又能执行一些新的功能，这不是Visitor模式的具体体现吗！

其实对于食物加热的是个技术难题，怎样在最短的时间内加热让其内部营养元素损失最少，又要保证其口感好，当然还要环保省电。我认为这里会对不同类型的食物需要一个复杂的算法进行控制。那就用策略模式吧！

前面说了一些功能需要封装成一个对象，那怎样兴建这些对象呀，这些对象是不是可以单粒呀，如果不是单粒的，是不是有些可以利用原形进行clone来呀！这样工厂模式，单粒模式，原形模式是不是也是需要的呀！

说实话，这几年广东这么微波炉市场发展的太快了！一方面要生产面向农村的低端微波炉，一方面还要生产面向大中城市的中高端微波炉，另外对于国外欧美非常高端的市场俺们也不能放过呀！老板说三大通吃，一个都不能少，都要强，都要狠才行！面对这么多套家伙，很多抽象的功能接口都是一样的，只是有些具体的实现不一样。比如加热开火，如果低端的就开个火就行了。而高端的或许需要检测一下外围情况，如果不能开火，还要来个报警。想想国外一个老太太喝汤被汤烫伤了还赔n多钱。俺们的微波炉要是有问题了不是要给赔光了不成。不扯了。反正是一套接口，多种实现了。咣当，赶紧查了一下设计模式圣经。圣经明确写着此类情况非桥（bridge）模式不可。

好了，现在总结一下，看看设计一个破微波炉要用到那些模式：
Facade，Command,MVC,Observer,Template,Visitor,Strategy,Factory,Singleton,Prototype,Bridge

其实对一些问题如果真正理解的其内含，联系起来，还是蛮方便的！如果答不上来，有时候也需要反思一下自己，是思维上，知识上，反应上等哪些地方出问题了。最近面试，偶被多线程的问题问倒，现在想想这一块的确是我自己的软肋，项目中用多线程太少了，一些东西知道，时间长了只是有个大概印象，细节的东西忘记了！呵呵！

这种情况的面试，如果回答的好，非常能活跃气氛，拉拢面试官与应聘者的距离。其实这比群呕，做游戏的要好多了。对于这两种，我一般必死无疑，因为我根本摸不透其中的规律呀！呵呵！


这个得看项目经验了，以前跟一些老鸟在一起工作得时候深有体会，他们因为多个项目得磨练，对于系统框架得可能变化点熟得很，比如分页框架，他们一般就是用适配器模式，以利于未来引入新得分页开源框架，还有就是对xml文件得处理，对于像我这样得新手来说，看到得是接口，具体内部用得是哪个开源框架，他们也做了封装。还有就是数据源和dao，一般都是用工厂模式，以方便在各个数据库间得切换。

另外就是，项目分不同区域得版本，主要框架是一致，但是在具体业务上却大有不同，具有地方特色，那么就需要对业务层进行高度抽象，灵活使用工厂模式，门面模式，策略模式等等，这样才好方便地方实施程序员进行扩展以及代码重用。