|
锁定老帖子 主题：关于简单工厂应用的心得
精华帖 (0) :: 良好帖 (0) :: 新手帖 (3) :: 隐藏帖 (2)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-05-27
berlou 写道 beneo 写道 berlou 写道 if else其实不是不能用，只不过当你的系统扩张的很迅速的时候， 多个分支的if else出现在多个方法里的时候， 可能造成指数级的分支数量（笛卡尔积）。而修改某一个东西的时候，你可能要修改N多个分支。
if else不能用得话，那不就不是简单工厂了么？ 看来你还是在纠结于模式， 模式是用来更好的解决问题的。 虽然楼主在谈简单工厂模式， 但是既然是谈心得， 何不谈谈如何更好的应用？不然有什么价值？把书本上的gof23搬过来岂不是更好？ 我已经控制话题的扩散性了。 其实这个问题，深入谈下去还会有许多扩散性： 比如，如果serviceImpl是singleton的话，map里直接放service的实例就可以了。而prototype的话，还是放一个factory好一些。 说的可能复杂了，但是有人也说过，简单工厂根本算不上什么设计模式，因为它基本没什么明显的优越性。 你说得很对，我们不该纠结模式，所以我也看不到除了linux，window以外，还需要哪些扩张，最多是一个MAC OS吧。 if else 足矣 |
| 返回顶楼 | |
|
发表时间：2010-05-27
简单工厂模式的使用，最简单的方式就如楼主所使用的，
这里是有问题的: 第一,工厂需要依赖一些实现类，在Java中，配合反射可以将依赖类变为依赖字符串，一旦依赖字符串，就可以做成外部配置的，那么这个工厂将具有很大的通用性, 工厂的核心就是生成对象，至于如何生成的并不重要。 第二，其实有了第一条,就能很好的避免类之间的依赖关系，也会避免if-else的使用,map也没必要了,那么此时的工厂模式将获得无敌的扩展性. 第三，工厂生成的对象的管理，每次都new出来一个，还是将第一次new出来的进行缓存，这个选择的标准依据singleton和prototype进行选择。 不如这种混乱的时代已经过去了，我们已经迎接到了大一统的时代， 如果程序当中，用这种方式比较少的话，还好管理，如果多的话，将很难管理。 |
| 返回顶楼 | |
|
发表时间：2010-05-27
beneo 写道 berlou 写道 beneo 写道 berlou 写道 if else其实不是不能用，只不过当你的系统扩张的很迅速的时候， 多个分支的if else出现在多个方法里的时候， 可能造成指数级的分支数量（笛卡尔积）。而修改某一个东西的时候，你可能要修改N多个分支。
if else不能用得话，那不就不是简单工厂了么？ 看来你还是在纠结于模式， 模式是用来更好的解决问题的。 虽然楼主在谈简单工厂模式， 但是既然是谈心得， 何不谈谈如何更好的应用？不然有什么价值？把书本上的gof23搬过来岂不是更好？ 我已经控制话题的扩散性了。 其实这个问题，深入谈下去还会有许多扩散性： 比如，如果serviceImpl是singleton的话，map里直接放service的实例就可以了。而prototype的话，还是放一个factory好一些。 说的可能复杂了，但是有人也说过，简单工厂根本算不上什么设计模式，因为它基本没什么明显的优越性。 你说得很对，我们不该纠结模式，所以我也看不到除了linux，window以外，还需要哪些扩张，最多是一个MAC OS吧。 if else 足矣 你说的很对， 针对楼主的问题可以这么做。但是讨论的还是模式，这只是个sample， ok? 但是问题还在于，扩张点不仅仅是操作系统的类别。 这里是一个方法， 去调用if else， 如果有3种系统，就是3次查找。 如果两个方法需奥调用if else判断操作系统， 就是6次查找。 N个方法需要判断操作系统，就是N*3次查找。 |
| 返回顶楼 | |
|
发表时间：2010-05-27
H_eaven 写道 简单工厂模式的使用，最简单的方式就如楼主所使用的，
这里是有问题的: 第一,工厂需要依赖一些实现类，在Java中，配合反射可以将依赖类变为依赖字符串，一旦依赖字符串，就可以做成外部配置的，那么这个工厂将具有很大的通用性, 工厂的核心就是生成对象，至于如何生成的并不重要。 第二，其实有了第一条,就能很好的避免类之间的依赖关系，也会避免if-else的使用,map也没必要了,那么此时的工厂模式将获得无敌的扩展性. 第三，工厂生成的对象的管理，每次都new出来一个，还是将第一次new出来的进行缓存，这个选择的标准依据singleton和prototype进行选择。 不如这种混乱的时代已经过去了，我们已经迎接到了大一统的时代， 如果程序当中，用这种方式比较少的话，还好管理，如果多的话，将很难管理。 你在讲Spring呢吧 |
| 返回顶楼 | |
|
发表时间：2010-05-27
berlou 写道 H_eaven 写道 简单工厂模式的使用，最简单的方式就如楼主所使用的，
这里是有问题的: 第一,工厂需要依赖一些实现类，在Java中，配合反射可以将依赖类变为依赖字符串，一旦依赖字符串，就可以做成外部配置的，那么这个工厂将具有很大的通用性, 工厂的核心就是生成对象，至于如何生成的并不重要。 第二，其实有了第一条,就能很好的避免类之间的依赖关系，也会避免if-else的使用,map也没必要了,那么此时的工厂模式将获得无敌的扩展性. 第三，工厂生成的对象的管理，每次都new出来一个，还是将第一次new出来的进行缓存，这个选择的标准依据singleton和prototype进行选择。 不如这种混乱的时代已经过去了，我们已经迎接到了大一统的时代， 如果程序当中，用这种方式比较少的话，还好管理，如果多的话，将很难管理。 你在讲Spring呢吧 客观规律发展的必然性，人的认识达到这一程度之后，即使没有Spring这个框架的出现，也会有和它作用一样的框架的出现，而且现再已经是了， Spring的背后就是这些认识的实现。 |
| 返回顶楼 | |
|
发表时间：2010-05-27
简单工厂就是为了以后系统更好的扩张，消除if else
|
| 返回顶楼 | |
|
发表时间：2010-05-28
berlou 写道 心得在哪呢？这只是典型应用啊。
另外这种简单工厂完全可以用map类去掉if-else， 更简单直观。 接口设计时，避免条件hard code， 把最后100条log写死不好， 不如作为可变参数n 感谢大家如此激烈的讨论，设计模式应用到具体项目中达到效果即可，并非达到可拓展和通用，该通用的设计我就另一套设计方法了，当时我写此工厂时候系统仅仅部署在window和linux两种平台下，所以这样写了，达到不同平台生成不同系统对象的效果，我们学习设计模式为了就是解决问题而不是为了展示理解水平有多牛X，一切知识都是为了做出更好的产品。 另外说一下 berlou 这位兄台 打印100行日志我只是写的描述，难道你没有看参数么。getLastIndex100Log(int index,String date) |
| 返回顶楼 | |
|
发表时间：2010-05-28
beneo 写道 berlou 写道 if else其实不是不能用，只不过当你的系统扩张的很迅速的时候， 多个分支的if else出现在多个方法里的时候， 可能造成指数级的分支数量（笛卡尔积）。而修改某一个东西的时候，你可能要修改N多个分支。
if else不能用得话，那不就不是简单工厂了么？觉得这个说的经典... |
| 返回顶楼 | |
|
发表时间：2010-05-30
qyhdt 写道 berlou 写道 心得在哪呢？这只是典型应用啊。
另外这种简单工厂完全可以用map类去掉if-else， 更简单直观。 接口设计时，避免条件hard code， 把最后100条log写死不好， 不如作为可变参数n 感谢大家如此激烈的讨论，设计模式应用到具体项目中达到效果即可，并非达到可拓展和通用，该通用的设计我就另一套设计方法了，当时我写此工厂时候系统仅仅部署在window和linux两种平台下，所以这样写了，达到不同平台生成不同系统对象的效果，我们学习设计模式为了就是解决问题而不是为了展示理解水平有多牛X，一切知识都是为了做出更好的产品。 另外说一下 berlou 这位兄台 打印100行日志我只是写的描述，难道你没有看参数么。getLastIndex100Log(int index,String date) 首先我非常认同你的这种方式,就是为了解决问题. 但对解决问题的标准评判应该建立在复杂性与灵活性之间的折中, 与理解水平没有关系,相反理解能力是为了找到更好的解决办法. 如何理解这句话呢："针对一个任务T可能会有10种不同的编码方法，而在这10种方法中，有7种方法是笨拙的，低效的或者是难以理解的。而在剩下的3种编码方法中，哪一种会最接近该任务T的下一年度版本的代码呢？" 10方法代表着理解的广度，从不同角度理解问题；剩下的3种相对于其它7种是对同一问题理解深度的加剧。最终会选择一种做为解决问题的办法，但是最终选择的方法是建立在与其它9种对比的前提下做出的选择，也许没有其它九种也不会有这最后的一种,这里“最佳的解决办法”应该解释为“最匹配”。随着问题的复杂性需要找到更灵活的方式；以前认为不是问题的地方，现再成为了问题，需要修复bug. 这些都将促使去寻找解决眼下问题的其它方式. |
| 返回顶楼 | |
|
发表时间：2010-06-13
H_eaven 写道 qyhdt 写道 berlou 写道 心得在哪呢？这只是典型应用啊。
另外这种简单工厂完全可以用map类去掉if-else， 更简单直观。 接口设计时，避免条件hard code， 把最后100条log写死不好， 不如作为可变参数n 感谢大家如此激烈的讨论，设计模式应用到具体项目中达到效果即可，并非达到可拓展和通用，该通用的设计我就另一套设计方法了，当时我写此工厂时候系统仅仅部署在window和linux两种平台下，所以这样写了，达到不同平台生成不同系统对象的效果，我们学习设计模式为了就是解决问题而不是为了展示理解水平有多牛X，一切知识都是为了做出更好的产品。 另外说一下 berlou 这位兄台 打印100行日志我只是写的描述，难道你没有看参数么。getLastIndex100Log(int index,String date) 首先我非常认同你的这种方式,就是为了解决问题. 但对解决问题的标准评判应该建立在复杂性与灵活性之间的折中, 与理解水平没有关系,相反理解能力是为了找到更好的解决办法. 如何理解这句话呢："针对一个任务T可能会有10种不同的编码方法，而在这10种方法中，有7种方法是笨拙的，低效的或者是难以理解的。而在剩下的3种编码方法中，哪一种会最接近该任务T的下一年度版本的代码呢？" 10方法代表着理解的广度，从不同角度理解问题；剩下的3种相对于其它7种是对同一问题理解深度的加剧。最终会选择一种做为解决问题的办法，但是最终选择的方法是建立在与其它9种对比的前提下做出的选择，也许没有其它九种也不会有这最后的一种,这里“最佳的解决办法”应该解释为“最匹配”。随着问题的复杂性需要找到更灵活的方式；以前认为不是问题的地方，现再成为了问题，需要修复bug. 这些都将促使去寻找解决眼下问题的其它方式. 楼上说的 +1啊 |
| 返回顶楼 | |
