面向对象设计之微波炉与冰箱的故事
这些天看到一贴子,地址如下:
http://topic.csdn.net/u/20091125/14/99c028d1-6cf0-4f82-b852-b94b84c4fb45.html
大概说的是:
[Quote=引用楼主 x_wy46 的回复:]
代码题(用oop的思想编码,注意代码规范)
用java写一个微波炉,注意物品正加热时不能开门,带皮带壳食物不能被加热。
用Java写一个冰箱,注意家用冰箱多数分为冷冻柜和冷藏柜两个柜(冰箱随机)
如题,就是要用面向对象的方式写代码,我怎么看不出来怎么写,
比如第二题,我一个接口然后具体类实现接口完事,结果被鄙视,无情鄙视啊
这是某某的面试题,大家各抒己见!!!
[/Quote]
以下是我的思考,记录下来,有兴趣可以在此加以回复讨论
这道题的目的是考面向对象,想要考察面试人员的考点我觉得:1、通过封装尽量降低解耦,2、提高可扩展性及可维护性。
所以观察题意,本人觉得先找变化点,再对其进行封装。
微波炉的例子变化点有两个,即:
微波炉的状态和微波炉中可加热的食物的判定:
先说微波炉的状态:微波炉的状态应该用状态模式,将开门、关门、加热封装成三种状态,如果以后有了新状态,如:强加热、中加热、弱加热等,可直接添加状态类而无需改动原代码。
再说微波炉中可加热的食物的判定:加热的食物可能会和加热状态耦合,之后为考题加难度可能会使不同加热方式可放入不同种类的食物等方面。此时,变化点比较复杂,所以食物不一定只有带不带壳,可能还有其他分法,为了解耦,可将不同的类的食物及不同类型加热方式封装在策略模式中。
此时,如果加入新的加热状态则只需要加入一个状态类和一个此状态的策略类。
但是这样做还是有问题的,因为如果加入一种新的食物,就需要更改所有的策略类,使所有加热状态都够判定新的食物。
微波炉例子就到这里吧,至于冰箱的例子,原文描述为:
“用Java写一个冰箱,注意家用冰箱多数分为冷冻柜和冷藏柜两个柜(冰箱随机)”
还是先找变化点,其中,每个柜的大小、开门方向或制冷量都是其属性而已,不属于变化点。
我认为变化点在以下描述中可以看出来:
冰箱有双开门或单开门:其中双开门又包括上冷藏下冷冻,也可能会是下冷藏上冷冻;而单开门可能只有冷藏,但也可能把冰柜也算在内。所以变化点之一就是冰箱的不同组合方式会是单柜或不同的上下柜。
另外,此处可以看到,有的组合了两种,有的只有一种,有的可能有特殊的保鲜柜,
将来的冰箱除了单开门和双开门,可能会加入三开门(保鲜柜)等。这时,问题不只是组合方式更加灵活,除了更加灵活的组合方式外,还有就是加入了新的冰柜类型即“保鲜柜”。
这两个变化点都可以用组合模式来完成,组合模式不仅可以让你的类组合起来更灵活,而且可以让新组件的添加独立于以前的结构。
注意:上述我所说的三个模式是GoF书中的composite组合、strategy策略和state状态。