设计模式的问题!——factory method

lonelybug 2003-09-24 10:47:46
在设计模式(可服用面向对象软件基础)哪本书中的factory method模式中的有一个p71最上面的图,application中的newdocument()有一部分代码,我想问问如何使用呢!?它本身需要有返回值吗!?还是说要把需要创建得product当参数传入,然后再返回!?
高手指点一下!我有点不明白!这个如何用代码实现!我已经把剩下的都实现了!就是这个部分我不太明白如何实现与使用!谢谢谢谢了!
...全文
96 27 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
27 条回复
切换为时间正序
请发表友善的回复…
发表回复
金庆 2003-09-29
  • 打赏
  • 举报
回复
先用最简单清晰的方法实现功能,需要扩展性的时候再重构,模式应该是重构的结果。
lynxliu 2003-09-29
  • 打赏
  • 举报
回复
o6z把设计重用等同于模块重用和代码重用了,呵呵,虽然都是重用,但是内涵,方式都是不同的。工厂模式竟然是代替new的?!这是我听到的一大笑话,呵呵,别生气呀,你踏踏实实的把代码写出来,就知道了,呵呵,new一个都不会少的。(我猜你是很少写代码的,光看理论,观点怎么可能知道真正的含义呢,就像看别人开车,怎么看也不能直接上路一样)
另外,你老是说“什么时候使用模式 什么时候不使用”,那你不妨说说工厂方法“什么时候使用模式 什么时候不使用”。
工科思路和理科思路其实也是不一样的,其特征反映在清华、北工大之类的工科院校和北大之类的理科院校的毕业生的思维上面,也反映在工科系和理科系之间。但是o6z老兄看起来像是学文的,呵呵,开个玩笑,别见怪。
libi 2003-09-29
  • 打赏
  • 举报
回复
o6z的说法我不是理解得很透彻,但我想“工厂模式代替new”仅是举个例子说明问题罢了,没必要在这上面做文章。
对于设计模式的理解,我的看法应该是与o6z接近的。书上的模式相当于案例,都是死的,关键的是它解决问题的思想。例如工厂方法,它的思想就是一个对象要“使用”另一个对象,但它事先并不知道具体是哪种对象,就留下一接口,由知道的去做。这实际上是一种职责的分配,因为这些工作交给它去实现很困难,那就留给别人吧。对于书上那个具体的解决案例,我就没有很仔细地去研究了,掌握这一思想,我想在遇到类似的问题时我就可以解决了,我并不要求非得用和书上相同的形式去解决问题。
我确实是学理科的,而且还不是计算机系的,编程经验几乎没有,也许我的想法和大家不同。呵呵。
lonelybug 2003-09-29
  • 打赏
  • 举报
回复
我明白了,是不是应该用一个工厂然后实现同一种类别的product呢!?比如用一个windowfactory就去实现不同的windows的子类呢!?(eg:roomwindow, carwindow)这样的呢!?谢谢了!
lonelybug 2003-09-28
  • 打赏
  • 举报
回复
upup
lonelybug 2003-09-28
  • 打赏
  • 举报
回复
tobirdgu:
我查了一下书上的,就是说美实现一个doors 或者windows的子类的时候,就需要用到一个相应的factory的子类来去实现,那我如果要实现mydoor和mywindow的话,是不是应该用继承factory来完成呢!?
那如果像我这样想这么建立的话是不是就应该用到两个factory呢!?然后把product(windows,doors)和变成一个product,然后用相应的factory的子类去创建呢!?我有点做反了吧!!?
ozzzzzz 2003-09-28
  • 打赏
  • 举报
回复
实际上初学者很难理解什么是技术 在模式这件事情上最难掌握的就是何时使用模式 我想这绝对是一个技术问题 就好像开车 只认为使用方向盘 档位 油门 刹车是技术 知道何时使用方向盘不是技术 没有人会同意这样的观点
落实到工厂模式 我们都知道工厂是用来代替new的 所谓你可以使用new就可以使用工厂 但是在程序中出现了那么多的new 究竟应该代替那些呢 过分的使用会让你的代码混乱不堪 而效能很低 而不使用也可能会有同样的结果 在一个简单的场景下我们无法很深刻的明白这些 只有在你实际的工作中仔细权衡 才会理解 而初学者由于没有实际的经验 很难理解这些 他们往往误以为 会使用模式就是理解了模式 其实对模式的理解在于知道什么时候使用模式 什么时候不使用
初学者往往认为技术是解决一切 但是他们不知道技术的背景 技术的使用范围 技术的结果 而技术的精髓其实就在这些地方
BirdGu 2003-09-28
  • 打赏
  • 举报
