用户名  找回密码
 FreeOZ用户注册
查看: 1608|回复: 10
打印 上一主题 下一主题

[论坛技术] 讨论一下Design Pattern应用的问题

[复制链接]
跳转到指定楼层
1#
发表于 3-8-2009 08:43:43 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有帐号?FreeOZ用户注册

x
碰到下面一个问题,看看大家的解答是如何。

A database contains a table named Car, which has a column named Frame.
This column can take one of the following values:
LIGHTWEIGHT=1
NORMAL=2
ARMORED=3


In the software associated with this database, developers decide to use
a simple integer. When checking the frame of a Car instance, they used
a simple switch statements of the following kind:
  1. switch (car.frame) {
  2.    case Constant.LIGHTWEIGHT:
  3.        // Do something for lightweight frame type.
  4.        break;
  5.    case Constant.NORMAL:
  6.        // Do something for normal frame type.
  7.        break;
  8.    case Constant.ARMORED:
  9.        // Do something for armored frame type.
  10.        break;
  11.    default:
  12.        throw new RuntimeException("Don't know about that type of frame);
  13. }
复制代码
In a new version of their software, they have been asked to add a new
value COMPOSITE_ULTRALIGHT=4 and they know they probably have to add
some more new values in the next few weeks. Now, on each rewrite of the
code, the number of switch statements grows to a very big number, it
takes a long time to spot all the statements and to check that every
single one of them is modified.

When the new version of the software goes in production one statement was
forgotten: The code throws a RuntimeException.

Which pattern would you use in place of the switch?

1. Proxy
2. Observer
3. Visitor
4. Builder
回复  

举报

2#
发表于 3-8-2009 11:25:26 | 只看该作者
是面试题目吗? 明显应该是bulder. 其实也许应该用工厂模式, 不过你这里没有列出对不同frame 具体需要哪些操作,所以不是很确定。
回复  

举报

3#
发表于 3-8-2009 12:48:46 | 只看该作者
我会用strategy或者template,如果对象生成用simple factory就算了。
回复  

举报

4#
发表于 3-8-2009 12:49:51 | 只看该作者
其实这是一个refactory的方法,好像叫做replace conditions with sub-class,不一定用patterns。
回复  

举报

5#
发表于 3-8-2009 14:46:41 | 只看该作者


这是正确的方法。replace conditions with sub-class, 同时,新的sub class采用Ioc方式(基于Factory Pattern构造),尽量保持现有代码的稳定性,扩展而不修改。

在这个场合里,新增加一个Frame的子类去体现新Frame的特征,并增加一个FrameImpl的子类去体现新Frame的行为,然后通过Factory模式构造这两个类,推荐用Ioc,这样可以不修改Factory类。

如果一定要在4个模式里选一个做答案,最沾边的可能是Builder,但是不完全。

class CarBuilder
public Car build(Frame frame, Tyre tyre, Engine engine)
{
  frame.assemble(tyre);
  frame.install(enginee);
  Car car=new Car();
  car.setFrame(frame);
  return car;
}

LightFrame,MediumFrame,HeavyFrame extends Frame
TwelveInchTyre,SixInchTyre extends Tyre
PetrolEngine,DieselEngine extends Engine

CarBuilder builder=new CarBuilder ();
Car car=builder.build(new LightFrame(),new TwelveInchTyre(),new PetrolEngine());
回复  

举报

6#
 楼主| 发表于 3-8-2009 15:38:15 | 只看该作者

看来大家的意见都比较一致

这个题应该是出错了。给出来的建议答案是 visitor,怎么看也不象。
明显是factory method + ioc或strategy
回复  

举报

7#
 楼主| 发表于 3-8-2009 15:41:26 | 只看该作者
原帖由 bfox 于 3-8-2009 11:25 发表
是面试题目吗? 明显应该是bulder. 其实也许应该用工厂模式, 不过你这里没有列出对不同frame 具体需要哪些操作,所以不是很确定。


来自java black belt上的beta题目,个人觉得题目出错了,所以拿出来讨论。
回复  

举报

8#
发表于 3-8-2009 16:21:34 | 只看该作者
Visitor是行为型模式,大家倾向的都是创建型模式。题目暗示的应该是如何建模switch里的"Do something..."的动作,这个倒是的确应该用visitor。当然,我这纯属马后炮,要我做我也肯定做的和参考答案不一样。
回复  

举报

9#
 楼主| 发表于 3-8-2009 17:19:37 | 只看该作者
原帖由 coredump 于 3-8-2009 16:21 发表
Visitor是行为型模式,大家倾向的都是创建型模式。题目暗示的应该是如何建模switch里的"Do something..."的动作,这个倒是的确应该用visitor。当然,我这纯属马后炮,要我做我也肯定做的和参考答案不一样。


visitor的前提是你已经有一堆不想动的类实现,现在需要扩展。
题目连这个前提都没有,根本不会想到visitor
我觉得在这里提visitor有点过于牵强
回复  

举报

10#
发表于 3-8-2009 17:37:35 | 只看该作者

回复 #9 key 的帖子

Car在这里就是不动的类, 变动的只是Frame的而已,如果Car.frame用int表示的话就更清楚了,现在是要根据类中某成员不同的值做不同的事,而且这些行为应该和Car这个概念没有强烈的相关性,因此可以用不同的FrameVisitor来visit这些值,并对这些行为进行建模。

当然,我说过我市马后炮,要我一开始也会用Builder,我觉得其区别就是对这些类成员(car.frame)值的变动是在创建时还是在创建后。这个例子也很好说明了只有参考答案而没有标准答案,我觉得只要能自圆其说就是好答案。
回复  

举报

11#
发表于 3-8-2009 20:21:53 | 只看该作者
是我刚开始我也选BUILDER,不过我觉得COREDUMP说的有道理,这里用BUILDER不合适,FRAME是一个INT变量,完全没有必要建几个不同FRAME的CAR,想考你的点其实比较浅,可惜大家一想都想远了,呵呵
回复  

举报

您需要登录后才可以回帖 登录 | FreeOZ用户注册

本版积分规则

小黑屋|手机版|Archiver|FreeOZ论坛

GMT+10, 13-4-2025 06:50 , Processed in 0.018008 second(s), 27 queries , Gzip On, Redis On.

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表