re: 一次运用设计模式对现有系统进行重构的尝试（二） megadotnet 2008-11-09 21:50
re: 一次运用设计模式对现有系统进行重构的尝试（二） winter-cn未登录 2008-11-03 17:16
你这个需求其实不需要工厂模式 直接把接口提出来就可以了 直接用new就很不错
呵呵 不过我觉得该鼓励下楼主 上一篇文章里我几乎难以辨别楼主想要什么
这篇里已经看到一个基本正确的抽象工厂了
--引用--------------------------------------------------
winter-cn未登录: @Ivan-Yan
呵呵 你有没有发现你一步步做下来 除了创建对象变得越来越麻烦
代码质量没有任何进展？
上篇里面我就对你说了 应用模式要先看意图 看你自己的意图与模式是不是匹配 你现在对代码重构都没有目标 使用模式又有什么意义呢？
不要为了使用模式而使用模式
--------------------------------------------------------
up
这个简单的需求,实在没有办法来讨论设计模式.另外我的体会就是,在某些实际的应用中,两个子类也许并不能够完全的与抽象一致,比如说有它自己独特的方法,而又需要在业务类里进行区分,则还是要判断类型.开放封闭,不可能永远封闭.
大家不要要求這麼高嘛!設計模式是一種指導方案,用得人用也有各種方案,我覺得都正常,還是開發者理解最重要.大家在這里可以談談自己的做法以改進.比如樓主這個代碼,如果我做,我會把客戶端反射調用再封裝一下,搞個工作生成類或者就在抽象工廠中做,否則客戶端每次這麼多調用代碼,如果多個地方調用累啊.
@winter-cn未登录
谢谢您的耐心指点~
老实说，由于刚开始学习设计模式，真有点“为了使用模式而使用模式”。
那么具体到这样一个需求，您觉得应该怎么做才比较合适呢？
re: 一次运用设计模式对现有系统进行重构的尝试（二） winter-cn未登录 2008-11-03 13:49
我想利用反射来完成的话，客户端对具体的工厂操作也被抽到Config文档中配置完成，这样在以后的维护中会更加灵活。比如，如果具体工厂名称有变化，只要改动Config文档即可，Client端无需更改。
===========================================
比如这个 假如我改了CellFactory的名字 CellFactory的定义和构造函数都必须改名 你用了配置文件又有什么意义？
re: 一次运用设计模式对现有系统进行重构的尝试（二） winter-cn未登录 2008-11-03 13:45
@Ivan-Yan
呵呵 你有没有发现你一步步做下来 除了创建对象变得越来越麻烦
代码质量没有任何进展？
上篇里面我就对你说了 应用模式要先看意图 看你自己的意图与模式是不是匹配 你现在对代码重构都没有目标 使用模式又有什么意义呢？
不要为了使用模式而使用模式
感觉有了反射后工厂模式就没他存在的必要性了
简单工厂+反射好于工厂模式
如果不用反射
你这个抽象工厂同样需要if..else.. ,跟原来简单工厂没有区别
如果用反射
还弄个抽象工厂干嘛？用个一个工厂方法+反射就可以。
re: 一次运用设计模式对现有系统进行重构的尝试（二） winter-cn未登录 2008-11-03 10:52
@Ivan-Yan
晕 这也不是工厂方法啊 工厂方法的业务逻辑在父类里啊 - -
而且这两个模式并不矛盾
@winter-cn未登录
因为业务需求的缘故，这里只是个工厂方法模式，而并非抽象工厂。
谢谢指点~
re: 一次运用设计模式对现有系统进行重构的尝试（二） winter-cn未登录 2008-11-03 10:14
但是你现在的工厂只有一种产品
并不能体现抽象工厂的优势啊
re: 一次运用设计模式对现有系统进行重构的尝试（二） winter-cn未登录 2008-11-03 10:07
不错 这回是个标准的抽象工厂了
为什么没有闻到OO的味道?
ReceiveType.CELL：
execRFC.Bill_no = "BN101"; //传递入库单号
ReceiveType.MOD：
execRFC.Workorder = "WO001"; //传递工单号码
出现上面的代码，这个工厂已经没有任何意义了。
要了解模式，就要先了解意图。
不一定要反射吧，设计模式没说不能更改代码，没见过哪个系统变更没有更改过一行代码的。设计模式目的在提高复用，降低藕合，减少变化。
貌似 “ 敏捷开发的思想 ” 不是 “当我们在做需求变更的时候，要考虑到将来可能发生的新的需求，而我们此时的设计应该能够轻松应对将来的需求变更”
@木野狐(Neil Chen)
谢谢指教.
但是这里每种产品的执行方式是不一样的（半成品按照入库单入库，成品按照工单入库），并且可能在增加新的子类的时，处理方式还是不一样的。所以使用工厂反射进行方法重用似乎有些问题.....
请指教~
re: 一次运用设计模式对现有系统进行重构的尝试（一） winter-cn未登录 2008-10-29 17:30
我觉得你首先应该review下你的系统究竟是不是需要工厂模式
好好看看工厂模式的动机吧
re: 一次运用设计模式对现有系统进行重构的尝试（一） 木野狐(Neil Chen) 2008-10-29 17:21
@Ivan-Yan
刚才开会去了。就是 T2噬菌体 说的原因。
要增加一个子类的话，你这个实现需要相应的增加枚举值，和工厂类里面的 if else 分支。这样其实只会把简单的问题复杂化。
关于反射工厂 petshop 4 里也有个简单的范例的，可以参考。
这里没有做到理想的OO。理想的OO应该对修改关闭的。
在你的设计中，如果现在除了半成品和成品再增加一种新的产品类，则你的工厂是要修改的（多一个判断）。而且你的客户类需要增加一个方法处理新的产品。系统不好扩展。
另外一个不好地方是你的各种产品处理过程很类似，造成了重复代码。如果现在除了半成品和成品还有10种产品，你岂不是要写12个重复性的代码？
我的思路是这样的：
你对不同产品的处理过程是相同的，而只是生成方法不同。所以你应该让你的处理过程（客户类）仅与抽象的产品类耦合，然后通过反射，实现一个反射工厂。并让处理过程成为一个可复用的方法。
这样，不同的产品处理只需调用可复用方法，传递一个参数就可以了。参数再传入反射工厂，决定实例化哪个具体类。这样，即使有新的产品类加入，你的这部分代码一行也不用改动。
--引用--------------------------------------------------
木野狐(Neil Chen): 这里工厂的作用不明显，其实可以直接 new 相关的子类。
--------------------------------------------------------
@木野狐(Neil Chen)
是因为这里的情况少，或者简单的缘故吗？请指教？
re: 一次运用设计模式对现有系统进行重构的尝试（一） 木野狐(Neil Chen) 2008-10-29 16:32
这里工厂的作用不明显，其实可以直接 new 相关的子类。
恩.很不错.我现在也是只是学,不知道什么时候运到什么地方,看来还是理解不够啊.
re: CLR vir C# 之 属性 nanhuacrab 2008-09-12 08:57
哦，恍然大悟，理解错了，谢谢
re: CLR vir C# 之 属性 Ivan-Yan 2008-09-10 09:59
@nanhuacrab
是不能重载，不是不能重写~~
re: CLR vir C# 之 属性 nanhuacrab 2008-09-10 09:54
无参属性含有一个名称和返回类型（不能为void）,不能重载
属性不能重载？C#的override可以修饰属性的，它是怎么实现的？