回复
lonelybug:
DoorFactory和WindowsFactory的功能是完全不同的,所以没有必要继承Factory。
addnum如果是product里面的一个方法,那它应该属于product类,也就是说应分别属于Doors和Windows类。如果addnum是设windows和doors的号码的话,那完全可以作为构造函数和factory method的参数。

同意ozzzzzz说的:“实际上设计模式的最难掌握的地方不是什么核心价值 也不是什么实现的方法 而是究竟在情景下使用它, 它的使用的后果又是什么, 给系统带来的灵活性是不是值得 其实就是一些策略的问题”
学模式最关键的是知道什么时候应该使用模式,什么时候使用模式又成为了过度设计。
推而广之,“度”的把握、各方面因素的权衡普遍地存在于软件设计的各个角落,不扩张地说,这也是软件设计中最关键的。
lynxliu 2003-09-28
  • 打赏
  • 举报
回复
to o6z:“实际上设计模式的最难掌握的地方不是什么核心价值 也不是什么实现的方法 而是究竟在情景下使用它 它的使用的后果又是什么 给系统带来的灵活性是不是值得 其实就是一些策略的问题”典型的想当然的错误观点,策略和模式是两码事。就是说你老是把技术和技术的使用以及管理这些东西混起来,唉。
lonelybug 2003-09-28
  • 打赏
  • 举报
回复
因为factory是一个接口,它提供了一些标准,addnum方法其实就是一个product里面的一个方法,主要是用来添加所创建windows和doors得号码的!

希望大家继续补充呀!哈!
谢谢了!
BirdGu 2003-09-28
  • 打赏
  • 举报
回复
补充一下。
lonelybug的程序更想是AbstractFactory模式。不过我手头没有 DesignPattern这本书,不是太确定。
BirdGu 2003-09-28
  • 打赏
  • 举报
回复
lonlybug:
DoorFactory和WindowFactory为什么要继承Factory?没有必要。
CreateDoor和CreateWindows是实现了Factory Method模式。不过addnum方法有什么用就不明白了。
lonelybug 2003-09-28
  • 打赏
  • 举报
回复
为什么建议我不学习设计模式了!?
能说明原因吗!?
如果说只是要求更有效的代码的话,我觉得这是个很幼稚的原因,设计模式准求得不是外美绝伦的代码的执行效率,而是要求学会如何设计一个易扩展,以维护,一种思想!不是吗!?
谢谢你的建议!希望多多交流!也希望给我更多的忠肯的意见!
金庆 2003-09-28
  • 打赏
  • 举报
回复
不套用模式会写出更有效的代码。
f3611018 2003-09-28
  • 打赏
  • 举报
回复
学习!!
金庆 2003-09-28
  • 打赏
  • 举报
回复
看了你的代码,建议你不要继续研究模式了。
lonelybug 2003-09-28
  • 打赏
  • 举报
回复
upup
ozzzzzz 2003-09-27
  • 打赏
  • 举报
回复
阎博士理解了我的说法 在实际上我们说到面向接口编程的时候都是在说是要对类提供给外界的行为规范编程 当然interface可以提供这个规范 可是不能说只有interface可以提供规范 父类也可以是接口 而且往往就是接口 既便这个父类有属性 所有方法都不是抽象方法 也可以是一个接口
实际上设计模式的最难掌握的地方不是什么核心价值 也不是什么实现的方法 而是究竟在情景下使用它 它的使用的后果又是什么 给系统带来的灵活性是不是值得 其实就是一些策略的问题
金庆 2003-09-27
  • 打赏
  • 举报
回复
该段代码照抄就可以用了。
实际是创建了一个产品,返回值并不重要。
不需要参数传入指明产品类型,因为创建什么产品是子类决定的。

lonelybug 2003-09-27
  • 打赏
  • 举报
回复
http://www.boustead.edu.cn/forum/A_SOKEFILE/Other/Factory Method.zip
这是我写的一个代码!也不知道是不是很正确的运用了这个模式!
希望大家可以帮我改进一下!写了!
加载更多回复(7)

1,268

社区成员

发帖
与我相关
我的任务
社区描述
软件工程/管理 管理版
社区管理员
  • 研发管理社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