锁定老帖子 主题:基础知识: 需求!
该帖已经被评为精华帖
|
|
---|---|
作者 | 正文 |
发表时间:2004-08-24
ajoo 写道 你BlackDog内部实现是真的直接实现了一个黑颜色的狗还是仅仅当作一个工厂从别的地方弄来的这个狗,我不关心。对我来说,BlackDog就是这个模块的入口。这个名字本身只是体现了这个模块的语义。我想这可以说得通吧? 这个,好像有点说不通。记得有一个builder模式,比如有一个最重要的buildMazeGame() /的方法。 按照名字体现"最重要"模块的语义,这个类直接叫做MazeGame,比MazeGameBuiler要少6个字母。 还有那个不需要改名的Square类,其实是因为最先取的这个Square比较中性,只要里面用到了乘方,不管怎么用的,按照哪种方式用的,都可以用这个名字。换句话说,这个名字的可区分度不大,所以带来的信息量也不大。假设这个包里面还有一个用到了乘方的类,那乍办?一个叫SquareA,另一个变成SquareB? 还有,那个抽象工厂的例子,其实重构成Template Method就了结这个问题了,把相异点封装在抽象方法中。 不过,好像你不喜欢继承的,hehe。 |
|
返回顶楼 | |
发表时间:2004-08-24
ajoo 写道 至圣先师说中庸,中庸。
我开始反对的是一干人咬牙切齿要彻底制静态厂于死地,静态厂绝对不可用的极端观点。 现在则在反对别人把我放在“静态厂万岁!静态厂要完全取代构造函数,要当系统设计的主导思想,要把容器打回老家去”的火上烤。 什么东西都不是银蛋。容器不是,静态厂也不是。 静态厂,不错,价格便宜量又足;容器也不错,用起来挺爽的。 但是,什么东西滥用都会出乱子地。你拿人参当饭吃?活腻了吧? hehe,大家好像没有要制静态工厂于死地吧。 即便是我这么不喜欢这个东西的,记得前面也表明过把它看作一个过渡模式的看法。如果应用的复杂性不再增加,那么这个过渡就变成最终了。只不过会在发布前把这些静态工厂抽象化(除非这个厂只有子系统内部用到)。 要把一个静态工厂发布出去,除非能够确认自己就是制定标准的老大,才能够方便用户不再作抽象直接使用静态工厂。标准的好处是成了标准,想变就比较难了,对client而言,不管怎么个依赖法,依赖于标准总是风险比较小的。 |
|
返回顶楼 | |
发表时间:2004-08-24
ajoo 写道 另外也希望读过effective java的同学们贴上一些书中的例子。
引用 刚才又google了一下别人都对这个问题怎么看。没有看见很有见地的讨论。(多是些大师说好就肯定好之类的话) 这里有一个对Bloch的interview。大家可以看看他的说法: http://www.artima.com/intv/bloch14.html 还有关于immutability的,也很对我的胃口。(呵呵。谁不是捡自己喜欢的介绍呢?) http://www.artima.com/intv/bloch11.html 关于不鼓励继承的。可能又会让一些同学不爽。增量编程有什么错? http://www.artima.com/intv/bloch12.html Blosh是java的大拿俺们都认同。但是,如果涉及到一些更加普遍的OO问题或者模式问题,至少俺会找一些别的说法,衡量一下哪个更大拿,然后选一个看的中眼。 hehe,口味问题。 |
|
返回顶楼 | |
发表时间:2004-08-24
ajoo 写道 至圣先师说中庸,中庸。
我开始反对的是一干人咬牙切齿要彻底制静态厂于死地,静态厂绝对不可用的极端观点。 现在则在反对别人把我放在“静态厂万岁!静态厂要完全取代构造函数,要当系统设计的主导思想,要把容器打回老家去”的火上烤。 什么东西都不是银蛋。容器不是,静态厂也不是。 静态厂,不错,价格便宜量又足;容器也不错,用起来挺爽的。 但是,什么东西滥用都会出乱子地。你拿人参当饭吃?活腻了吧? AJOO 好像我们这里谁都没有这样咬牙切齿的反对静态厂吧! 有的话,请举证!! 至于你举的例子,我只看了一半,因为你写的代码没有足够的注释,我也懒得看了!! 不过对于你的提的[b]包私有,对外隐藏一些具体类![/b]我觉得这是很正常的阿,比如说一个要实现具体而复杂的逻辑类,我就很喜欢把一些相对比较独立的逻辑封装在那个具体类的内部作为一个私有内类来实现,封装隐藏得比你更彻底,更自私!!!^_^ 至于静态厂,我也比较喜欢用!当我觉得一个相对比较小的子模块,而这个子模块只负责对应不用的需求提供实现自同一接口的对象时,我首先想到的是抽象工厂。但是我这里的静态厂是包或者应用公用的一个厂,而不是你所说类的静态厂方法。 但是对于你以前一致坚持的 为了实现类的静态厂方法而 私有 类的构造函数,无论如何, 如果万不得已,实在万般无奈, 被ajoo拿大砍刀 夹在脖子上逼我 的话,我才会这么做! 很显然,把一个没必要的限制加在任何一个类上(比如private 构造器),这是很 碍于 可扩展性的。 也是很容易让整个开发过程不得不 围绕 一个方向 进行:那就是因为你隐藏了类的构造器,让整体开发不得不仅能采取静态厂的方向进行。 如果,某一天,需要直接new的话,切发现这一切已经不可挽回,只能又硬着头皮 照着 套在头上的 类静态厂方法的 锁链 前进。 无论如何,隐藏一个类的构造器,这是很慎重的! |
|
返回顶楼 | |
发表时间:2004-08-24
firebody,
我要说的就是要批驳所谓的"使用静态工厂会碍于可扩展性的"这个毫无根据的结论. 我还以为都差不多了.怎么还有这个想法? 直到现在,没有人能够拿出所谓碍于扩展性的任何理论或者实践证据. 我的结论是:静态厂的扩展性是大于构造函数的. 现在唯一站得住脚也比较有力的反驳只有一个: 静态厂复杂度增加,是否实用. 其它所有的指责, 比如你认为静态厂影响灵活性或者静态厂不提供任何额外利益, 如果谁有兴趣继续讨论,我都可以奉陪. 不举例证直接就说"静态厂有碍灵活性"我是不答应的. 另外, 你弄错了封装的一个原则: 基本上都是你要公开一个东西的时候才要额外慎重. 隐藏一个东西嘛, 无所谓, 就算你以后发现真需要公开, 公开了就是. 从private变public容易, 反过来难. |
|
返回顶楼 | |
发表时间:2004-08-24
这么快大家就总结陈词了? ?好吧, 偶也来总结一下偶对万恶的静态工厂的看法吧:
1. 耦合性强, 所有的客户代码都耦合到了具体的X这个Class Name, 而不是I这个Interface Name. 2. 限制性强, 剥夺了他人extend或者override的权利. 3. 职责不清, 偶一直受到的教育是: "Decouple object creation policies from your class", Class只应该专心做好提供业务逻辑这份很有前途的职业, 象创建策略, 管理状态等等这种糙活应该丢给其他东东完成( 工厂 or 容器 or 配置文件 or blah blah ) |
|
返回顶楼 | |
发表时间:2004-08-24
1。耦合性小于构造函数
2。final也有这个特点。可是我认为这是一个优点。private也有限制性强的特点,我也认为是个优点。 3。这个教育说法太绝对。这个耦合不是你想解藕就可以的。有些创建逻辑和类实现细节本身就是强耦合的。强行分开就是破坏内聚性。 |
|
返回顶楼 | |
发表时间:2004-08-25
发现readonly最狡猾了。
放一把火,然后转身就跑。等大家打得筋疲力尽,又冒了出来,同样的话稍微换一下说法,继续煽风点火。 很象武侠小说里造谣有宝藏让武林豪杰自相残杀的大恶人。 良心大大地坏了! |
|
返回顶楼 | |
发表时间:2004-08-25
1, 3不争了, 前面都有230贴的争论......
不过, 偶发现了一个有趣地方: ajoo 写道 2。final也有这个特点。可是我认为这是一个优点。private也有限制性强的特点,我也认为是个优点。
那么ajoo看待问题的态度和Bloch一样: Bloch 写道 If somebody really needs to subclass it, they will call you. Listen to their argument. Find out if it's legitimate. If it is, in the next release you can take out the final. hey, man, 偶的客户可等不及大牛的next release了, 偶下周就要交货了...... 偶要求sun提供一个private member的getter都需要等个1, 2年, 害得偶只好去hack...... p.s ajoo 写道 很象武侠小说里造谣有宝藏让武林豪杰自相残杀的大恶人。 良心大大地坏了! 你现在才发现呀, 嘿嘿...... |
|
返回顶楼 | |
发表时间:2004-08-25
引用 偶要求sun提供一个private member的getter都需要等个1, 2年, 害得偶只好去hack
有趣。解释一下,看看是sun的错,还是你逆练九阴真经的结果。 |
|
返回顶楼 | |