|
锁定老帖子 主题：基础知识: 需求!
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2004-08-22
引用 从举的例子来看，工厂模式是可以在控制对象产生的方式上来进行动态配置的。但同时这个也带来更多的问题，我们看看配置文件就知道了，protected构造器，意味着factory的实现是多个的，意味着每个包对应一个factory类，还要为获取不同的实现类提供不同的instance方法，为了组装一个服务类，factory需要多少特定的方法？？？
假设一个包中的类用到另外一个包的类，而这两个类的构造器是相互看不见的，factory怎么放？？？？再把问题规模放大，多个子系统对应多个包，那么上面的factory怎么配？？ 从为了一个控制对象的优点而引入众多的标志，我们看看xml就知道，如果真正到生产环境，xml dtd至少为此庞大上一倍！！！xml dtd定义越复杂，说明实现就越难！！！！！ 这是典型的把问题复杂化的案例！！！！为了一个不必要的考虑，而引入如此众多的问题规模，这绝对不可取！！！ 问题是我从你举的例子看不出你说的这些可怕的问题呀. 就是多了几个factorymethod="xxx". 你的一些反问我也不懂是什么意思. 我觉得我们大家都最好不要高估对方的理解力. 尽量避免长句. 用例子和简短的说明更好. 如果有很多的点, 咱们一个一个来, 这比问题都堆在一个帖子里有效得多. |
| 返回顶楼 | |
|
发表时间：2004-08-22
firebody 写道 讨论一个小小的例子是绝对看不出利弊来得！！
怪不得讨论如此僵化，艰难，坎坷，跌宕起伏！！！ 奶奶的，我们一起例子规模搞大一点，再来讨论 protected 构造器的利弊！就知道谁对谁错？？？ 不是protected, 是private. 所以可能比你想象的限制还大. |
| 返回顶楼 | |
|
发表时间：2004-08-22
X1和X2不是我们讨论的范畴，我们是讨论X已经有了，是否可以不受影响地被重用，你还是直接讨论我那个X1和X2的例子吧
如果在这种情况下重构X1,X2的话，我绝对不会让X1和X2还存在，他们是两个不必要的工厂，没有任何逻辑，你消除了一个地方的味道，产生了另外一个地方的味道 |
| 返回顶楼 | |
|
发表时间：2004-08-22
potian 写道 X1和X2不是我们讨论的范畴，我们是讨论X已经有了，是否可以不受影响地被重用，你还是直接讨论我那个X1和X2的例子吧
如果在这种情况下重构X1,X2的话，我绝对不会让X1和X2还存在，他们是两个不必要的工厂，没有任何逻辑 1. 我还在等着你举反例来说明X不能被不受影响的重用. 2. 你认为在这种内部重构的时候改动客户代码是合理的. 好吧. 我不想对你的个人喜好做评判. 至少, static factory没有阻止你这么做. 你不想保留, 删了就是. 但是你这么说还不够, 你需要说明任何重构时候, 对任何设计者, 保留X1和X2都是不对的. 这才能证明你说的static factory没用的判断. 从用户角度来看, X1, X2就是提供两个不同功能的模块入口点. 我连它们是否是工厂都不关心. 至于它们是否自己做这个功能还是委托给别人, 关我啥事? |
| 返回顶楼 | |
|
发表时间：2004-08-22
ajoo 写道 呵呵. 从具体的到底有什么用扯到比较抽象的什么"实际含义"了? 那么你认同这个作用了? 至于是否改名? 你真要改名没人拦着. 但是你就认为自己永远正确, 自己认为应该改名, 自己认为没有什么实际含义就是圣旨了? 从用户的角度, X1的语义仍然是在标准输出打印"x1", 什么都没有变化. 为什么你的内部实现逻辑变化要影响用户? 你实现者自己认为"我的实际含义不同了", 就可以要求用户改动代码或者配置文件? 因为用户代码不能改动而保持不恰当的名字是无奈之举，但通常在保持兼容性的情况下会把这些名实难符的东西限定为deprecated。 如果保持名字不变，对于这个类的读者而言，除非能够在一个显眼的地方看到这个类的历史由来，否则会有一个严重的误导作用。 所谓的实际意义，意思就是说X1这样的名字，就像是aabb这样的变量一样，在实际的项目中是不会出现的，每个类通常会有一个与功能相匹配的类名。 而且，这两个X*类的存在，除了保持客户代码不变之外，真没有别的作用了。还不如搞个接口变成抽象工厂呢。 |
| 返回顶楼 | |
|
发表时间：2004-08-22
那好。private构造器，看我怎么修理你！！
原来我以为你是protected，那么ajoo， 我问你，你怎么设计读取这个配置进行service的实例化?： <bean name="serviceA" interface="Service" class="serviceImplA" factoryMethod="instanceForService"> <constructor> <param name="delaterA"></param> </constructor> </bean> <bean name="delegaterA" interface="Delegater" class="DelegateImplA" factoryMethod="instanceForDelegator"> <constructor> <param name="daoA"></param> </constructor> </bean> <bean name="daoA" interface="Dao" class="HibernateDaoImplA" factoryMethod="instanceForDao"> </bean> |
| 返回顶楼 | |
|
发表时间：2004-08-22
我那个最后一个问题，就是你如何写那个instance()，
注意这里静态的构造方法是唯一妨碍这个X类可以直接被readonly和potian两个人同时使用的原因 如果把构造交给外部，这个X类是可以被同时使用的，我们可以采取各种手段达到这一点，但用什么手段是没有关系的，关键是不在内部确定构造哪一个子类的给了我们这种可能性。 |
| 返回顶楼 | |
|
发表时间：2004-08-22
ajoo 写道 但是你这么说还不够, 你需要说明任何重构时候, 对任何设计者, 保留X1和X2都是不对的. 这才能证明你说的static factory没用的判断.
从用户角度来看, X1, X2就是提供两个不同功能的模块入口点. 我连它们是否是工厂都不关心. 至于它们是否自己做这个功能还是委托给别人, 关我啥事? 不过，最简单的做法还是举出一个这样的静态工厂能够成立的场景的反例。 |
| 返回顶楼 | |
|
发表时间：2004-08-22
"不恰当的名字"是你个人的看法.
你自己这么看不要紧. 但是如果你想把这个想法强迫每个人接受, 似乎你就要告诉大家为什么它们是不恰当的. 你要告诉客户: 看, 我知道你要一个可以打印"x1"的功能, 但是, 我们内部现在学习三个代表, 精简机构, 没有x1这个部门了. 你需要到"generic X"部门, 并且明确告诉他们你想打印x1 (因为这个部门现在吃喝拉撒都管, 你不告诉他们, 他们可不象原来的x1部门的人自动就知道你要打印x1) 于是客户要调整自己的工作逻辑, 给每个工作人员发一个通知: 大家以后不要去x1部门, 要去generic X部门并且告诉他们你要打印x1. 呵呵. 不错啊. |
| 返回顶楼 | |
|
发表时间：2004-08-22
potian 写道 我那个最后一个问题，就是你如何写那个instance()，
注意这里静态的构造方法是唯一妨碍这个X类可以直接被readonly和potian两个人同时使用的原因 如果把构造交给外部，这个X类是可以被同时使用的，我们可以采取各种手段达到这一点，但用什么手段是没有关系的，关键是不在内部确定构造哪一个子类的给了我们这种可能性。 我的X有一个instance(), Y有一个instance. 呵呵, 你要哪个, 就调用哪个. |
| 返回顶楼 | |
